RE: clarifying RFC2251: ;binary option

[Alexis Bor <alexis.bor@directoryworks.com>]

We need to be careful here.  If we have to take surveys to figure out how to
interpret an RFC, then we need to update the RFC to be more clear and
specific.  Perhaps an 'implementor agreement' type of RFC - but that too can
cause trouble...

I read it the same way as John did below in his response.  Are there a lot
of different interpretations?

-- Alexis

-----Original Message-----
From: kristian@netscape.com [mailto:kristian@netscape.com]
Sent: Monday, August 30, 1999 1:38 PM
To: Christopher Oliva
Cc: ietf-ldapext@netscape.com
Subject: 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.