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

[Eric A. Hall]

on 8/19/2003 12:58 PM Andrew Newton wrote:

> Eric A. Hall wrote:
> 1  > A referral entry:
> 2  >
> 3  >     cn=www.example.com,cn=...
> 4  >       cn: www.example.com
> 5  >       objectClass: top
> 6  >       objectClass: inetResources
> 7  >       objectClass: inetDnsDomain
> 8  >       objectClass: referral
> 9  >       ref: ldap:///cn=host1.example.net,cn=inetResources,dc=...
> 10 >
> 11 >       [No other attributes allowed.]
> 
> I think the confusion is over lines 7 & 8.  How could it be either-or 
> when your text says "also"?  Anyway, I believe I understand what you are 
> saying.

As I said in the other message, that part of the text was in error and is
already fixed in the -03 drafts. The modified text says that referrals
must not be containers, must not have additional attributes, blah blah.
It's explicitly either-or in the -03 texts.

> I believe this comes down to a difference between 2251 style referrals 
> and the named subordinate references in 3296.  After reading 3296, it 
> would seem my original point is still somewhat valid because your draft 
> does not mention the use of the manageDsaIT control.  You should add 
> text requiring the recognition of it by the server and the use of it by 
> the client.

That's not necessary. In the case of deployments that use packaged
servers, the control would need to be provided as part of the referral
service. In the case of servers that are going to be manipulating data in
a private back-end, LDAP isn't going to be used for editing the referral
data, but even if it is, RFC 3296 is the governing spec here not FIRS. In
any event, I don't think it's appropriate or necessary to restate RFC 3296
requirements in the FIRS specs.

> Otherwise, all those domain variants you mentioned will 
> fill up the result set before any valid response.

I'm not sure what you mean by this. The manageDsaIT control provides a way
for clients to edit an entry that contains referral data (in the default
case, a request for the entry would cause the server to generate the
referral, while the control says "no no, I want to change the entry not
read it"). It doesn't have anything to do with the "size" of the result
set to my knowledge. Am I misunderstanding you here?

> I also do not see where the thin registry model referral/reference is 
> defined. But that should be a simple addition, correct?

Something like that should probably go in the architecture guide rather
than in the technical spec. I have some other text that I want to put in
there already so this would be a good time to include anything else along
those lines. What exactly do you think needs to be said here?

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