- From: Tim Howes <tim@umich.edu>
- Date: Mon, 08 May 1995 13:57:55 -0400
- To: ietf-lists@proper.com (Paul Hoffman)
- Cc: uri@bunyip.com
> From: ietf-lists@proper.com (Paul Hoffman) > To: "Tim Howes" <tim@umich.edu> > 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. No problem. Thanks for the comments. I will incorporate them as indicated below. > 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. Right, this one defines an X.500 attribute type (and associated object class) for holding a URI in an X.500 entry. It also allows a text label, so the URI can be displayed with some chance of knowing what it points to (e.g., "Bob's Home Page" <url>). I'm sure ASID would appreciate any comments you have on this one as well. > >...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. Will do. > >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. If you have another suggestion, let me know. > >... with any URL-illegal charac- > >ters (e.g., spaces) escaped using the % method. > > ... described in RFC 1738. Will add. > >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? Yes, the idea is for a single namespace that looks and acts the same no matter what server you contact. So any X.500 LDAP server should know how to resolve it. > >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. I don't see any problems with that, but I do think it could use some words about the fact that we assume no authentication (i.e., there's no way to pass credentials). > >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). I'll add them. Thanks again for the comments, and let me know if you (or anybody else) have more! -- Tim
Received on Monday, 8 May 1995 13:58:12 UTC