Subject: RE: AttributeTypeValue and binary

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 25 Jan 2001 12:24:30 +1100

Kurt,

Jim did write 'unless an option is present'. He didn't cover the case of
binary syntax, either. Anyway, I like it.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, 25 January 2001 12:12
To: Jim Sermersheim
Cc: [email-masked]; [email-masked]
Subject: Re: AttributeTypeValue and binary

At 05:52 PM 1/24/01 -0700, Jim Sermersheim wrote:
>My suggested change is the result of trying to keep the existing wording
intact as much as possible, and also not address any issues other than the
wrapper confusion. Another wordy possibility is:
>
>A field of type AttributeValue is an OCTET STRING containing an encoding of
the value syntax of the companion attribute type. When the syntax of an
attribute type defines a string encoding, that encoding is used unless an
option is present in the companion AttributeDescription which overrides the
string-based encoding. For example, if the "binary" option is present, the
value will be the binary encoding of the value.
>
>This addresses the "wrapper" issue, the "default encoding" issue, and the
"future encodings" issue.

This has the problem in that the default encoding for certificate
is binary.  That is, when all attributes are requested and the
entry contains a userCertificate attribute, the attribute should
be returned as userCertificate;binary.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Jan 2001 17:58:20 -0800

At 12:24 PM 1/25/01 +1100, Ramsay, Ron wrote:
>Jim did write 'unless an option is present'.

userCertificate is to be transferred using the binary option
regardless of whether the binary option is present in the request.

>He didn't cover the case of binary syntax, either.

good.

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 25 Jan 2001 14:09:37 +1100

Kurt,

> regardless of whether the binary option is present in the request.

RFC 2252, Section 6.5 says userCertificate MUST be *requested* as
userCertificate;binary as well, but since I've encountered clients that
use userCertificate with the values BER encoded I'm not against relaxing
this apparent restriction.

A couple of questions come to mind. If an attribute's syntax has no
string encoding (like Access Point) must the attribute be requested
and returned with the ;binary option ? What about attributes with the
Binary syntax ? Consistency would require that they be requested
with the ;binary option as well.

I'm happy for the attribute to be returned as requested, with or without
the ";binary" option, with the default encoding applying where there
is no encoding option given. The only thing this would break is clients
that ask for, e.g. userCertificate, but expect to be returned
userCertificate;binary. According to 6.5 these clients are already broken.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Jan 2001 19:29:40 -0800

I withdrawn this issue.  I had reviewed the suggestion in an
incorrect context.

I have no objection to Jim's last suggestion.  I also agree
with Steven in regards to "binary" vs "BER".