Subject: LDAP URI scheme that specify alternative transport protocols

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 30 Nov 1999 19:05:58 -0800

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?]

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

---

From: Mark Valence <[email-masked]>
Date: Tue, 30 Nov 1999 22:56:28 -0500

Kurt-

>where transport is tcp, tls, ipc or other transport protocol

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.

---

From: "Alexis Bor" <[email-masked]>
Date: Tue, 30 Nov 1999 20:13:17 -0800

I'm involved in a group (Business Quality Messaging Forum, or BQM for
short).  We are currently looking at ways of doing LDAP calls through a
store/forward messaging middleware technology, such as IBM's MQseries or
Microsoft's MSMQ, or many of the other store/forward products.  The idea is
that you can issue an LDAP call to a queue that is connected to one or more
networks or brokers that are not available to the LDAP call issuer.  We see
this as a strong need for many business to business E-commerce applications.

We would be very interested in a URI mechanism for messaging middleware.

-- Alexis

-----Original Message-----
From: Mark Valence [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 7:56 PM
To: Kurt D. Zeilenga
Cc: [email-masked]
Subject: Re: LDAP URI scheme that specify alternative transport
protocols

Kurt-

     ldap.tls://host:port/

and so on.

     ldap.udp://host:port/

Regards,

Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 30 Nov 1999 20:18:25 -0800

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

> 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

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.