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

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 14:49:58 2003

#5 inetDnsDomain attributes for contacts and nameservers

At first I thought the attributes for contacts and nameservers in 
inetDnsDomain were LDAP url's, but after reading the example it would 
seem they are just strings.  Correct me if I'm wrong (reading the OID 
numbers starts to get confusing for me).

If they aren't LDAP URL's, then what is a client to do with them for 
dereferencing?  Are these LDAP aliases?  The OID number seems to define 
their syntax as that of inetDnsDomain (also confusing since an email 
address is not a domain name).

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?

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.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 15:33:11 2003

> numbers starts to get confusing for me).

They used to be URLs, now they're just resource names which the client
uses to seed a new query.

There is no substantial difference there in terms of the followup
activitiy. A URL just provides a pre-packaged query to the client, and the
client still has to go through the same basic steps in any event (eg, it
has to find the SRV RRs, build the query, etc).

However, the pre-packaged URLs can be too static. The URL set may not
accurately reflect loading issues, for example, or may direct clients
somewhere they shouldn't be going. Making the client start the query with
the key value keeps these problems from happening.

Architecturally, this is similar to what DNS does. EG, when you get an NS
RR, you get a domain name as a value that you have to resolve.

> dereferencing?

They spawn new queries of the appropriate $resourceType with the attribute
value as the search key.

> Are these LDAP aliases?

No, they are input values for any followup queries that the user may be
interested in resolving. None of the attribute values are "automatically"
processed (referrals are the only data that get the automatic treatment).

> The OID number seems to define 

Contact entry names use an email-like syntax (user@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 [email-masked] 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 [email-masked]). Or as another example, I might be
[email-masked], 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.

> 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.

> to further dereference this information.

Probably need clarifications to the text.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 17:19:07 2003

> 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?

> 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

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 17:46:28 2003

on 8/18/2003 4:45 PM Andrew Newton wrote:

> 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!?

Heh. Are IP addresses domain names? Does the dot-separator confuse you?

They aren't email addresses, they are contact identity pointers. Whether
they are also usable as email addresses is up to the provider.

They use the same representation as IDN transformation, just like email
addresses will commonly appear if IDNA conversion takes hold.

> namespaces for them?  Perhaps use uid=contact-handle and mail=email

Just like URIs break when they are too explicit, DNs also break when they
are too explicit.

[email-masked] would get mapped into cn=[email-masked],cn=... just like
ns1.example.com would get mapped into cn=ns1.example.com,cn=...

> 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?

That works fine for locally-constrained and managed apps within a fixed
namespace. It has a lot of implications out in the wild.

Why don't MX RRs just return the IP address?