- From: Paul Hoffman <ietf-lists@proper.com>
- Date: Sun, 7 May 1995 17:29:40 -0700
- To: "Tim Howes" <tim@umich.edu>
- 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
Received on Sunday, 7 May 1995 20:28:46 UTC