[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.