Subject: Re: Protocol: referrals and other URIs

From: [email-masked]
Date: Wed, 12 Nov 2003 10:35:23 -0600

>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: John McMeeking <[email-masked]>
Date: Wed, 12 Nov 2003 14:20:06 -0600

I view the existing wording as an attempt to leave the door open for some
as yet unknown alternative URI and tell client implementors that they
should be prepared to handle it -- or at least deal with an unsupported
format more gracefully than they might have otherwise.

In that context, I think the existing language is fine.

John  McMeeking

                      [email-masked]                                                                             
                      agation.net                         To:       [email-masked], [email-masked]                
                      Sent by:                            cc:                                                                  
                      owner-ietf-ldapbis@OpenLDAP.        Subject:  Re: Protocol: referrals and other URIs                     
                      org                                                                                                      

                      11/12/2003 10:35 AM

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 13 Nov 2003 13:40:27 +1100

It is weird, no matter which way you slice it!

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Howard Chu
Sent: Thursday, 13 November 2003 10:06
To: 'Jim Sermersheim'; [email-masked]
Subject: RE: Protocol: referrals and other URIs

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

> 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.

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.

> 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?

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...)

> Jim
>
> >>> <[email-masked]> 11/12/03 10:35:23 AM >>>
> >All,
> >

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 12 Nov 2003 19:39:58 -0700

>>>> "Howard Chu" <[email-masked]> 11/12/03 5:05:31 PM >>>
>they merely return them to clients. 
 
Right, the server returns the referral to the client. and an
administrator populates the directory with the referral. The referral is
returned for operations. Thus there are two players that can control
what is returned in a referral: 1) The administrator (the entity
populating the directory with the reference URI), and 2) The server
(which is returning the referral for an operation)
 
The requirement in question involves knowledge of three things: a) the
presence of a reference, b) the current operation, c) the protocol used
to progress the resulting referral.
 
I assert that neither of the two players can make use the three bits of
knowledge to meet the requirement.
 
The server can't understand the relationship between (b) and (c).
The administrator can't specify a URI based on any given operation.
 
>Whether or not a server implements the

Agreed, this is not the path I'm going down (unless one considers
servers that chain operations, and know how to chain using non-LDAP
protocols, but let's ignore that for now).

>request types. The completeness of an implementation has nothing to do
with

Sure, but let's not just toss rhetoric about. When an implementor
decides to go a bit further than to return unwillingToPerform and
actually process an operation, it's generally seen as a good thing when
they actually adhere to the specification. When following the
specification becomes impossible, one tends to want to fix the
specification. I assert that there are cases where the language in
question is impossible for any given player involved to follow.

>format that the calling LDAP application understands?

In this case, there would be some specification that defines a URI
format to be used to reference an HTTP server from a directory entry
(one hasn't yet been defined). That specification would likely describe
URI parts that are somewhat analogous to the various parts of an LDAP
URL.
 
A client receiving such a referral would be free to follow it per the
aforementioned specification. A natural client scenario would be one
where a federation-friendly library like JNDI was being used. The JNDI
client would have both the LDAP service provider and another (HTTP-Dir?)
service provider (and possibly others) available. When a non-LDAP
referral is encountered, the JNDI application would federate using that
referral so long as it knows how to follow it using one of its non-LDAP
service providers. This is only one example of client-side work that
could be used to follow non-LDAP referrals (JNDI need not be used, it's
just the most natural environment for such a thing to happen that I know
of).

>for connectionless LDAP over UDP, perhaps LDAP over a multicast
transport,

It was this open ended in RFC 2251. I believe the ability to federate
to non-LDAP servers is useful and powerful. I would argue against
removing this flexibility.
 
Many cross-protocol federations have been suggested in the past,
including (various) Filesystem, HTTP, DAP, NDAP, (various) Domain-like,
and others. I imagine the future will see proposals to add referrals to
XLDAP, and the like as well.
 
To reiterate: this problem has to do with the fact that a requirement
is asking that knowledge of protocol/operation pairs are known, yet no
LDAP actor has that knowledge.
 
Jim

> Jim
>
> >>> < [email-masked] > 11/12/03 10:35:23 AM
>>>
> >All,
> >
> >"Other kinds of URIs may be returned, so long as the operation
could
> be

-- Howard Chu

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 13 Nov 2003 19:20:44 -0700

"Clients are free to ignore"?

>>> Mark C Smith <[email-masked]> 11/13/03 8:04:08 PM >>>
Jong wrote:
>>Other kinds of URIs may be returned. The syntax and symantics of
such
>>URIs is left to future specifications. Clients ignore URIs that they
>>don't support.

I am not sure we should say that clients ignore URIs that they do not 
understand. A client may want to display them to the user or report an

error in some way if a referral was returned that could not be followed

(or understood).

-Mark