Re: LDAP URI scheme that specify alternative transport protocols

[Mark Valence <kurash@sassafras.com>]

Kurt-

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

I have a few comments and some questions.

One potential problem is that "+" can be used in some cases to denote 
a space.  This would require special casing in URL decoders, which 
would need to replace + with space except in the protocol designator. 
Is this already necessary anyway for domains with +'s in them?

Using [ ] or any other paired symbols requires specification of the 
behavior when the right-hand symbol is missing.  Simplest would be to 
reject the URL, but smart clients might try to correct the mistake.

I suggest that you use ".", as in:

    ldap.tls://host:port/

The benefit is that dot is already used to separate components of 
domain names, file names, etc.

Also, how far down the protocol stack would you go?  For example, tls 
runs over tcp, but perhaps some future tls could run over other 
protocols.  Would you allow for something like:

    ldap.tls.spx://host:port/

You then need to define the default sub-protocols when they are not 
specified.  For example:

    ldap://...       -> ldap.tcp://...
    ldap.tls://...   -> ldap.tls.tcp://...

and so on.

What about when choice of lower level protocols affects the higher 
level protocol, as in:

    ldap.udp://host:port/

Should this mean CLDAP?  Or should such a combination not be allowed, 
since strictly speaking LDAP requires a reliable ordered transport?

Regards,

Mark.