Subject: Re: Specifying non-tcp transports referrals

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 26 Jun 2003 12:39:37 -0600

>The only well defined transport for LDAP is TCP. So I just assume that

>LDAP URLs must use TCP as a transport too. Are you saying that is too

>limiting?

I'm just saying that it's under specified or ambiguous (I actually
don't know if LDAP URLs can be used to specify transports other than
TCP--I'd like it to be able to).

The protocol doc says:
"This protocol is designed to run over connection-oriented, reliable
transports, with all 8 bits in an octet being significant in the data
stream."

It doesn't limit to TCP, but it does go on to define how things work
over TCP. So while TCP is the only well-defined transport, nothing
limits LDAP to run over some other transport (as long as it follows the
definition above).

The other problem is (and maybe this is really a problem to be solved
in [Protocol] is that a referral is a sequence of LDAPURL, where LDAPURL
follows [LDAPURL]. And also we see in the referral definition:

"Other kinds of URLs may be returned, so long as the operation could be
performed using that protocol."

To me, this means either [LDAPURL] needs to allow anything considered
as an "Other kind of URL", or [Protocol] needs to be fixed to allow
either URLs that follow [LDAPURL] or anything else.

I also thing that if [LDAPURL] is meant to implicitly specify TCP, it
should be called out.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 Jun 2003 14:43:54 -0700

>follows [LDAPURL]. And also we see in the referral definition: 

RFC 2251,
   LDAPURL ::= LDAPString -- limited to characters permitted in URLs

That is, an LDAPURL != [LDAPURL].   It might be wise to
s/LDAPURL/URL/ in the ASN.1.

>I also thing that if [LDAPURL] is meant to implicitly specify TCP, it

Likely some clarification here is appropriate.

Kurt