Re: LDAP URL Format

Paul Hoffman (ietf-lists@proper.com)
Sun, 7 May 1995 17:29:40 -0700


Message-Id: <v02120c08abd30f85da66@[165.227.40.11]>
Date: Sun, 7 May 1995 17:29:40 -0700
To: "Tim Howes" <tim@umich.edu>
From: ietf-lists@proper.com (Paul Hoffman)
Subject: Re: LDAP URL Format
Cc: uri@bunyip.com

Sorry for taking so long to get back to you on this proposal (although I
noticed that no one else jumped in yet...). In all, I think it looks quite
good. I'm not yet an X.500 dweeb, but I imagine that you have plenty of
those in the ASID WG looking out for the X.500 parts of this.

Folks in the URI WG should be aware that there is another X.500ish I-D that
relates to URIs, namely draft-ietf-asid-x500-url-01.txt.

>...This  document  describes  a  format for an LDAP Uniform Resource
>Locator which will allow World Wide Web clients to have direct access to
>the  LDAP protocol.

I'd replace "World Wide Web" with "Internet" because there are now many
non-Web clients that understand URLs.

>An LDAP URL begins with the protocol prefix "ldap" and is defined by the
>following grammar.
>
>    <ldapurl> ::= "ldap://" [ <hostport> ] "/" <dn> [ "?" <attributes>
>                        [ "?" <scope> "?" <filter> ] ]

The use of multiple question marks with possibly nothing between them bugs
me a bit here, but I don't have a better delimiter in mind. This might just
be a visual thing for me.

>... with any URL-illegal charac-
>ters (e.g., spaces) escaped using the % method.

... described in RFC 1738.

>Note that if the entry resides in the  X.500  namespace,  it  should  be
>reachable from any LDAP server that is providing front-end access to the
>X.500 directory.  If the <hostport> part of the URL is missing, the  URL
>can be resolved by contacting any X.500-back-ended LDAP server.

Should there be a description (or a reference) of how "any X.500-back-ended
LDAP server" will resolve the URL? Must *all* such servers resolve requests
that come from anywhere?

>5.  Security Considerations
>
>Security considerations are not discussed in this document.

Should they be? Is there any additional security problems of forcing any
LDAP server to resolve URLs that aren't for that host? If not, you might
just point to the X.500 RFC that has the most complete security section.

>7.  Bibliography

I noticed a couple of RFCs referred to in the draft that didn't appear in
the bibliography, such as 1487 and 1558 (and 1738 that I suggested above).


--Paul Hoffman
--Proper Publishing