On the Mac I just press the ‘-‘ button on the list of printers to remove the old entry.
I suspect most devices WILL NOT REMEMBER old printers. Macs are a exception because their heritage is manually configured printers. You will get to see the current list and that is just that. I think this is really a non-issue. The old printer is gone. There is a new printer with a different name. If a device really wants to be known by two names it can register itself twice. Mark > On 1 Jun 2018, at 10:39 am, Ted Lemon <mel...@fugue.com> wrote: > > On May 31, 2018, at 4:27 PM, Michael Thomas <m...@mtcc.com> wrote: >> With a CNAME, you wouldn't need to deprecate the other... it's just an alias >> that you have control of. >> From the UI perspective, whatever is presenting names to the user can prefer >> the human-given name over >> the auto-generated name, right? We wouldn't need to standardize anything >> then. > > Michael, I don't think you've really understood the issue here. Let me try > and explain it all at once, since the explanation was actually scattered > across several messages. > > There are two pieces to this. First, there's the thing that publishes the > name. That's DNSSD. There's no problem with that end of things. If you > change the name, the device just appears with its new name, and everything is > fine. That's our piece of the puzzle, and it already works. > > The problem is that hosts tend to remember names. On MacOS, for instance, > if you configure a printer, the host remembers the printer forevermore. > It's no problem to configure a new printer, but if you change the name that > the printer advertises, there will be a stale configuration on the host > pointing to the old name, and the user will have to configure a new printer > to get access to the old printer. > > So what we are talking about here actually breaks DNSSD's good behavior. We > don't want DNSSD to publish two names. We don't want DNSSD to publish a > CNAME. That would just be extra garbage that would have to be maintained > forever. > > What we want is a way for the host to notice that the device's name has > changed. We want the device to have some identity other than the name that > doesn't change when the name changes. And we actually have this in the > registration protocol, which is another draft being published in the DNSSD > working group. That protocol has the host generating a public/private key > pair, and using the public key as an identity. It uses this identity to > claim the name, but it wouldn't be that much work to also specify that hosts > should use that identifier to notice that a device has a new name and update > the name in the user interface. > > When I talk about UI, I'm really talking about the API behind the UI. > Having a management API for homenet would be a good thing. Possibly it > could just be done with HNCP. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
