[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: DN revision
Hi Kurt!
There's still a problem because the first sentence of 2.4 says that the
attribute value does not have a string representation, which is not the
case for directoryString.
What am I missing?
Thanks,
Kathy
"Kurt D. Zeilenga" wrote:
>
> 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.