[Date Prev][Date Next]
RE: Binary Syntax and the binary Attribute Type option
> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> Sent: Saturday, 20 January 2001 3:38
> To: Damian Power
> Cc: IETF LDAPBIS
> Subject: Re: Binary Syntax and the binary Attribute Type option
> At 03:25 PM 1/19/01 +0000, Damian Power wrote:
> >I have a question somewhat related to the
> "AttributeTypeValue and binary"
> >thread currently on the ELSE and LDAPBIS lists, but
> different enough that I
> >don't want to pollute that thread.
> I trimmed LDAPext off the cc list.
> >Simply put, my question is this: given that an Attribute
> Type is defined as
> >having Binary syntax (18.104.22.168.4.1.1422.214.171.124.5), is the
> ;binary option
> >required when referring to that attribute in protocol?
> No. (some might argue that it's allowed, I argue that it's not
> allowed [see previous thread], but I think we agree that it
> is not required).
> >For example,
> >attribute type "foo" has Binary syntax. If I request this
> attribute in a
> >search, do I refer to it as "foo" or "foo;binary"?
> It should be transferred as "foo".
> >I don't believe the RFCs make a clear statement either way,
> I would agree that the RFCs need clarification. But, I think if
> you carefully read RFC 2251, 126.96.36.199:
> If the "binary" option is present in an AttributeDescription, it
> overrides any string-based encoding representation defined for that
> attribute in . Instead the attribute is to be transferred as a
> binary value encoded using the Basic Encoding Rules . The syntax
> of the binary value is an ASN.1 data type definition which is
> referenced by the "SYNTAX" part of the attribute type definition.
> you'll find you cannot use ";binary" transfer with a value of
> binary syntax without contradicting the last sentence.
I find the second sentence to be bogus with respect to RFC 2252.
I don't think any of the syntaxes referenced by the "SYNTAX" part of
the attribute type description is formally associated with an ASN.1
type definition. The syntax descriptions typically give an LDAP string
encoding but make no mention of the ASN.1 type that applies for the
binary/BER encoding. The corresponding ASN.1 type is only arrived at
by noting the curious similarity between the LDAP syntax names and the
ASN.1 types defined in X.500 and used as attribute syntaxes.
If a formal correspondence between LDAP syntax and ASN.1 type is added
to the RFCs then the Binary syntax could be described as being the ANY
type, in which case Binary syntax does have an ASN.1 type definition,
or it could be described as representing an unspecified "something",
in which case Binary syntax does not have an ASN.1 type definition.
> That is, you can only ";binary" transfer a value who's SYNTAX
> is references an ASN.1 data type definition. The "binary" syntax
> does not reference an ASN.1 data type definition and hence (IMO)
> cannot be transferred using ";binary".
> There is a subtle difference between ";binary" and the "binary"
> ";binary" transfer is meant to be used to transfer a value with a
> syntax described by ASN.1 data type definition and BER encoded
> per this definition. Here, as there is specific ASN.1
> data type definition, a server may verify the value not only
> can be decoded but conforms to definition.
I've always taken a more relaxed view of the meaning of ";binary".
It's just a request to return the BER encoding of a value. It doesn't
matter whether the server knowns the ASN.1 type definition.
> The "binary" syntax allows the BER encoding of some ASN.1
> data definition type. A server may only verify the value can be
> decoded. It cannot verify it conforms to any specific ASN.1
> data type definition as there is none.
There are two circumstances where I imagine the Binary syntax might
be used in an attribute definition:
1) The attribute syntax is unknown to the server. As far as the server
is concerning the ASN.1 type could be anything.
2) The ASN.1 type of the attribute syntax is known to the server but
the ASN.1 type has no defined LDAP syntax OID.
In the first case the server cannot verify the encoding of a value whether
the attribute is referred to as "foo" or "foo;binary" so I wonder what is
gained by banning the ";binary" option. In the second case the server can
verify the value encoding whether the attribute is referred to as "foo"
or "foo;binary". Linking the the usage of ";binary" to whether the server
knows the ASN.1 type doesn't seem to be adding anything useful.
> I believe RFC 2252 obscures this difference by attempting to
> detail both in one section. As RFC 2251 already details ";binary",
> RFC 2252 should only detail the "binary" syntax. And, if there
> is consensus that binary transfer of the binary value makes no
> sense, an appropriate clarification should as be made.