Subject: Re: Specifying non-tcp transports referrals

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 Jun 2003 16:35:31 -0700

At 04:01 PM 6/27/2003, Jim Sermersheim wrote:
>But read a little further:
>>   URLs for servers implementing the LDAP protocol are written
>according
>>   to [9].  
>
>(where [9] is [LDAPURL])
>
>This means that URLs pointing to LDAP servers, follow [LDAPURL]. And if
>[LDAPURL] is only used for TCP/IP... Well, it means any URL to an LDAP
>server means TCP is used. This is too limiting (in my view).

Likely the above needs to be clarified with something like:
        URLs for servers implementing LDAP and accessible via
        TCP/IP (v4 or v6) are written according to [LDAPURL].

I think ldap:// needs to be viewed as providing a LDAP/TCP/IP
service locator and that LDAP over other transports locators
will use other schemes (e.g., ldaps://, ldapi://, ldap.sctp://,
or whatever) defined in other documents.  And Referrals and
Continuations may contain non-LDAP URLs (e.g., xdap:// ?).

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 27 Jun 2003 17:01:29 -0600

according

(where [9] is [LDAPURL])

BTW, I agree with the s/LDAPURL/URL in the ASN.1

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 6/27/03 3:43:54 PM >>>
At 11:39 AM 6/26/2003, Jim Sermersheim wrote:
>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: 

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
>should be called out.

Likely some clarification here is appropriate.

Kurt