[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: AttributeTypeValue and binary
> -----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
> > >
>