Subject: draft-ietf-ldapbis-url-04.txt comments

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Dec 2003 23:05:22 +0100

> 5.  URL Definition
> (...)
>   If an extension is unsupported by the client, the client MUST NOT
>   process the URL if the extension is critical.  If an unsupported
>   extension is non-critical, the client MUST ignore the extension.
>
>   If a critical extension cannot be processed successfully by the
>   client, the client MUST NOT process the URL. If a non-critical
>   extension cannot be processed successfully by the client, the client
>   SHOULD ignore the extension.

I'm not sure what the difference is between 'unsupported' and 'cannot be
processed successfully'?  These paragraphs seem to say the same thing
except that for the final MUST vs. SHOULD.

Editorial comments:

> 3.  Table of Contents
> (...)
> 5.1.      Escaping Using the Method.................................4
                             ^^^
                          Missing '%'.

> 6.  Defaults for Fields of the LDAP URL
> (...)
>   Note:  other documents MAY
>   specify different defaulting rules; for example, section 4.1.11 of
>   [Protocol] specifies a different rule for determining the correct DN
>   to use when it is absent in an LDAP URL that is returned as a
>   referral.

Section 4.1.10.

> 7.  Examples
> (...)
>  ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04)
>  IP The filter in this example uses the LDAP escaping mechanism of \

Remove "IP".  Suggest to split the URL in front of one of the '?'s.

> 9.  Normative References
> (...)
>   [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
>    Considerations for the Lightweight Directory Access Protocol
>   (LDAP)", RFC 3383, September 2002.

This should be draft-ietf-ldapbis-bcp64-01.txt.

-- 
Hallvard

---

From: Mark Smith <[email-masked]>
Date: Fri, 12 Dec 2003 09:47:01 -0500

> except that for the final MUST vs. SHOULD.

I suspect the intent was to distinguish between extensions that a client 
understands but can't process vs. extensions the client is not even 
aware of.  But now that you mention it, the distinction does not seem 
important.  I think we can delete the first paragraph.

>>5.1.      Escaping Using the Method.................................4

Good catch.  That was caused by a bug in my TOC generation script.

>>  to use when it is absent in an LDAP URL that is returned as a

OK; will fix.

> Remove "IP".  Suggest to split the URL in front of one of the '?'s.

OK.

> This should be draft-ietf-ldapbis-bcp64-01.txt.

OK.

Thanks for your detailed review!

-Mark

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 13 Dec 2003 12:31:24 -0800

At 06:47 AM 12/12/2003, Mark Smith wrote:
>I suspect the intent was to distinguish between extensions that a client understands but can't process vs. extensions the client is not even aware of.  But now that you mention it, the distinction does not seem important.  I think we can delete the first paragraph.

I would prefer to use language like to that of governing
criticality of controls:
    If the extension is recognized it implementation MUST make
    use of it.  Otherwise (the extension is not recognized),
    the implementation MUST error if critical and MUST ignore if
    if not critical.

Kurt

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Dec 2003 14:23:07 -0500

>     the implementation MUST error if critical and MUST ignore if

I am OK with this suggestion.  Note that the current text we are 
replacing uses SHOULD in some places, e.g., "The client SHOULD obey 
supported extensions that are non-critical."  I am not sure if the 
interoperability concerns are high enough to warrant the use of MUST... 
but the same rationale that was applied to the protocol document 
probably applies here as well.

-Mark

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Dec 2003 11:50:20 -0800

At 11:23 AM 12/16/2003, Mark Smith wrote:
>I am OK with this suggestion.  Note that the current text we are replacing uses SHOULD in some places, e.g., "The client SHOULD obey supported extensions that are non-critical."  I am not sure if the interoperability concerns are high enough to warrant the use of MUST... but the same rationale that was applied to the protocol document probably applies here as well.

And security considerations.

Say someone adds an URL extension "starttls" which means
to Start TLS.  I would think it unwise to ignore "!starttls".
Given that ! means critical, I think MUST is quite appropriate.

Kurt