[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: I-D ACTION:draft-ietf-ldapbis-url-07.txt
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: Re: I-D ACTION:draft-ietf-ldapbis-url-07.txt
- From: Mark Smith <mcs@pearlcrescent.com>
- Date: Wed, 03 Nov 2004 12:02:26 -0500
- Cc: ietf-ldapbis@OpenLDAP.org
- In-reply-to: <6.1.2.0.0.20041029154203.02f0fe88@127.0.0.1>
- References: <200410252003.QAA29281@ietf.org> <6.1.2.0.0.20041025133320.0347b3d8@127.0.0.1> <6.1.2.0.0.20041029154203.02f0fe88@127.0.0.1>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Kurt D. Zeilenga wrote:
I have completed my review of the I-D. While it's my personal
opinion that the revisions made are consistent with WG
consensus, I did find a few minor problems which likely
should be addressed prior to progression. Most significantly,
a few aspects of the I-D need updated to be consistent with
the ABNF definitions of [Protocol] and [Models]. I suggest
the <extype> rule be clarified and examples changed slightly
to demonstrate case-insensitive. I also make a few editorial
suggestions to improve clarity and/or to remove nits. See
attachment for details.
Thanks for your detailed review of this I-D as well. My detailed
replies are inline below, prefaced with [mcs]. I will likely revise and
submit updated drafts for both this document (URL) and the filter
document in the next couple of weeks, so if anyone else has comments
please let me know.
...
Abstract
This document describes a format for an LDAP Uniform Resource Locator
(URL). An LDAP URL describes an LDAP search operation that is used
Spell LDAP out of first use.
[mcs] OK.
>>> ...
13. Appendix B: Changes Since Previous Document Revision...........13
13.1. Editorial Changes...........................................14
14. Intellectual Property Rights...................................14
15. Full Copyright.................................................14
Last sections should be unnumbered.
[mcs] OK.
...
1. Introduction
LDAP is the Lightweight Directory Access Protocol, defined in
[Protocol].
s/[Protocol]/[Roadmap]/
[mcs] OK.
This document specifies the LDAP URL format for version
3 of LDAP and clarifies how LDAP URLs are resolved. This document
also defines an extension mechanism for LDAP URLs, so that future
documents can extend their functionality, for example, to provide
access to new LDAPv3 extensions as they are defined.
s/their/the/ (extensions extend the base functionality)
Actually, rewriting the sentence as follows may be appropriate.
This document also defines an extension mechanism for LDAP URLs.
This mechanism may be used to provide access to new LDAP
extensions.
[mcs] I like your suggested re-wording. Let's use it.
I suggest inserting a paragraph break here.
[mcs] Good idea.
>>> ...
Note: not all
^
Remove extra space. I also suggest s/Note:/Note that/.
[mcs] OK.
of the parameters of the LDAP search operation described in
[Protocol] can be expressed using the format defined in this
document.
It maybe appropriate to add the following to this paragraph:
Note also that URLs may be used to represent reference
knowledge, including for non-search operations.
[mcs] I am OK with adding this. Any objections? LDAP URLs are widely
used to represent configuration information also, which is similar to
the reference knowledge kind of use.
...
attrdesc = <AttributeDescription
from Section 4.1.4 of [Protocol]>
/ ASTERISK
; See the "Escaping Using the % Method"
; section below.
This should be:
attributes = selector *(COMMA selector)
selector = <attributeSelector from Section 4.1.4 of [Protocol]>
; See the "Escaping Using the % Method"
; section below.
[mcs] You are correct. Also, in protocol-27 the section is 4.5.1
instead of 4.1.4. I will make the appropriate changes.
...
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
; See the "Escaping Using the % Method"
; section below.
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
This should just be:
extype = <oid from section 1.4 of [Models]>
[mcs] Right.
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
; See the "Escaping Using the % Method"
; section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [LDAPIANA]>
With the above change, <oid> and <oiddescr> rules here can
be deleted.
[mcs] Yes. These were kind of ugly anyway, so it is nice to be able to
just reference [Models].
EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERISK = %x2A ; asterisk ("*")
Can be dropped if the above changes are implemented.
[mcs] I will drop ASTERISK.
...
I suggest wrapping all ABNF rule names appearing in the prose
using <>.
[mcs] Yes, that would be best. I will do so.
>>> ...
The extension type (extype) MAY be specified using the oid form
s/oid/numeric OID <numericoid> form/ (likewise below)
(e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
s/oiddesc/descriptor <descr> form/ (likewise below)
s/./ of the <oid> production [Models]./
[mcs] Right. I do not think we use <oid> or <oiddesc> anywhere else in
the document.
...
ldap://ldap1.example.com/c=GB?objectClass?one
Please s/ldap:/LDAP:/ and s/one/ONE/ to demonstrate case insensitive.
[mcs] Good idea.
>>> ...
ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)
The filter in this example uses the LDAP escaping mechanism of \ to
encode three zero or null bytes in the value. In LDAP, the filter
would be written as (four-octet=\00\00\00\04). Because the \
character must be escaped in a URL, the \'s are escaped as %5c in the
URL encoding.
s/%5c/%5c (or %5C)/
I suggest that you use uppercase hex values in a subsequent
example.
[mcs] OK. That is easily done.
[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
With above changes, can be informative.
[mcs] Right. Good catch!
Thanks!
-Mark