RE: AttributeTypeValue and binary

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

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
 > Sent: Friday, January 26, 2001 8:33 PM
 > To: Jim Sermersheim
 > Cc: ietf-ldapbis@OpenLDAP.org
 > Subject: RE: AttributeTypeValue and binary
 > 
 > 
 > At 05:53 PM 1/26/01 -0700, Jim Sermersheim wrote:
 > >Okay, so we're saying that when the default encoding is NOT 
 > a string encoding, it MUST be accompanied by an 
 > AttributeDescription.option that specifies the encoding.
 > 
 > Yes, certificate's default encoding is BER and ";binary" must be
 > specified.
 > 
 > >I wrote it in anticipation of there someday being an 
 > encoding which is not a string encoding, and also doesn't 
 > require an AttributeDescription.option. (ala something I 
 > read in 
 > http://www.OpenLDAP.org/lists/ietf-ldapbis/200101/msg00039.html).
 > 
 > I don't mind language that like:
 >   In the absence of an option specifying the transfer encoding
 >   (e.g. ";binary"), the string encoding is used.  Otherwise, the
 >   transfer encoding is that specified by the option.  Multiple
 >   options specifying transfer encoding MUST NOT be present.  At
 >   the time of this writing, there is only one option, ";binary"
 >   (4.1.5.1), which specifies the transfer encoding to be used.
 >

The wording here is not quite accurate.  Suppose all attributes are
requested with the * option.  Then each attribute must be encoded in its
default encoding.  For example, userCertificate;binary must be returned
since there is no string encoding for certificates.

I've also noticed that RFC2256 is explicit about userCertificate (and
others) always being requested and returned as binary.  However, RFC2252 is
a bit ambiguous.  In the Certificate syntax description in 6.5, it says, 
"... 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".  "
This could be interpreted as allowing an attribute to be requested as
"tomsCertificate" and to be returned as "tomsCertificate;binary".

Are we trying to prevent this?  If so RFC2251 must be changed.  In 4.1.5, it
says "An AttributeDescription with one or more options is treated as a
subtype of the attribute type without any options."  In X.500, at least,
subtypes are returned when an attribute type is requested.

 
 > I don't view rfc2251 as disallowing additional options specifying
 > alternative transfer encoding.
 > 
 > Kurt
 >