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

RE: AttributeTypeValue and binary



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" <Kurt@OpenLDAP.org> 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" <Kurt@OpenLDAP.org> 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