|
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" <Kurt@OpenLDAP.org> 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 |