Re: LDAP URI scheme that specify alternative transport protocols

[RL 'Bob' Morgan <rlmorgan@cac.washington.edu>]

TLS is not a transport protocol; it requires a stream-oriented transport
protocol underneath it to handle things like packet reordering, endpoint
addressing, etc.  TLS is a security-oriented session layer.  When we
considered this problem 2-1/2 years ago (see the ASID list archives from
early-mid 1997) we came to the conclusion that it is best to allow the use
of a session layer (ie, TLS) to be negotiated in-band rather than via port
probing.  This led to the ldapv3-tls spec (which was essentially finished
2 years ago), and the intentional removal of an ldaps: scheme from what
became RFC 2255.  The same approach has been taken with other application
protocols.  At this point there is no justification for an ldaps: URI
(other than historical), and many reasons why it's a bad thing to put into
practice, especially in knowledge references.  Even the HTTP group has
specified a way to negotiate TLS in-band due to the observed problems
that the https: scheme creates.

It might be useful to put something into a URI indicating that TLS should
be used by the URI interpreter.  This falls not into the category of
transport but into the category of specifying security policy (sorry, the
P-word again).  Any scheme to permit specifying security policy in a URI
would be woefully deficient if the only expression it allowed was "use
TLS".  The writer of a URI would also want to be able to specify what TLS
ciphersuites to use, whether to authenticate and how, what SASL mechanisms
are acceptable, etc.  There was some work along this line (I think in the
IMAP context) that I think fizzled due to the obvious complexity of this,
and the realization that jamming security policy into a URI is probably a
bad idea in most cases.  But it may be that the time is ripe to try this
again.

Regarding actual transport specs, like IPC or some store-and-forward
transport as Alexis suggests, note that according to RFC 2396 the part of
the URI that indicates the use of a particular IP-based transport is the
"hostport" construction:

      hostport      = host [ ":" port ]
      host          = hostname | IPv4address
      hostname      = *( domainlabel "." ) toplabel [ "." ]

I would think that the right way to indicate an alternative transport
would be to have some other format in this field that indicated the
transport and the params it needs.

 - RL "Bob"