[Date Prev][Date Next]
RE: interoperability of ;binary
I must once again object to using "string encoding" to refer to a binary
The reason for ;binary is probably to warn clients not to print the
contents. String encoding would, I believe, be an encouragement to print.
But, comparing the mess with jpegPhoto, simply leaving ;binary off
userCertifcate would not seem so bad.
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 4 April 2001 6:52
To: Jim Sermersheim
Subject: Re: interoperability of ;binary
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.
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
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.
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.