[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on namedref draft
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.