Subject: Re: AttributeTypeValue and binary

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 17 Jan 2001 16:51:20 -0500

Kurt,

Sounds ok to me.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     [email-masked]
cc: 
Subject:        AttributeTypeValue and binary

RFC 2251, 4.1.6:
   A field of type AttributeValue takes on as its value either a string
   encoding of a AttributeValue data type, or an OCTET STRING containing
   an encoded binary value, depending on whether the "binary" option is
   present in the companion AttributeDescription to this AttributeValue.
        AttributeValue ::= OCTET STRING

This wording can be interpreted as either:
   A field of type AttributeValue is an OCTET STRING which contains
   either a string encoding of a AttributeValue data type or an
   binary encoded value depending on whether the "binary" option is
   present in the companion AttributeDescription to this AttributeValue.

or:
   A field of type AttributeValue is an OCTET STRING which contains
   either a string encoding of a AttributeValue data type or an
   OCTET STRING containing an binary encoded value depending on
   whether the "binary" option is present in the companion
   AttributeDescription to this AttributeValue.

RFC 2252, 4.3.1 provides clarification that the correct interpretation
is the former.  I think RFC 2251 should be clarified to remove any
doubt.

Actually, I suggest that the description of the "binary" transfer
option be described completely within (and only within) RFC 2251
and that "binary" syntax be described within RFC 2252.

Also as previously noted on the LDAPext mailing list (see archives
for discussion), "binary" transfer of values of "binary" syntax
makes little sense and likely should be disallowed.

Comments?

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 17 Jan 2001 17:39:54 -0700

I agree on both counts.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/17/01 2:20:45 PM >>>
RFC 2251, 4.1.6:

or:

Comments?

---

From: "Salter, Thomas A" <[email-masked]>
Date: Thu, 18 Jan 2001 08:24:31 -0600

I agree.  I especially want to see the explanation that "binary" means "BER
encoding of an ASN.1 data type" included in the first reference to the
binary option.  First-time readers tend to think that binary means JPEGs and
other non-printable things.

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:[email-masked]]
 > Sent: Wednesday, January 17, 2001 4:21 PM

---

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 24 Jan 2001 20:50:51 -0500

Hi all,

Perhaps it would be good to add an example or two of the BER encoding for 
the different cases?

This would certainly help clarify the intent of the words.

Regards,
Tim Hahn

Sent by:        [email-masked]
To:     <[email-masked]>
cc:     <[email-masked]>, <[email-masked]> 
Subject:        Re: AttributeTypeValue and binary

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.

Jim

>>> Mark Smith <[email-masked]> 1/24/01 4:01:54 PM >>>
Jim Sermersheim wrote:
>
> I believe there is consensus regarding the first part of this message.
> That being that the first paragraph of section 4.1.6 is confusing, and
> leaves the reader unsure as to whether or not all binary encodings 
require
> an extra OCTET STRING wrapper.
>
> Unless there are objections, I will make the following change to the 
protocol > document:
>
> 4.1.6
> <A field of type AttributeValue takes on as its value either a string 
encoding of a AttributeValue data type, or an OCTET STRING containing an 
encoded binary value, depending on whether the "binary" option is present 
in the companion AttributeDescription to this AttributeValue.
> >A field of type AttributeValue is an OCTET STRING containing either a 
string encoding, or an encoded binary value of an AttributeValue data 
type, depending on whether the "binary" option is present in the companion 
AttributeDescription to this AttributeValue.

I think the revised text is better but still a little confusing and
awkward (although the OCTET STRING wrapper issue has been addressed).
At the risk of being "wordy" I suggest:

 If the companion AttributeDescription to an AttributeValue does not
 contain the "binary" option, then the AttributeValue field is an
 OCTET STRING that contains a string encoded value.

 If the companion AttributeDescription to an AttributeValue contains the
 "binary" option, then the AttributeValue field is an OCTET STRING
 that contains an encoded binary value of the AttributeValue data type.

-Mark

---

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

Kurt,

userCertificate is only to be transferred using the binary option.

This is a short cut for:

  Values are only transferrred as binary (except the binary syntax) if the
;binary option is used
  userCertificate must be transferred as binary

  Therefore, userCertificate must be transferred with the ;binary option.

I don't think there is any support for transferring syntaxes that may be
binary without the ;binary option.

Ron.

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

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: "Ramsay, Ron" <[email-masked]>
Date: Thu, 25 Jan 2001 14:20:39 +1100

Steven,

I believe that BER encodings (except the binary syntax) must be transferred
with the ;binary option. For the binary syntax I thought that the option
should not be sent though some on this list or the LDAPEXT list thought that
the relevant text was ambiguous. I think the LDAP founding fathers believed
that string encodings would exist for all attributes defined in LDAP. The
mirrored cracked on certificate syntax.

Ron.

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Thursday, 25 January 2001 14:10
To: 'Kurt D. Zeilenga'
Cc: [email-masked]
Subject: RE: AttributeTypeValue and binary

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: "Jim Sermersheim" <[email-masked]>
Date: Thu, 25 Jan 2001 15:48:25 -0700

There is no string encoding for userCertificate, thus binary is used. I'll amend the statement to reflect that the default encoding is used regardless of whether it's a string encoding or otherwise.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/24/01 6:12:14 PM >>>

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: "Jim Sermersheim" <[email-masked]>
Date: Thu, 25 Jan 2001 16:02:24 -0700

