Re: I-D ACTION:draft-ietf-ldapext-refer-00.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Roland,

Thanks for putting this together.

I would like to see alignment of named references (per old
nameref or my I-D) and this draft.  I view named references
(which supports only superior and subordinate knowledge
information) as a "base" (or "simple")  functionality.  I
would prefer that other knowledge information (cross, nssr)
be supported through extension of a "base" specification.
I prefer this approach as it allows progression of the
"base" specification separately from extensions (which are
likely require additional time to ready).

I think the WG direction given at IETF#46 is still quite
applicable: "The authors are requested to ensure that by
the next meeting we have a single base document on the
simple (base) referral behavior that is suitable for
last call to become a Proposed Standard."

I would be happy to work with you on ensuring that a
base specification was extensible.

Regards, Kurt


Comments inline.

Excerpts from Referrals in LDAP Directories
<draft-ietf-ldapext-refer-00.txt>:
> 1.  Background and intended usage
> 
>    The broadening of interest in LDAP directories beyond their use as front
>    ends to X.500 directories has created a need to represent knowledge
>    information in a more general way. Knowledge information is information
>    about one or more servers maintained in another server, used to link
>    servers and services together.
>                      
>    This document is based on the following basic assumptions:
> 
>    - several naming domains

s/domains/schemes/   There is only one domain, the global domain.
All naming schemes must produce names which are unique within this
domain. 

>    The usage of LDAP as a access protocol to other than X.500 servers has
>    created islands of directory service systems containing one or more
>    LDAP servers.

The usage of two access protocols did not create islands.  The
lack of infrastructure to manage knowledge information created
islands.  If there was adequate infrastructure, the multiple
access protocol issues (in theory) could be solved by gateways.

>	 Each of these islands are free to pick their own naming
>    domain.

Organizations are free to choose which scheme the choose to
obtain a name within.

>    And that they also do; some use the old country,organization,
>    organizationalUnit naming scheme[X.521], some use the newer domain name
>    based naming scheme but these two are in no way the only ones in use.

And many pull names out of thin air.  Only organizations which
used standard track naming schemes may partcipate in the global
directory.   Knowledge information infrastructure provided for
each scheme varies, so some may have 'islands'.  However, the
protocol (and other models) supports knowledge information equally
well regardless of the naming scheme used.

This I-D proposes a model for managing knowledge information.  It
should be scheme independent.  As such, I find the discussion of
different naming schemes to be bit irrelevant and maybe better
left to other I-Ds.

>    The
>    existence of several naming domains are in itself no real problem as
>    long as they produce unique names for the objects in the directory.

Exactly.

>    Still naming schemes like the domain name based one, might easily create
>    non-continues naming structures because some toplevel domain names
>    might no find organizations that are interested and/or willing
>    to manage them. Therefor tree transversal might not longer be possible
>    except in parts of the whole tree.

This is true with traditional X.500 naming as well.

>       
>    - authoritive structure vs directory structure
>    In some instances even if a part of the tree is delegated to one
>    organization, the organization doing the delegation might want to
>    remain as the authority for the baseobject of the delegated tree.

The LDAP protocol may not be able to support such without modification.

Server A delegates the subtree "o=foo" to server B but remains
authority for "o=foo".  A subtree search for "o=foo" sent to A, A 
should return "o=foo" and a search continuation to B.  What would
the scope (implicitly or explicitly) of the LDAP URI provided
in the continuation?

subtree?  no, this would cause B to either return "o=foo" (if it
held a replica of this entry) or a referral (back to A or other)
or noSuchObject.  All are not acceptable.

>    - support for onelevel searches
>    At points in the tree where the responsibility for all or almost all
>    of the children of a object is delegated to different organizations
>    and resides in different directory servers a one-level search is not
>    very efficient if not supported by special facilities in the directory
>    as such.

I assume these special facilities do not change the semantics of 
protocol operations.

>    -- directory server discovery
>    LDAP servers that do not use dc nameing or are not registered with
>    SRV records in the DNS are very hard to find.

You generally do not need to discover the location of an LDAP
service which you have a LDAPURI for...

> 
>    This document defines a general method of representing knowledge
>    information in LDAP directories, based on URIs.
>    Two types of knowledge reference are defined: refer and subRefer.

subRefer?


> 2.1 The refer attribute
>    The refer attribute can be further specified by the use of options as
>    defined in section 4.1.5 of [RFC2251]. This document defines five
>    options and their use. Future documents might defined other options.
 
Is an option required?  If not, what is the semantics of an optionless
refer attribute?

I also question this use of options.  Are there better approaches?
I would suggest tieing the semantics of the attribute to object
classes and/or type of the DSE its contained in.  That is, a refer
in the root dse is a superior reference, a refer in a referral
object (objectclass=referral) is a subordinate, etc..

>    The options defined are:
>   "me", "sup", "cross", "nssr" and "sub" .
> 
>    'refer;me' is used to hold the reference of this server, and is always
>    held in the root DSE
> 
>    'refer;sup' is used to hold the reference of a server superior to this
>    one in this global LDAP naming domain e.g. a server holding the dc=com,
>    dc=se, or the c=se node. The 'refer;sup' is always held in the root DSE.
>    'refer;cross' indicates that this is a cross reference pointing to another
>    naming context within or outside this global LDAP naming domain.
 
Suggest striking "within or outside this global LDAP naming domain".
Naming schemes should be immaterial in the context of this draft.

>    'refer;sub' indicates that this is a subordinate reference pointing to
>    a subordinate naming context in this global LDAP naming domain.

Suggest striking "in this global LDAP naming domain".
Naming schemes should be immaterial in the context of this draft.
 
