Subject: Re: Protocol: referrals and other URIs

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 12 Nov 2003 12:08:15 -0700

Howard,
 
For an implementation to conform to the protocol specification, it must
understand and correctly implement the specification. If there is
language that forces a server to do something it cannot do, that's a
problem.
 
If my interpretation is muddy, then the wording needs to change,
because it is not only me who is interpreting it that way.

Do you have alternate wording which captures the intent of this
statement while allowing non-LDAP protocols to be specified in referral
URIs?
 
Jim

>>> <[email-masked]> 11/12/03 10:35:23 AM >>>
>All,
> 
>There is the following text regarding referral URIs in the protocol
>document:
>"Other kinds of URIs may be returned, so long as the operation could
be
>performed using that protocol."
>
>It's quite likely (actually, it's a reality) that a protocol could
>exist which allows some directory operations (like add, modify, and
>search), but not others (like modDN).
>Even when one considers this language a certain way, two LDAP servers
>may not both support the same extended operation.

What the protocol defines and what a particular server implementation
supports are two very different things. Your interpretation is
muddying
the details needlessly.
-- Howard

---

From: "Jong" <[email-masked]>
Date: Wed, 12 Nov 2003 16:46:59 -0500

The server's knowledge on the other opaque protocols is an implementational
one
and hence needs to be treated as such in the protocol specification.
The client needs to be prepared for the server which has imprecise
information
on the other protocols, but IMHO, this seems to be outside of the protocol
specification.
- Jong

---

From: "Howard Chu" <[email-masked]>
Date: Wed, 12 Nov 2003 15:05:31 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Sermersheim

> language that forces a server to do something it cannot do, that's a

Certainly. But that's not relevant, since servers don't process referrals,
they merely return them to clients. Whether or not a server implements the
referral scheme is orthogonal to the question.

On the other side, a server that correctly parses LDAP queries and generates
properly formatted replies obviously has correctly implemented the
specification, even if it just returns LDAP_UNWILLING_TO_PERFORM for all
request types. The completeness of an implementation has nothing to do with
the correctness of it.

> statement while allowing non-LDAP protocols to be specified
> in referral URIs?

Not really, since I haven't really thought about which non-LDAP protocols
might meaningfully be used in a referral. I suppose one could envision an
HTTP server that was operating as an LDAP gateway, but I don't see what an
LDAP client really should do with such a response. Is it the LDAP client's
responsibility to parse these various other protocols and marshal them into a
format that the calling LDAP application understands?

Should it really be so open-ended, or should it just allow other *LDAP*
schemes over as-yet-unknown transports? (e.g. ldapi for LDAP over IPC, cldap
for connectionless LDAP over UDP, perhaps LDAP over a multicast transport,
etc...)

> >may not both support the same extended operation.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support