Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-dn-05.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:30 AM 5/11/01, Timothy Hahn wrote:

>Greetings, 
>
>I have only a couple of comments on this Internet Draft: 
>
>Section 2.3, second paragraph - "otherwise it is encoded ... "  Does "is" mean MUST or SHOULD? 

First, section 2 as a whole is a SHOULD per last sentence of section 3.
(I suggest s/algorithm/RECOMMENDED algorithm/ in last sentence of
section 2 to make this clear).  This requirement is imposed for
interoperability reasons (I note that Section 4 of RFC 2253 had a
similar requirement at MUST but the WG consensus was that MUST was
too strong).

An imperative was not used here, per RFC 2119:
   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is   
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for interoperability.

That is, there may be other methods for generation of the string
representation of a DN and that's fine (as long as they can be
recognized per Section 3).

I note that there is a "SHOULD" and a "MAY" elsewhere in Section
2.  Likely these should be replaced with non-RFC 2119 imperatives.
I would consider this (and the above) edit to be a minor change.

>Section 2.4, third bullet - should equals (=) be included in this list? 

No.  It is not required to escape equal signs within values
('=' is not in "escaped" production). 

I note that RFC 2253's ABNF required '=' (as well as non-leading '#')
to be escaped but RFC 2253's Section 2 clearly allows '=' (as well
as non-leading '#') to used unescaped.  In this I-D, the ABNF was
made consistent with Section 2 as this is the RECOMMENDED method
for generating DNs.  The alternative, requiring '=' (as well as
non-leading '#') to be escaped, would like have rendered many
existing implementations non-complaint.  It is noted that existing
implementations generally don't care of '=' (as well as non-leading
'#') are escaped or not.

>Section 4 - would it be possible to add an example of a DN where one of the RDNs contains an attribute type which has distinguishedName syntax? 

 1.1.1=#abcdef,dc=example,dc=net

 where 1.1.1 is an attribute type of distinguishedName syntax
 and abcdef is the base64 representation of the BER encoding of
 the value used for naming.

I note there is an octet string syntax example.  I rather not
add a distinguishedName value as it has a complex ASN.1 data
type definition.
        
Kurt