Subject: Binary Syntax and the binary Attribute Type option

From: "Damian Power" <[email-masked]>
Date: Fri, 19 Jan 2001 15:25:31 -0000

Hi,

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.

Simply put, my question is this: given that an Attribute Type is defined as
having Binary syntax (1.3.6.1.4.1.1466.115.121.1.5), is the ;binary option
required when referring to that attribute in protocol? 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"?

I don't believe the RFCs make a clear statement either way, so I'm looking
to see if a particular interpretation has gained acceptance. My personal
feeling is that the option should not be required.

I accept that the presence/absence of the option doesn't affect the value
returned.

Regards,

Damian.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Jan 2001 08:38:28 -0800

>don't want to pollute that thread.

I trimmed LDAPext off the cc list.

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

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, 4.1.5.1:
   If the "binary" option is present in an AttributeDescription, it
   overrides any string-based encoding representation defined for that 
   attribute in [5]. Instead the attribute is to be transferred as a
   binary value encoded using the Basic Encoding Rules [11].  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.

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"
syntax.

";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.

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.

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.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 22 Jan 2001 12:00:48 +1100

Kurt,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]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
> 
> 

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.

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

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

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 21 Jan 2001 20:07:14 -0800

I changed the subject as I think this discussion is now largely
not specific to the binary syntax.

At 12:00 PM 1/22/01 +1100, Steven Legg wrote:
>type definition.

I would agree that some clarification to RFC 2252 might be needed,
but I believe the intent of the table provided in 4.3.2 is to relate
LDAP SYNTAX OIDs to a specific ASN.1 data type definitions found in
X.500(93).  RFC 1778 was actually more clear on the relationship
between LDAP SYNTAXs and X.500 defined ASN.1 data type definitions.
These statements could have been dropped due to the addition of
LDAP specific syntaxes.

>in which case Binary syntax does not have an ASN.1 type definition.

Yes.

>...so I wonder what is gained by banning the ";binary" option.

Server implementations which support the binary syntax should be
expected to support the string encoding.  The point of ";binary"
is to allow, an implementation could choose to only support
";binary" transfer.  It would be very bad for interoperability
if some servers required "foo" and some required "foo;binary"
(regardless of what syntax foo is).

If we require all implementations to support a particular
encoding, there is no need to "MUST" or "SHOULD" another
encoding.  I don't see any point in a specific "MAY" as
implementations generally MAY be liberal in what accept.
Likewise, one could argue that "MUST NOT" or "SHOULD NOT"
are not needed.

I believe we should consider adding to the specification
statements which say:
 1) each syntax has a default encoding which is to be
    used unless the client requests an alternative encoding, and
 2) a syntax's default encoding is its string encoding unless
    stated otherwise.

Comments?

Kurt