RE: LDAP URI scheme that specify alternative transport protocols

[Alexis Bor <alexis.bor@directoryworks.com>]

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:kurash@sassafras.com]
Sent: Tuesday, November 30, 1999 7:56 PM
To: Kurt D. Zeilenga
Cc: ietf-LDAPext@netscape.com
Subject: Re: LDAP URI scheme that specify alternative transport
protocols



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.