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

From: Mark Smith <[email-masked]>
Date: Wed, 03 Nov 2004 12:02:26 -0500

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

---

From: Steven Legg <[email-masked]>
Date: Fri, 05 Nov 2004 09:43:46 +1100

Mark & Kurt,

>>>>         extype        = <oid from section 1.4 of [Models]>

This isn't ABNF. I much prefer this:

    extype = oid ; from section 1.4 of [Models]

or this:

    extype = oid

    The <oid> rule is defined in [Models].

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 04 Nov 2004 16:34:13 -0800

At 02:43 PM 11/4/2004, Steven Legg wrote:
>This isn't ABNF.

Technically, this is a <prose-val> [RFC 2234]:
        prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                               ; bracketed string of SP and VCHAR
                                  without angles
                               ; prose description, to be used as
                                  last resort

But I agree that we should avoid use of <prose-val> here
and elsewhere in this grammar.

>I much prefer this:

---

From: Mark Smith <[email-masked]>
Date: Fri, 05 Nov 2004 09:01:06 -0500

> and elsewhere in this grammar.

That would be a good thing.  I will switch to the form Steven suggests, 
e.g.,

-Mark