Re: Comments on namedref draft

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

At 01:32 PM 4/23/01, Richard V Huber wrote:
>What would we break if we required referrals to be LDAP URLs?

We would lose the flexibility provided by RFC 2251:
   Other kinds of URLs may be returned, so long as the operation
   could be performed using that protocol.

While RFC 2251 could use some clarification in this area, I believe
that it's generally accepted that clients should ignore URLs they
cannot process (either because they are not of a scheme the client
recognizes, or have unrecognized critical extension, or other
reason).

>In the same section:
>   The referential integrity of the URI SHALL NOT be validated by the
>   server holding or returning the URI (whether as part of the value of
>   the attribute or as part of a referral result or search reference
>   response).
>
>I'm not clear why we need to be so emphatic here.  I believe that the
>client MUST NOT expect the server to do referential integrity checks,
>but why make it "illegal" for the server to do them if it wishes?

I believe a SHOULD would be fine.  This recommends a practice
consistent with the data model but would allows behaviors
which do not violate the interface.


>In Section 7.6.1:
>
>   7.6.1 Bind
>
>   A server SHOULD process a bind request as if it held no referral
>   objects.  That is, if the bind name is a referral object or is
>   subordinate to a referral object, the server SHOULD process the
>   request normally as appropriate for a non-existent bind name (e.g.
>   return invalidCredentials).
>
>I think this needs some discussion on the list.

I should reword this a bit.  The intent was not to disallow the
server from chaining the request, but was to recommend the server
not return a referral to the bind operation (as the semantics of
such are ill defined).

> As this text stands,
>it would make it very difficult to split a large directory into several
>pieces on different servers.  Other current drafts (e.g.
>draft-reed-ldup-inheritance-00.txt) seem to be working towards
>supporting a more distributed environment.  I would prefer a MAY here
>(or remove section 7.6.1 entirely) so we can address this issue in more
>detail in future work.