RE: clarifying RFC2251: ;binary option

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

See comments below.

 > -----Original Message-----
 > From: John Kristian [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'd say that the only syntaxes that must always be referenced with the
;binary option are those which say so explicitly in RFC2252, such as
Certificate syntax.

On the other hand, RFC2252 4.3.1 talks about "Binary Transfer of Values" and
specifically references "1.3.6.1.4.1.1466.115.121.1.5" (Binary syntax).  It
does not, however, mention ";binary".


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

No, the binary option has nothing to do with these other syntaxes.  ;binary
indicates that the value is BER encoded. 
 
 > 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 wouldn't call it "evil".  It has other purposes when Ldap front-ends
X.500, such as being able to see the original character set of a
DirectoryString, not the UTF-8 transformation of it.

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

Except for the certificate syntaxes.  RFC2252, 6.5 explicitly requires
;binary on all references to them:
   "Because of the changes from X.509(1988) and X.509(1993) and
   additional changes to the ASN.1 definition to support certificate
   extensions, no string representation is defined, and values in this
   syntax MUST only be transferred using the binary encoding, by
   requesting or returning the attributes with descriptions
   "userCertificate;binary" or "caCertificate;binary".  The BNF notation
   in RFC 1778 for "User Certificate" is not recommended to be used."

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

I completely disagree.  The ;binary option has no bearing on how the
attribute is stored; it refers only to the encoding in the Ldap operation.
This is explicitly stated in RFC2251, 4.1.5.1:
  "The presence or absence of the "binary" option only affects the
   transfer of attribute values in protocol; servers store any
   particular attribute in a single format."

The server includes ;binary whenever it is returning BER, instead of a
string translation of an attribute.

For example, a server which supports ;binary on all attributes, would return
different values for description and description;binary:

if description is requested:  
	description: "abc"
	
if description;binary is requested:  
	description;binary:: 0C 03 61 62 63
             (abc with the UTF8 tag and a length of 3)


 > - John Kristian <kristian@netscape.com>
 > 
 > P.S. These are my opinions, and don't necessarily reflect my 
 > employer's
 > policies.
 >