Subject: Re: small inconsistency in http://www.openldap.org/ietf/ldapbis/dn.txt

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 11 Jul 2005 17:50:23 -0600

The SHOULD from Section 2.4 has been removed (was in RFC 2253, but gone
in the latest I-D). Is that the SHOULD you are referring to?
 
<getting slightly off track>
I'm not sure why the SHOULD was removed (nor do I know why the
suggestion was there in the first place). It seems useful to separate
the reasons for using numeric oids in the attributeType from the reasons
for using the hexstring/BER form in the attributeValue. 
 
<back to the point>
If there is no SHOULD, I expect some producers and consumers will be
written to expect a hexstring value to follow any numericoid
attributeType. My preference would be to add the SHOULD back where it
was in RFC 2253.
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 7/11/05 11:55:51 AM >>>
At 10:29 AM 7/11/2005, Jim Sermersheim wrote:
>The last valid DN test is this:
> 1.1.1= // empty value [AoO]
> 300A31083006060229011300 [AoO]
>
>Section 2.4 says that when the numeric oid form is used for the
attribute value, then the value is #<ber-octets>.

If we're generating the string per section 2, yes. But that's
only a SHOULD. The dn.txt includes parsing tests for OPTIONALly
generated strings. That is,
1.1.1=
is a valid RDN string per the Section 3 ABNF.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Jul 2005 09:02:31 +0200

At 01:50 AM 7/12/2005, Jim Sermersheim wrote:
>The SHOULD from Section 2.4 has been removed (was in RFC 2253, but gone in the latest I-D). Is that the SHOULD you are referring to?

In section 1:
  Section 2 details the RECOMMENDED algorithm for converting a DN
  from its ASN.1 structured representation to a string.

>I'm not sure why the SHOULD was removed (nor do I know why the suggestion was there in the first place). It seems useful to separate the reasons for using numeric oids in the attributeType from the reasons for using the hexstring/BER form in the attributeValue. 

All of Section 2 is considered a SHOULD.  The key MUST is:
   While other documents may define other algorithms for
   converting a DN from its ASN.1 structured representation to
   a string, all algorithms MUST produce strings which adhere
   to the requirements of Section 3.

Kurt