Subject: LDAP URLs "loose ends" comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 Feb 2001 20:52:02 -0800

Mark's "strawman" proposal lists a few "loose ends"
<draft-smith-ldapv3-url-update-01.txt, Section 15>.

Search URL v. Referral URLs
  I believe this issue should be tied off as discussed
  in the thread:
    http://www.openldap.org/lists/ietf-ldapbis/200010/msg00034.html

Other Extensions
  I believe it best to view any new LDAP URL extensions,
  including those providing SASL and Start TLS mechanisms,
  as "new features" and hence out of scope of this working
  group.

update RFC1738 reference to RFC2396
  Yes.

<userinfo>@<host>:<port>
  I suggest this TS not exclude a future document from
  specifying use of this construct.

BNF -> 2234 form
  Please.

---

From: Mark Smith <[email-masked]>
Date: Wed, 21 Feb 2001 15:34:33 -0500

>     http://www.openldap.org/lists/ietf-ldapbis/200010/msg00034.html

I agree.

>   as "new features" and hence out of scope of this working

I agree, although we should consider working this outside of ldapbis.

> update RFC1738 reference to RFC2396

Okay.

>   specifying use of this construct.

Okay, but I am not sure how to handle this.  Should we include a
statement in the LDAP URL document that says "if <userinfo>@ is present,
it should be ignored?"  Or "if present, the URL can't be interpreted?" 
Or ?

>   Please.

I am working on it.

-Mark

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Feb 2001 13:07:10 -0800

>it should be ignored?"  Or "if present, the URL can't be interpreted?" 

Well, after re-reading 2396, I believe the best thing to do is
leave the syntax alone.

We could note that future specifications may replace "hostport"
with "server" (and provide the necessary specification of "userinfo").
With this statement, a cautionary note would be needed stating that
users must not assume implementations support userinfo.

Another approach is not to mention this at all...

Either approach is fine with me.

As previously noted, it would be interesting to draft
a userinfo specification supporting TLS/SASL features
in a application protocol neutral manner.