On 08/06/2012 07:17 AM, Ted Lemon wrote:
Every single user who has added a printer to OS X or Linux in the last
several years.
No. You think that because you're a geek like the rest of us. Every single
user who has added a printer to OS X has done so from a UI that presented a
list of printers doing bonjour. This list named the printers by brand. The
user clicked on a printer from the list, and that was the end of it. The user
certainly never saw Canon_PIXMA_900.local in any UI. I'm fairly sure this is
true of Linux as well.
Speaking as a geek who not only remembers NBP but actually wrote
an implementation of it, I have to say that it never even occurred to
me that there is some sort of IP equivalent of NBP. It just doesn't
fit the same mental model as fqdn's which is how I and just about
everybody else thinks of net naming.
In fact, I'm being far too generous with fqdn's. People don't even think
about them other than maybe top level brand names.com. Nowadays,
people expect to just search for whatever's relevant. If it doesn't come
up in search, it must not exist.
I have to say that part of my struggle here is just understanding the
problem(s) coming in from the cold. I see lots of hammers being applied
to things that may or may not resemble nails, but much less about the
real world aspects of this problem, cf search above.
Mike
Apparently multicast DNS works even in the absence of mental models.
It works in the sense that if you know the name of the machine you are trying, and tack
".local" on the end, there is a small chance that you will get to that machine.
But usually you won't, because various network glitches will have caused the machine to
rename itself to machine-04.local by the time you try to address it, even though there
were never any machine.locals other than that one. mDNS is a nice hack, but fairly
useless for the particular application we are talking about. It's pretty good for
service discovery (showing a list of printers in a UI).
IMHO, we shouldn't promote bad solutions, and .local is a bad solution.
A bad solution to what problem?
Well, indeed. We are clearly talking about different problems.
Several people spoke in favor of supporting existing solutions (a.k.a.
running code).
I'd like to see us gauge consensus for this point here on the list.
I'm against it, as you know. The problem with the current running code is
that namespaces overlap, and the UI has no way to detect or present this.
Settling on a half solution because we have running code is the wrong way to go.
I tried to show in the print server example that the client
may cache unique information about the server (GUID, unique host name, etc.)
that makes
disambiguation a non-issue.
But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know
which "fridge" is the right one. (I'm just repeating Stuart Cheshire here,
from a conversation we had last week). So the GUID doesn't give us the information we
want, and indeed can produce confusing results in the UI. A per-site naming scheme,
with a nice UI on top of it, _does_ give us that. Fridge can be fridge (home) and
fridge (here) in the UI, for instance, because we know we aren't at home.
It was agreed that name-<random>.local. is equivalent to
name.local-<random>. from a CS standpoint.
Here you are definitely arguing about the wrong problem. At the presentation
layer, both are equivalent, and both are wrong. What we want is not
fridge-1.local and fridge-2.local, but fridge (here) and fridge (there).
- it is relatively easy to retrofit this behavior to hosts and servers
and difficult (or
impossible) to reflash existing printers
You don't need to update the printers. Just have the CPE device say where you are. This stuff
can all happen at the presentation layer—at the protocol layer, it's perfectly fine if the printer
is "printer.local" as long as the CPE says what "local" means, and the UI
presents it correctly.
- using .local-<random>. based on ULA means complexity equivalent to ULA
distribution problem. This is a big issue when homenets are coalesced and
can't be solved by routing alone.
In general, the homenet merge is not likely to be a homenet merge in the sense
you mean, but rather a decommissioning of one of two routers, and a migration
of the devices formerly connected to the one router to the network operated by
the other router. In this case, a CPE-advertised location will solve the
problem in a nice, intuitive way—all the devices will appear in the UI as being
connected to the local network.
I think you're referring to a _different_ problem; resolving your
site's resources
while you are mobile. Am I mistaken?
I'm claiming that this isn't a separate problem.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
