[Ietf-not43] #5 inetDnsDomain attributes for contacts and nameservers

[Andrew Newton]

Eric A. Hall wrote:
> 
> Contact entry names use an email-like syntax (user at domain) so that they
> can overlap with email addresses, but these are not always going to
> reference existing email addresses.
> 
> The idea here is that I can publish ehall at ehsco.com as my contact identity
> and people will be able to remember this since that's what I use for all
> of my crap anyway. However, if ~netsol assigns a nic handle to me, then
> that identity can point to their portion of the namespace (eg, something
> like eh26 at registry.netsol.com). Or as another example, I might be
> eh26 at registry.arin.net, where that identity entry holds public information
> about my role as a hostmaster. In either case, those entries could provide
> additional information or services (such as forwarding mail to me, or
> publishing subordinate reference referrals to my real identity, or
> whatever). Those are feature-adds that are up to the provider.
> 
> So the idea here is that we have a flexible, universally applicable
> pointer for contacts, and which may be the same "identity" as I use for
> things like email, or a registrar-specific identity that provides public
> delegation-related data.
> 
> The syntax uses the i18n domain logic for the @domain element for
> consistency purposes. The localpart@ is also utf8 to allow for the i18n
> work effort that is ongoing in the email space, but does not define a
> syntax for that (yet) so the localpart element is technically limited to
> the existing RFC 2822 syntax rules but is capable of supporting a richer
> syntax when one becomes available.

Huh? Email addresses that aren't quite email addresses, and domain names 
that aren't quite domain names!?  Private email addresses assigned by a 
registry!?

Why don't you just call them contact handles and have two separate 
namespaces for them?  Perhaps use uid=contact-handle and mail=email address.

I don't get this.  Why is this special email address your "identity"?  I 
thought the LDAP DN was the identity.  Isn't that the LDAP way?

>>If the client gets an inetDnsDomain entry, what is it to do to follow 
>>the information for a nameserver?  Does it requiry the same server? 
>>Does it start the whole query bootstrapping process again?
> 
> 
> It spawns new queries for each of the referenced domain names. If an
> organization wants to force this, they can return the entries as
> subordinate reference referrals which the client would then automatically
> chase down.
> 
> 
>>Either I just don't get it (entirely probable at this point), or these 
>>should be LDAP URL's, or there needs to be text defining how a client is 
>>to further dereference this information.
> 
> 
> Probably need clarifications to the text.

Thank you.  This makes sense now.  I think text describing that the 
client is to use this to feed new queries would be useful.

-andy