On 8/31/2005 12:36 PM, Ned Freed wrote: > Section 2 states: that's unfortunate LLMNR clients need to make a distinction between the different kinds of networks and then process the names accordingly. The whole argument behind the original distinction between LLMNR and DNS is that ad-hoc names aren't self-authoritative, the namespaces are therefore different, and so forth. Having clients try both namespaces is really missing the point. > Another way of fixing the overlapping namespace problem would be to require > LLMNR to be truly disjoint from the DNS: Remove all this stuff about using the > DNS as the primary service when available. However, my guess is that such a > service would not be terribly interesting, and that much of the supposed value > opf LLMNR comes from its lashup to the DNS. I was under the impression that LLMNR value was from ad-hoc networks and naming. Surely that's the right place to flag the distinction too. NB: I consider ".local" to be a crutch that's needed to make a hack work, and the right place to deal with these problems is at the interface map, not inside the namespace. Nevermind the fact that .local is overloaded with massive historical and experimental context already too. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf