Ted Lemon <[email protected]> wrote: > 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, there are now "True Names", and "Current Names", and some nebulous
disctinction between them. TrueNames could be IP addresses or L2 addresses
(except for privacy issues that make them Current names)...
Let me add additional motivation/use-case to what you say:
Let's say I have a printer called "basement", and after awhile I decide I
want a better printer, and so I get one. I move the "basement" printer
to the spouse's office, and I want to rename it "houseprinter", because
I want the new printer to be called "basement".
I should be able to rename the printer once, and a whole bunch of places
where there is a link to "basement" should become "houseprinter", because I
see no reason why I should re-install drivers and changes settings, etc.
At the same time, the default printer for my basement desktop should probably
*not* change, but perhaps that's too much to ask.
Contrast this to a case where I get a new phone, and give my old phone to my
kid. I actually want to *disconnect* all privileges for the old phone when
it is not just renamed, but in fact, factory reset. My new phone should get
all the privileges of my old phone.
So in fact, when I move the printer I want it to keep the TrueName something,
and when I get a new phone, I want it to adopt the old phone's TrueName
something.
> 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.
Factory reset generates a new keypair, and despite the name change,
that should persist in the printer, so this is perfect.
So what we want the host to remember is the public key of the printer, not
the name. Is this possible with DNSSD? I guess we need this additional draft.
> 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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
