Subject: Specifying non-tcp transports referrals

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 24 Jun 2003 12:12:54 -0600

All,

Currently, either an LDAPURL or "Other kind of URL" may be specified in
an LDAP referral.

I believe it's assumed that the address in an LDAP URL
(draft-ietf-ldapbis-url-03.txt) points to an LDAP server capable of
communicating over TCP/IP. This is probably a bad assumption.

If/when someone wants to specify a non-TCP transport be used to follow
a referral, how would that be done? So far, all I can think of is to use
different URI schemes like:

ldap.udp
ldap.mobileip

Is there another way I'm not seeing?

Also, in [Protocol], there is this wording (Section 4.1.10)
>URLs for servers implementing the LDAP protocol are written according

>to [LDAPURL]. 

and

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

This implies (maybe it's more than an implication) that if the LDAP
protocol is to be used, the Referral will adhere to [LDAPURL]. This
means an ldap referral shouldn't contain a scheme like "ldaps". I think
the wording is either unclear or too restrictive. Why shouldn't I be
able to name a server supporting the LDAP protocol using some non
[LDAPURL] URI?

Jim

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 24 Jun 2003 15:23:41 -0400

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Sermersheim
Sent: Tuesday, June 24, 2003 2:13 PM
To: [email-masked]
Cc: Steve McLain; Tom Doman
Subject: Specifying non-tcp transports referrals

All,

ldap.udp
ldap.mobileip

==============================================================

Not if you want to comply with the specs as written.

The only other way I can think of is to use a labeledURI
such as ldap://host.name[udp] or ldap://host.name[mobileip].
The drawback is that you have to analyze content further
down in the string to determine what transport to use.

I acknowledge that this could represent significant
changes to various documents (and implementations)
including [LDAPURL]. But it is another way of solving
the general problem you describe below.

And I haven't sorted through the non-referral-related
issues with using the label in this way. It may make
more sense to use something like:

ldap://host.name[transport-udp]

That would seem to solve the more general problem below and
avoid confusion over more human-friendly uses of the label
value.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

==============================================================
Also, in [Protocol], there is this wording (Section 4.1.10)

and

Jim

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 24 Jun 2003 15:52:20 -0500

> different URI schemes like:

This is a problem for other schemes that can use multiple transport
protocols already. RFC 3263 defines a mechanism using NAPTR and SRV RRs to
handle this problem with SIP and is being advocated by some folks for use
with other services. My own personal preference would be to modify the
scheme descriptor to include a transport (eg ldap/tcp://host:port/...)
since that would be the cleanest service/proto mapping.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Mark C Smith)
Date: Tue, 24 Jun 2003 22:42:16 -0700

>>communicating over TCP/IP. This is probably a bad assumption.

Why is that a bad assumption? If and when someone wants to use URLs that 
support LDAP over a non-TCP transport, they can define an LDAP URL 
extension or a new URL scheme (as both Jim and Eric suggested). I do not 
think the LDAPBis documents need to say much if anything about this.

-Mark