RE: AttributeTypeValue and binary

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:38 AM 1/30/01 -0500, Salter, Thomas A wrote:
> > -----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. 

That's a different discussion.  Here were talking only about
the relationship with the returned AttributeDescription associated
with the returned AttributeValue in section 4.1.6. 

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