[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Serious Comments on Referral draft

David, I don't understand what problem you are trying to solve
with your proposal i). Can you explain some more?    -- Tim

David Chadwick wrote:

> Tim, Mark,
> Having thought more about the referrals document over-night, I would
> now like to revise my previous conclusion that it was basically OK,
> and say that now in my opinion the document is fundamentally flawed,
> for the following reason. Referrals are dynamic information, which
> potentially change with every request that they forward, whereas
> knowledge references are static information that only rarely change
> (e.g. when a server is reconfigured). For this reason, the inclusion
> of the DN component in the ref attribute is fundamentally wrong, as
> this can potentially change for each operation that is referred. In
> this respect, only section 5.2 of the current document is
> correct.
>
> So I propose the following revisions:
>
> i) knowledge references are composed of two components
> a) the DN of the entry (DSE) in which they are stored
> b) the ref attribute which just contains the host component (host
> name and optional port number)
>
> ii) this leads to the following models for knowledge references:
> a) superior reference - as now, held in the root DSE, with only the
> host name and optional port number
> b) subordinate reference - held in the DSE with the DN of the context
> prefix of the subordinate naming context, with the ref attribute only
> containing the host component
> c) cross reference - a new section can be added for this (I will
> write it if you like), again held in the DSE with the DN of the
> context prefix of the referred to naming context, with the ref
> attribute only containing the host component
> d) NSSR - a tricky one, as my earlier email pointed out NSSRs are not
> currently supported with the current referrals model. A decision
> needs to be taken by the group about whether this is OK or not
> e) Indexed references - any of the above can probably hold indexing
> attributes and be used as described in section 5.3
> This model is nice in my opinion, since all knowledge references are
> now held in the same way, as opposed to the existing document where 3
> different ways are specified.
>
> iii) a new section needs to be written on how name resolution works
> using these knowledge references. This component of distributed
> operations is conspicuously missing from the current section 5.1 (I
> suspect because the current model does not adequately support it). I
> have included a draft section on this below.
>
> iv) The last sentence about name resolution in section 5.2 is
> incorrect. It should state "with the referral field filled in as
> follows:        Host component is copied from the ref attribute
>         DN is copied from the operation
>
> v) A new section needs to be written describing how alias derefencing
> works (unless you are happy to point to relevant sections in X.518
> and let folks work it out for themselves). I can write this if you
> want.
>
>  vi) The definition of ref attribute in section 4 has a minor
> error. When a ref attribute is used as a named reference as in
> section 5.1, it is actually a distributed operations operational
> attribute, and not a DSA operation operational attribute. This is
> because the ref attribute can be legitimately replicated between
> servers, if the entry in which it is held is copied.
> (Replication is the determining factor between DSA and distributed
> operational attributes)
>
> If the authors/working group accept my revised model, then the
> document will need some editorial revision before it is issued
> as an RFC. (I can help with this)
>
> Proposed new section for name resolution
>
> 5.1.1.4 Name resolution
> If the client requests an operation in which the target entry is
> below an entry (DSE) holding a ref attribute, and this entry (DSE) is
> a leaf entry in the current server, then the server will return an
> LDAPResult with the result code field set to referral, and the
> referral field set as follows:
>         Host component is copied from the ref attribute
>         DN is copied from the operation
>
> Thats it for now folks
> David
>
> ***************************************************
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 370 957 287
> Email D.W.Chadwick@iti.salford.ac.uk
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> ***************************************************