[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DN revision



At 11:17 AM 4/18/01, Kathy Dally wrote (in part):
>However, I'm confused by section 2.4.  Here's an example:
>
>The example attribute type is initials and the value is "KL".
>
>The system recognizes the initials attribute.
>
>Sending
>        First paragraph of 2.4 says AttributeTypeAndValue SHOULD be:
>                2.5.4.43=#04024B4C

Note that initials is of directoryString syntax not octetString so
that hex encoding is incorrect.  But that's another matter.
Maybe I'll add a directoryString # example to the I-D.

>        Second paragraph of 2.4 says representation is:
>                2.5.4.43=KL
>
>        WHICH ONE IS SENT?

The former SHOULD be sent per last sentence of first paragraph.


>Receiving
>        Plus, the alternative given in the new paragraph of section 3, allows a
>keyword, 
>        such as, the attribute type name specified in RFC 2256, to be the
>AttributeType:
>                initials=KL

or
        initials=#....


>        WOULD ALL THREE BE ACCEPTED ON RECEPTION?

The "initials=" forms may not be as there is no requirement
to recognizes "initials" as an attribute string name in this
context.  I hope the latest Section 3 text I offered in
response to Jim's concerns.

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2.3 table, but MAY recognize other
  names.  Implementations MAY recognize other DN string representations
  (such as that described in RFC 1779). As there is no requirement
  for other names or alternative DN string representations be
  recognized, implementations SHOULD only generate DN strings in
  accordance with Section 2 of this document.