On Aug 6, 2012, at 12:58 AM, Unindicted Coconspirator wrote: >> Domains like .local seem like a good idea to geeks like us, but how many >> regular users ever use them? > 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. > 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
