[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Serious Comments on Referral draft
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
***************************************************