[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: AttributeTypeValue and binary

I forgot to mention a related change to 4.1.7. The proposal is to change:

"If the "binary" option is present in attributeDesc, this signals to the server that the assertionValue is a binary encoding of the assertion value."

to:

"If an option specifying the transfer encoding is present in attributeDesc, the assertionValue is encoded as specified by the option."

Please respond if you don't want to see this change in the protocol doc.

Jim

>>> "Jim Sermersheim" <jimse@novell.com> 2/21/01 12:35:05 AM >>>
Unless there are objections, I'll make the beginning of 4.1.6 read like this:
<
A field of type AttributeValue is an OCTET STRING containing an encoded value of an AttributeValue data type. The AttributeValue is encoded using the string encoding unless an option specifying the transfer encoding is present in the companion AttributeDescription to this AttributeValue (e.g. ";binary"). Multiple options specifying transfer encoding MUST NOT be present.

The definition of string encodings for different syntaxes and types may be found in other documents, and in particular [RFC2252].

At the time of this writing, there is only one AttributeDescription option used to specify transfer encoding--";binary", described in section 4.1.5.1.
>

Jim

>>> "Salter, Thomas A" <Thomas.Salter@unisys.com> 1/30/01 10:30:06 AM >>>


 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
 > Sent: Tuesday, January 30, 2001 11:00 AM
 > To: Salter, Thomas A
 > Cc: Jim Sermersheim; ietf-ldapbis@OpenLDAP.org 
 > Subject: RE: AttributeTypeValue and binary
 > 
 > 
 > 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. 

Ok, now that I understand the discussion, I'll try again. :-)

The wording suggested above got me into the wrong discussion because phrases
like "... encoding to be used" seem to indicate a request for an encoding.  

If this language is going into 4.1.6, how about rewording it as:

In the absence of an option specifying the transfer encoding (e.g.
";binary"), the AttributeValue is encoded using the string encoding.
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 transfer encoding option, ";binary"
(4.1.5.1).

Then it also needs to be repeated or referenced so it applies to
AssertionValue in 4.1.7 as well.

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