In message <50236402.3020...@gmail.com>
Brian E Carpenter writes:
> On 08/08/2012 19:52, Evan Hunt wrote:
> >> Except, of course, that it's not a "DN" at all: it's not a domain
> >> name.
> >
> > Also not "qualified", as long as we're quibbling. But I do think the
> > distinction between FQDN and <thing we're talking about> is a useful one
> > to have terminology for, and "LQDN" does get the job done even though it
> > doesn't make proper acronymic sense; I suggest we continue using it here
> > in the short term and plan on switching to a more precisely accurate term
> > by the time we start producing RFC's.
> >
> > I don't have spare cycles to participate in the bikeshedding, but I'll
> > be happy with anything that agrees with the definition previously
> > proposed for "LQDN".
>
> As far as I can see there are still two kinds of LQDN:
>
> ALQDN - ambiguous, or potentially ambiguous, names (like printer.local)
> ULQDN - unambiguous, or almost certainly unambiguous, names (like
> printer.<gibberish>.sitelocal)
>
> I will be unhappy if ALQDNs are allowed except as legacy.
>
> Brian
Brian,
My prior suggestion is that we have both types of LQDN and not just
temporarily.
printer.{local|sitelocal} is an ALQDN
printer.<gibberish>.ulalocal is a ULQDN
printer.<real-domain-name> is a FQDN
For backward compatibility and to have a constant and easy to type
identifier, printer.{local|sitelocal} can be a CNAME where:
If an FQDN for printer exists:
ALQDN CNAME points to the FQDN
printer.{local|sitelocal} is a CNAME for printer.<real-domain-name>
rDNS points to the FQDN
<in-add> points to printer.<real-domain-name>
If an FQDN for print does not exist:
ALQDN CNAME points to the ULQDN
printer.{local|sitelocal} is a CNAME for printer.<gibberish>.ulalocal
rDNS points to the ULQDN
<in-addr> points to printer.<gibberish>.ulalocal
The application can detect that the mapping of the ALQDN has changed
in three ways. First the CNAME mapping has changed. Second the
address that is returned has changed. Third the rDNS has changed.
If a domain name is later acquired, then the application can detect
this on later use of the ALQDN in two ways. First the CNAME mapping
has changed. Second the rDNS has changed. Note that the final
forward mapping to an address has not changed in this case. If a
domain name appears, but the address remains the same, the mapping to
FQDN can silently replace the mapping to ULQDN (retaining the former).
If the final address associated with a ALQDN changes, then it may be
that the site local scope has changed. If so all ALQDN that map to
ULQDN can be retained but the user must be warned if specifying a
ALQDN. If the ALQDN had previously mapped to a ULQDN or FQDN that
mapped to a GUA, then the user can be given the option to try it. If
the ALQDN maps to a FQDN, the mapping can be verified. If the ALQDN
maps to a ULQDN, then the mapping cannot be verified but can be tried.
This is what I suggested before, just reworded and using your ALQDN vs
ULQDN distinction.
Curtis
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
