Re: LDAP URI scheme that specify alternative transport protocols

[mcs@netscape.com (Mark C Smith)]

"Kurt D. Zeilenga" wrote:
> 
> One of the problems facing LDAP (and other application protocols)
> is how to specify URIs that indicate use of an alternative transport
> protocol.  This problem stems from the need to represent LDAP knowledge
> references which indicate the transport to use when the referred to
> server supports/requires alternative transport protocols.
> 
> For example, LDAP can be utilized over TCP or over TLS (versus
> StartTLS).  In fact, LDAP can be utilized over any transport
> which provides a reliable byte stream.
> 
> We (and I believe other vendors) are currently extending our LDAP
> implementation to support a number of other transport protocols
> such as Local IPC and TLS.  The current approach is to define a
> URI scheme per transport protocol, ie:
>         ldap://host:port/
>         ldaps://tlshost:port/
>         ldapi:///
> 
> [Note: StartTLS could be handled using the ldap: scheme
> with an extension <ldap://host/dc=openldap,dc=com????tls>.
> Maybe we should document a URL format for StartTLS in the
> TLS draft?]


We (Sun-Netscape Alliance) already support the ldap: and ldaps:
schemes.  Of course ldaps: is not a standard.  In the past, the argument
was made that a client can decide whether to use TLS after they connect
using regular LDAPv3, so there is no need for an ldaps: scheme or a TLS
option.  But I believe it is sometimes important for clients to be given
a strong hint that they should use TLS.

By the way, what is the ldapi: scheme?  Is that the "LDAP over a
machine-local transport" idea (like using a UNIX domain socket)?


> This problem is not unique to LDAP.  Numerous application protocols
> support multiple transports.  Though this can be handled by adding
> additional URI scheme for each transport protocol supported by each
> application protocol, an extensible mechanism is desirable.

I agree -- this is a general problem.  And therefore I think it should
be handled in a URI-focused group.  This same issue must've been
discussed by those who worked on RFC 2396.  Certainly if you extend the
generic URI syntax, 2396 will need to be updated.


> I have two approaches that might be workable that I would like to
> discuss:
>         ldap://host:port/
>         ldap+transport:://host:port/
> 
> or
>         ldap://host:port/
>         ldap[transport]:://host:port/
> 
> where transport is tcp, tls, ipc or other transport protocol
> identifier.
> 
> As this could be extended to support other application protocols,
> it may be appropriate to move this discussion into another forum.

I wonder if the scope of our problem is really just differentiating
between TCP and TLS+TCP transports?  If so, then maybe having one extra
URL scheme per protocol is tolerable.  That simple solution has been
shown to work.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?