[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: clarifying RFC2251: ;binary option
Christopher Oliva wrote:
> 1) ... I'm sure the most common interpretation of the RFC is that even for
> the Binary syntax, the attribute type must be referenced using the ";binary"
> option ...
I don't interpret it that way, nor does anyone I know. Has someone taken a
survey, to see if it's the 'most common' interpretation? Any relevant
anecdotes?
Do you propose a similar relationship between the ;binary option and other
syntaxes that have no UTF-8 representation? Some examples are Audio, Fax, JPEG
and (arguably) Octet String. Why should these syntaxes be treated differently
from Binary? They should not; the Binary syntax should not be special.
The ;binary option was the least evil way to rectify a deficiency in LDAP v2;
that is, the LDAP v2 printable syntax for userCertificate and related
attributes was inadequate to support public key infrastructure. Although the
;binary option was less evil than alternative solutions to that problem, it is
nonetheless evil and should be deprecated. Its use with other attribute types
is generally a bad thing. Certainly it should not be required.
> I would suggest that when the attribute is referenced in client requests,
> that the ;binary option tag MUST be present.
That would contradict some precedents, including RFC 2251 (section 4.1.5) and
<draft-ietf-ldapext-lang-01>. An AttributeDescription with one or more options
is treated as a subtype of the attribute type without any options [RFC 2251],
or fewer options, in general. So, when a client sends an attribute description
without options, the server implicitly considers it a reference to the named
attribute with or without options. For example, a client reference to "foo" is
implicitly refers to both "foo" and "foo;binary". This intepretation is
implemented in Netscape Directory Server, at least.
> Also, when the server responds to a query where the attribute type was
> explicitly requested, the ;binary option MUST also be present.
I agree, unless the query also requested the attribute without options, in
which case the server may send attribute descriptions both with and without
options.
> However when the client performed a request and did not explicitly request
> the attribute type, the server SHOULD include the ;binary option tag.
No; the server should include the ;binary option IF it was included by the
client that stored the value, originally. That is, the server should be a
neutral repository for options.
- John Kristian <kristian@netscape.com>
P.S. These are my opinions, and don't necessarily reflect my employer's
policies.