[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: AttributeTypeValue and binary
Sounds good. Where do you suggest the statement go?
1) We can make the AttributeValue definition in 2251 generic and state that it holds either the default encoding, or some other encoding specified by a transfer option, then defer to 2252 for statement you propose. Or,
2) We can include your proposed statement into the AttributeValue definition in 2251.
I prefer 1 as 2252 already has some language that hints at it, but I'm not against 2.
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/25/01 4:29:48 PM >>>
At 04:12 PM 1/25/01 -0700, Jim Sermersheim wrote:
>Wait, before you withdraw, one question. Does the spec state that all syntaxes MUST be defined with either a string encoding or an encoding whos transmission is signified by an AttributeDescription.option?
Well, some means for transfer of values must be defined but, IIRC,
this is not an explicit statement to this effect. I think there
is an assumption made in RFC 2252 in that if there is not a string
encoding defined, the syntax is transferred using the binary
transfer option and BER encoded.
As I noted in:
http://www.OpenLDAP.org/lists/ietf-ldapbis/200101/msg00054.html
I believe we should consider adding to the specification
statements which say:
1) each syntax has a default encoding which is to be
used unless the client requests an alternative encoding, and
2) a syntax's default encoding is its string encoding unless
stated otherwise.
>If not, I believe we need to amend my suggested paragraph.
>
>Note that your read of my question here is subject to your interpretation of the term "string encoding". I believe "string encoding" means nothing more than the fact that there's some way to string together octets to form a defined syntax. The octets may contain any value (as long as they meet the syntax requirement).
>
>Jim
>
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/24/01 8:29:40 PM >>>
>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".