|
>>>> "Howard Chu" <hyc@symas.com> 11/12/03 5:05:31 PM >>>
>> -----Original Message----- >> From: owner-ietf-ldapbis@OpenLDAP.org >> [mailto:owner-ietf-ldapbis@OpenLDAP.org]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. 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
>referral scheme is orthogonal to the question. 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).
>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. 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.
>> 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? 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).
>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...) 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 > > >>> < highlandsun@highlandsun.propagation.net > 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. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |