On Thu, Aug 9, 2012 at 7:51 AM, Andrew Sullivan <[email protected]> wrote: > On Thu, Aug 09, 2012 at 08:17:22AM +0100, Brian E Carpenter wrote: >> >> ALQDN - ambiguous, or potentially ambiguous, names (like printer.local) > > That doesn't need a new name. We have a name for that: "relative". > See RFC 1034 section 3.1. > >> ULQDN - unambiguous, or almost certainly unambiguous, names (like >> printer.<gibberish>.sitelocal) >> > Change the leftmost '.' to '-' and I'm with you.
> That example is strictly speaking a relative name, too, since it isn't > qualified by the root label. > > But my point upthread was not about bikeshedding the things we call > this, but to observe that there are different naming technologies (we > concentrated on DNS and mDNS names, but we also have NetBIOS and llmnr > names. The latter is very similar to but not exactly the same as > mDNS. We can only wish that NetBIOS names are all gone). I think the > impulse to try to get these to work together from the user's > perspective is right, but for the purposes of protocol development we > need to attend to the fact that they're all just different > technologies. > We all agree we shouldn't call them FQDNs, so that's progress. The distinction I was trying to draw was not which protocol is used for resolution, nor the degree of ambiguity in the name, but that these names are defined within a local scope (e.g. without recourse to recursive DNS lookups outside the site boundary). I feel that names such as those in RFC 6303 would also qualify by my definition, so maybe we should call them Locally Served DNS Names or similar. I also want to draw attention to terminology Erik Kline used in his discussion of http://tools.ietf.org/html/draft-kline-default-perimeter, the notion of "inside the home" versus "The Internet". I think this is a very useful model to enforce with users as it can be applied equivalently to naming, discovery, addressing, and security. >> I will be unhappy if ALQDNs are allowed except as legacy. > That's exactly the point. mDNS isn't going away, so let's fix the issues and leverage it as a basic capability. -K- > Me too, but since they're built right into RFC 1034 (which is still > STD 13), I think we're dreaming. We might as well wish that the world > be freed from NAT. > > Best, > > A > > -- > Andrew Sullivan > [email protected] > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
