|
>>> John McMeeking jmcmeek@us.ibm.com> 9/3/03 9:23:17 AM >>
>I think the first sentence of the paragraph (protocol 4.1.10) is critical >for context: > >URLs for servers implementing LDAP and accessible via [TCP]/[IP] (v4 >or v6) are written according to [LDAPURL]. If an alias was >dereferenced, ... > >Other kinds of URLs may be returned, so long as the operation could >be performed using that protocol. > >This suggests that the entire discussion of returning a DN in the referral >URL is already in the context of LDAP URL, but that could be reading more >into the document than was intended (in which case some sort of change is >warranted). To return something other than an LDAP URL implies that we are >not using LDAP or not using TCP/IP. I agree. This was not done intentionally on my part (more a lucky happenstance), and I kind of doubt it was the intent of the original authors. I agree that if we choose to tie the DN, filter, etc specifically to LDAP URLs, there need to be clarifications.
>These paragraghs are defining the interaction between a client and server >with respect to how a client handles continuation references. In that >context it seems appropriate to do something like: >1. A referral URL may contain the following components, which are used to >modify the original request: DN, filter, etc.. These components are to be >handled as decribed in the original text (generically - without reference >to LDAP URL) >2. The type of URL returned is dependent on the transport protocol; a
>mapping of LDAP to a given transport protocol must include the type(s) of >URLs that are to be used in continuation references and the mapping of the >above components (server, DN, filter,...) to the type of URL. Yes, this is what I feel is missing. Some kind of definition of reference "parts" and a forward looking statement requiring those parts (or equivalences) to be defined in future reference types.
Currently, it is only implied by some language in Protocol and RFC 3296 that some of these fields are required to perform certain LDAP operations.
>3. For use of LDAP over TCP/IP, this document defines the use of LDAP
>URLs. In addition to the components described above, the referral URL will >contain the target DNS host name, and optionally, port number (I assume >that these are not universal to all URL types that might be of interest). > >Having said all that, is there any reason to not require LDAP URLs? Good question. Though I assume one could reasonably say referrals to DSML, DAP, XLDAP, etc. are things people want. Another proposal is to allow any URL, so long as the <path> and <query> parts adhere to LDAP URL. Jim
|