[Ietf-not43] #6 inetDnsDomain objects and 2251 referrals

[Eric A. Hall]

on 8/18/2003 6:18 PM David Blacka wrote:

> On Monday 18 August 2003 05:55 pm, Eric A. Hall wrote:

>>>  DNS domain name entries in FIRS MUST use the inetDnsDomain object
>>>  class, in addition to the mandatory object classes defined in
>>>  [FIRS-CORE]. DNS domain name entries MUST be treated as containers
>>>  capable of holding subordinate entries. If an entry exists as a
>>>  referral source, the entry MUST also be defined with the referral
>>>  object class, in addition to the above requirements.
>>>
>>>Why would they also use the referral objectclass?
>>
>>It's either-or, not also. The referrals are for use whenever a domain
>>entry needs to exist as an alias for some other entry.
> 
> Huh?  You've lost me.  
> 
> It seems you are saying that the object is *either* a inetDnsDomain object 
> *or* a referral object.  But that is not how the quoted paragraph reads: 
> "If an entry exists as a referral source, the entry MUST *also* be defined 
> with the referral object class, *in addition to the above requirements*." 
> [emphasis mine] says that some objects are *both* inetDnsDomain objects 
> and referral objects.
> 
> Or have I misunderstood?

Object classes are different from attributes.

The object classes that define the entry must always be defined. This is
needed so that the matching process works as expected ("please give me all
of the resources like name X of object class Z").

If an entry is a referral source, then the only attributes should be
defined inside the entry are the objectlass= attributes themselves, the
naming attribute (cn=), and the ref attribute.

If an entry is terminal, then it may have any of the attributes from any
of the object classes that are defined.

A terminal entry:

   cn=host1.example.net,cn=inetResources,dc=...
      cn: host1.example.net
      objectClass: top
      objectClass: inetResources
      objectClass: inetDnsDomain
      o: example.net ISP
      description: the example.net hosting server
      <any other>: ...

A referral entry:

    cn=www.example.com,cn=...
      cn: www.example.com
      objectClass: top
      objectClass: inetResources
      objectClass: inetDnsDomain
      objectClass: referral
      ref: ldap:///cn=host1.example.net,cn=inetResources,dc=...

      [No other attributes allowed.]

A query for cn=www.example.com && objectClass=inetDnsDomain would match
against the appropriate entry, and the resulting referral data would kick
the client over to the canonical target entry.

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