Subject: RE: AttributeTypeValue and binary

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 26 Jan 2001 17:53:37 -0700

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. That's fine with me. 

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). If we want to shut that door, or don't think there was, is, or ever will be a door there to open, I'll fix.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/26/01 1:42:51 PM >>>
At 10:36 AM 1/26/01 -0700, Jim Sermersheim wrote:
>Help me understand what your saying, are you saying this?
>
><<
>I think you are now confusing the relationship between:
>
>1) the transfer encoding and the attribute description (4.1.6) and
>
>2) issues dealing with requested (implicit or explicit) attribute descriptions v. returned attribute descriptions (which is what I did previously).
>>>
>
>If so, I'm trying to address #1, not #2.

Yes.  We are currently only attempting to address #1.

>Help me understand what it is in the paragraph that makes one think about #2.

Because you say "that (default) encoding is used an transfer option is not present".
No, if a transfer option is not present, the string encoding is used regardless of
of whether it is the default or not.  That is, the default encoding could be either
a "string encoding" or a "binary encoding" (;binary) [and that relates to issue #2].

>>>> "Kurt D. Zeilenga" <[email-masked]> 1/25/01 10:41:32 PM >>>
>At 09:16 PM 1/25/01 -0700, Jim Sermersheim wrote:
>>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 BER encoding of the value. 
>>
>>The definition of encodings for different syntaxes and types may be found in other documents, and in particular [RFC2252].
>
>Hmm... I'm not sure I'm happy with this.  I think you are now
>confusing the relationship between the transfer encoding
>and the attribute description (4.1.6) and issues dealing
>with requested (implicit or explicit) attribute descriptions
>v. returned attribute descriptions (which is what I did
>previously).
>
>Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Jan 2001 17:33:14 -0800

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.

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

Kurt