[Date Prev][Date Next]
Re: interoperability of ;binary
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/3/01 2:52:15 PM >>>
>At 12:18 AM 4/3/01 -0600, Jim Sermersheim wrote:
>>Supposing that we do away with ;binary, would that imply that there must be string encodings for all syntaxes?
>Yes. Some might be BER/DER string encodings as was done
>in LDAPv2 for userCertificates (RFC2559).
>>I'd personaly rather make a distinction between subtyping and non-subtyping options so we can leave the door open for tranfer options.
>Making a distinction in RFC2251bis scares me. One has to
>go down the path of whether there multiple kinds of subtyping
>and non-subtyping options. That is direct vs non-direct
>subtyping options. Or, transfer options which act like
>subtyping options in some contexts but not in others. We
>end up having to redesign the feature, hence the protocol.
>It's a slippery slope that I rather not step down into.
I agree that it has the smell of introducing complexities that were not there to begin with.
>However, I am also quite willing to consider other options...
>I'll even offer another one myself:
> An AttributeDescription with one or more options is
> treated as a subtype of the attribute type without
> any options.
> The relationship between an AttributeDescription with
> one or more options with an AttributeDescription with
> the same or related attribute type and a subset of the
> same options is not defined in general. Such semantics
> are defined on an option by option basis.
>and update ;binary (and ;lang-*) as approrpiate.
I like this suggestion. No, I love this suggestion. I'm taking it out for dinner and a movie tonight.
>Another approach would be to do both. That is, make the
>replacement, remove ;binary to a separate document (an
>extension). This would keep the "redesign" out of LDAPbis.
Doing this will require some care in that we don't 'cement' one transfer encoding in place for attribute values and assertion values in 2251bis.