Re: [apps-discuss] Apps Review Team review of draft-zeilenga-ldap-dontusecopy-08

[Kurt Zeilenga <[e-mail]>]

On Oct 14, 2010, at 10:06 AM, Ted Hardie wrote:

> I have been selected as the Applications Area Review Team reviewer for
> this draft
> (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> Please wait for direction from your document shepherd or AD before
> posting a new version of the draft.
> 
> Document: draft-zeilenga-ldap-dontusecopy-08
> Title: The LDAP Don't Use Copy Control
> Reviewer: Ted Hardie
> Review Date: October 14, 2010
> 
> Summary: This document is basically ready for publication on the
> standards track, with one
> clarification needed and some editorial issues.
> 
> Major Issues:
> 
> In section 3, the document currently says:
> 
>   If original (master) information for the target or base object of the
>  operation is not available (either locally or through chaining), the
>  server MUST either return a referral directing the client to a server
>  believed to be better able to service the request or return an
>  appropriate result code (e.g., unwillingToPerform).
> 
> The LDAP referral syntax permits the use of URIs other than LDAP,
> provided they are believed capable of performing the operations
> (see RFC 2251 section 4.1.11).  But it is not clear
> how a referral using a different URI scheme would handle
> a request for authoritative data only.  I believe the author should

> consider whether restricting referrals to LDAP URIs
> would be useful in this case or whether real-world deployments
> make non-LDAP URIs sufficiently rare to make this superfluous.
> Text describing the case would be useful for either approach.

I was trying to avoid discussing chasing of referrals (even with only LDAP
URIs are used) as chasing of referrals is otherwise fraught with problems.

I will add text which says:

1) if the client chooses to chase an LDAP URL, it ought to use this control in the request it send to the referred to server.

2) use of non-LDAP URIs is left to future documents.

3) in absence of assurance that only authoritative information is used, the client ought to assume non-authorative information will be used.

> 
> Since the control is based on an X.511/DAP control, it is possible
> to get this same functionality there, but the IANA does not appear to list
> any URI scheme for this, making its use in a referral also apparently
> unlikely.

DAP relies heavily on chaining not referrals.

LDAP is increasingly slowly shifting to chaining instead of referrals.   (Given that LDAP doesn't have a chain operation, what LDAP servers do today might better be called proxying as there is no distinction in the proxied request of what infomration was provided by the originating client and what was provided by the proxying server).


> 
> Minor Issues: None seen.
> 
> Nits: The background section has a number of cases where multiple
> parenthetical expressions are used.  Some re-writing to remove them
> may increase the readability. For example:
> 
>  If the server has access to
>  the original (master) information (directly or through chaining), it
>  performs the operation against the original (master) information and
>  return compareTrue or compareFalse (or an error).
> 
> 
>  If the server has access to the original (master) information
> directly or through chaining,
>  it performs the operation against the original (master) information and
>  returns compareTrue,  compareFalse,  or an error.
> 
> These can be resolved in cooperation with the RFC Editor's application
> of the style guide.