Re: LDAP URI scheme that specify alternative transport protocols

["Kurt D. Zeilenga" <kurt@boolean.net>]

Mark Valence wrote:
> 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.

A "+", like ".", is an allowed character of a scheme.  If a URL
parse cannot handle "+" in schema today, well, it's broken.
However, "." is just as good as "+".   Maybe we can "." for
subprotocols and "+" for options.

	LDAP+3.TLS+des3.TCP+nodelay://...

A bit sick but at least it would provide uniform support
for subprotocols and options.

> Using [ ] or any other paired symbols requires specification of the
> behavior when the right-hand symbol is missing.

This alternative was suggested to avoid using characters
already reserved for scheme.  It's similiar to how IPv6 addresses
are being added to the host part.

> Simplest would be to reject the URL,
> but smart clients might try to correct the mistake.

The key is not to allow ":" inside of the [ ] so that it's easier
to detect and correct the error.

> What about when choice of lower level protocols affects the higher
> level protocol, as in:
> 
>      ldap.udp://host:port/

That protocol binding makes no sense.

> Should this mean CLDAP?

No, CLDAP is a different protocol with it's own encoding requirements.

> Or should such a combination not be allowed.

For a stream based protocol such as LDAP, yes, it should be disallowed.