>    'refer;nssr' indicates that this is a non-specific subordinate reference
>    pointing to a subordinate naming context in this global LDAP naming domain.
 
Suggest striking "in this global LDAP naming domain".
Naming schemes should be immaterial in the context of this draft.
 
> 
> 3. Use of the knowledge attribute

I would prefer to attach the semantics of 'refer' attribute
to the DSE type and if an entry DSE to an object class.  In
the case of subordinate referrals, a structural object class
works well (semantics of DSE are established at instantiation
time).  For superior referrals, presence in the root DSE is
sufficient.

> 4 Behaviour specification
> 
> 4.1 Name resolution for any operation
> 
>    Clients SHOULD perform at least simple "depth-of-referral count" loop
>    detection by incrementing a counter each time a new set of referrals is
>    received.

Client behavior is specified by RFC2251.  This statement replaced
with a statement using wording found in RFC2251 with a clause
"as per RFC2251".

> 4.2.1 base-level
> 
>    If the entry matches the filter and does NOT contain a refer attribute
>    it will be returned to the client as described in [RFC2251].
>    If the entry matches the filter contains a refer attribute without
>    the 'nssr' option it will be returned as a referral as described here.
 
referral or search continuation?

>    If a matching entry contains a refer attribute and the URI
>    contained in the refer attribute is NOT an LDAP URI [RFC2255],
>    the server should return the URI value contained in the refer
>    attribute of that entry in a SearchResultReference.
>         
> 
> Hedberg           Expires September 30, 2000                    [Page 5]
> 
> Internet-Draft    LDAP Knowledge references                   July 2000
> 
> 
>    If a matching entry contains a refer attribute in the LDAP
>    URI syntax, the server will return an SearchResultReference
>    containing the value(s) of the refer attribute minus any optional
>    trailing whitespace and labels that might be present.

Wouldn't the server have returned a referral as directed above?
Is this for the with nssr case?  If so, some clarification would
be useful.

>    The URL from the refer attribute must be modified before it is
>    returned by adding or substituting a "base" scope into the URL. If the
>    URL does not contain a scope specifier, the "base" scope specifier must
>    be added. If the URL does contain a scope specifier, the existing scope
>    specifier must be replaced by the "base" scope.
>
> 4.2.2 One-level
> 
>    Any entries matching the filter and one level scope that
>    do NOT contain a refer attribute are returned to the client normally as
>    described in [RFC2251]. Any entries matching the filter and one level
>    scope that contains a refer attribute without the 'nssr' option must
>    be returned as referrals as described here.

s/referrals/search continuations/

> 
>    If a matching entry contains a refer attribute and the URI
>    contained in the refer attribute is NOT an LDAP URI [RFC2255],
>    the server should return the URI value contained in the refer
>    attribute of that entry in a SearchResultReference.
>         
>    If a matching entry contains a refer attribute in the LDAP
>    URI syntax, the server will return an SearchResultReference
>    containing the value(s) of the refer attribute minus any optional
>    trailing whitespace and labels that might be present.
>    The URL from the refer attribute must be modified before it is
>    returned by adding or substituting a "base" scope into the URL. If the
>    URL does not contain a scope specifier, the "base" scope specifier must
>    be added. If the URL does contain a scope specifier, the existing scope
>    specifier must be replaced by the "base" scope.
> 
> 4.2.3 Subtree search evaluation
> 
>    Any entries, held by the server, matching the filter and
>    subtree scope that do NOT contain a refer attribute or contains
>    a refer attribute with the 'nssr' option are
>    returned to the client normally as described in [RFC2251].
>    Any entries matching the subtree scope and containing a refer
>    attribute must be returned as referrals as described here.

s/referrals/search continuations/ 

>    If a matching entry contains a refer attribute and the URI
>    contained in that attribute is NOT an LDAP URI [RFC2255],
>    the server should return the URI value contained in the refer
>    attribute of that entry in a SearchResultReference.
>  
> 
> 
> 
> 
> Hedberg           Expires September 30, 2000                    [Page 6]
> 
> Internet-Draft    LDAP Knowledge references                   July 2000
> 
>    If a matching entry contains a refer attribute in the LDAP
>    URI syntax, the server will return an SearchResultReference
>    containing the value(s) of the refer attribute minus any
>    optional trailing whitespace and labels that might be present.
> 
>    N.B. in subtree search evaluation a entry containing a 
>    refer attribut with the 'nssr' option might appear twice in the
>    result, first as a entry and then as a reference. A client
>    following all references might therefore end up with a resultset
>    containing two representations of the same entry, one from the
>    server getting the original query and one from the server 
>    that the 'nssr' reference points to.

A (non-extended) search operation should not return the same
entry multiple times.  If a server returns a search continuation
that server must be capable of completely the operation.  It
is inappropriate for it to return entries which were returned
by other servers as part of a single distributed search operation.
 
> 5. The referral object class
> 
>    The referral object class is defined as follows.
> 
>    ( 1.2.752.17.2.10
>      NAME 'referral'
>      SUP top
>      STRUCTURAL
>      MAY ( refer ) )
 
I suggest this new object class use a new name.
I suggest LDAPreferral.

>    The referral object class is a subclass of top and may contain the
>    refer attribute.

What are the semantics associated with a referral object without an
refer attribute?  Which such an entry be normally visible? 

>	The referral object class should, in general,
>    be used in conjunction with the extensibleObject object class to support
>    the naming attributes used in the entry's distinguished name.
 
I suggest stating that the refer attribute itself should NOT be used
for naming purposes.

>    Servers must support the refer attributes through use of the
>    referral object class. Any named reference must be of the referral
>    object class and will likely also be of the extensibleObject object
>    class to support naming and use of other attributes.
> 

For all uses of refer?  This seems odd.