[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: I-D ACTION:draft-ietf-ldapbis-url-07.txt

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