Yes, we should say "BER encoding" there. That would help push wandering minds in the right direction.

Jim

>>> "Steven Legg" <[email-masked]> 1/24/01 7:40:55 PM >>>

Jim,

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Jim Sermersheim
> Sent: Thursday, 25 January 2001 11:52
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> 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.

Can we say "BER encoding" instead of "binary encoding" ? The latter is
likely to cause confusion with arbitrary binary data, which should of
course be put in an attribute with Octet String syntax.

Regards,
Steven

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 25 Jan 2001 21:14:47 -0700

Okay. I've amended the prior proposal to this (it now includes the amended second paragraph):

A field of type AttributeValue is an OCTET STRING containing an encoding of the value syntax of the companion attribute type. The syntax of each attribute type defines a default encoding, that encoding is used unless an option is present in the companion AttributeDescription which overrides the default encoding. For example, if the "binary" option is present, the value will be the binary encoding of the value. 

The definition of encodings for different syntaxes and types may be found in other documents, and in particular [RFC2252].
<<

We don't actually need the "For example" part, but it's useful. Is it useful enough to include?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/25/01 5:18:55 PM >>>
At 04:56 PM 1/25/01 -0700, Jim Sermersheim wrote:
>Sounds good. Where do you suggest the statement go?

Well, I'm thinking the first part of my suggestion
belongs in 2251, it's clearly protocol semantics.
The second part needs to be part of the "syntax
profile" (what a syntax specification is required
to provide).  This likely should be in 2252.

Kurt

---

From: "Salter, Thomas A" <[email-masked]>
Date: Tue, 30 Jan 2001 10:38:47 -0500

> Sent: Friday, January 26, 2001 8:33 PM
 > To: Jim Sermersheim
 > At 05:53 PM 1/26/01 -0700, Jim Sermersheim wrote:
 > >Okay, so we're saying that when the default encoding is NOT 
 > a string encoding, it MUST be accompanied by an 
 > AttributeDescription.option that specifies the encoding.
 > 
 > Yes, certificate's default encoding is BER and ";binary" must be
 > specified.
 > 
 > >I wrote it in anticipation of there someday being an 
 > encoding which is not a string encoding, and also doesn't 
 > require an AttributeDescription.option. (ala something I 
 > read in 
 > http://www.OpenLDAP.org/lists/ietf-ldapbis/200101/msg00039.html).
 > 
 > I don't mind language that like:
 >   In the absence of an option specifying the transfer encoding
 >   (e.g. ";binary"), the string encoding is used.  Otherwise, the
 >   transfer encoding is that specified by the option.  Multiple
 >   options specifying transfer encoding MUST NOT be present.  At
 >   the time of this writing, there is only one option, ";binary"
 >   (4.1.5.1), which specifies the transfer encoding to be used.
 >

The wording here is not quite accurate.  Suppose all attributes are
requested with the * option.  Then each attribute must be encoded in its
default encoding.  For example, userCertificate;binary must be returned
since there is no string encoding for certificates.

I've also noticed that RFC2256 is explicit about userCertificate (and
others) always being requested and returned as binary.  However, RFC2252 is
a bit ambiguous.  In the Certificate syntax description in 6.5, it says, 
"... and values in this syntax MUST only be transferred using the binary
encoding, by requesting or returning the attributes with descriptions
"userCertificate;binary" or "caCertificate;binary".  "
This could be interpreted as allowing an attribute to be requested as
"tomsCertificate" and to be returned as "tomsCertificate;binary".

Are we trying to prevent this?  If so RFC2251 must be changed.  In 4.1.5, it
says "An AttributeDescription with one or more options is treated as a
subtype of the attribute type without any options."  In X.500, at least,
subtypes are returned when an attribute type is requested.

 > I don't view rfc2251 as disallowing additional options specifying
 > alternative transfer encoding.
 > 
 > Kurt
 >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 30 Jan 2001 08:00:22 -0800

At 10:38 AM 1/30/01 -0500, Salter, Thomas A wrote:
>requested with the * option. 

That's a different discussion.  Here were talking only about
the relationship with the returned AttributeDescription associated
with the returned AttributeValue in section 4.1.6. 

>Then each attribute must be encoded in its

---

From: "Salter, Thomas A" <[email-masked]>
Date: Tue, 30 Jan 2001 12:30:06 -0500

> Sent: Tuesday, January 30, 2001 11:00 AM
 > To: Salter, Thomas A
 > Cc: Jim Sermersheim; [email-masked]

Ok, now that I understand the discussion, I'll try again. :-)

The wording suggested above got me into the wrong discussion because phrases
like "... encoding to be used" seem to indicate a request for an encoding.  

If this language is going into 4.1.6, how about rewording it as:

In the absence of an option specifying the transfer encoding (e.g.
";binary"), the AttributeValue is encoded using the string encoding.
Otherwise, the transfer encoding is that specified by the option.  Multiple
options specifying transfer encoding MUST NOT be present.  At the time of
this writing, there is only one transfer encoding option, ";binary"
(4.1.5.1).

Then it also needs to be repeated or referenced so it applies to
AssertionValue in 4.1.7 as well.