Subject: Binary Syntax (consensus confirmation)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 17 Dec 2001 19:32:38 -0800

The definition of the binary syntax [RFC2252] (not to be confused
with the ;binary transfer option) was discussed during the LDAPbis
session at IETF#52.

RFC 2252 failed to provide an ASN.1 data definition for the
binary syntax.  There are at least two different interpretations:
	a) OCTET STRING constrained to a BER-encoded data
	b) ANY
Implementations of both exist in the wild, they do not
interoperate when ;binary is used.

In summary, the proponents of a) argue that it is more useful
as servers tend to preserve values (but not representations)
while proponents of b) argue that it is more consistent with the
literal reading of RFC 2252.  A poll of the room appeared to
favored a) over b), the chairs were not conformable in declaring
consensus (even rough).

The chair suggested that the specification for the binary syntax
be removed and the reasons why (ambiguous definition) be detailed
in the document's informative appendix detailing changes since
RFC 2252.  A poll of the room indicated strong consensus for this
approach.

Unless there is significant objection voiced from the WG, it shall
be assumed the WG consensus is to implement this approach.

Regards, Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 18 Dec 2001 15:48:40 +1100

I find this a tad extraordinary.

RFC 2252 Section 6.2 Binary:

Values in this syntax are encoded as described in section 4.3.1.

4.3.1 describes the binary transfer of values, therefore tying ;binary to
the binary syntax.

Values encoded in the Binary syntax are encoded in BER. For those of us
working with X.500, we know that all values are encoded in BER and many of
them have a suitable syntax (X.520). For those that don't have a defined
syntax, the actual syntax must surely be ANY.

How anyone felt any justification to use binary to mean octet string leaves
me breathless!

I know the IETF members complain about the cost of the standards and so try
and play it by ear, but the standard is the standard. We are not talking
whois or ph here.

Unhappily,

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 18 December 2001 14:33
To: [email-masked]
Subject: Binary Syntax (consensus confirmation)

Regards, Kurt

---

From: "Volpers, Helmut" <[email-masked]>
Date: Tue, 18 Dec 2001 09:39:04 +0100

I totally agree with Ron. 
;binary is defined and it have to be correctly encoded.
My Server looks in the value for a UserCertificate;binary
and validate the syntax and the client gets an error if it 
is not correctly encoded.
Why should I use ;binary for an OctetString ?
Binary was invited to transfer complex ASN.1 syntaxes (e.g. 
Certificates, Revokationlsits etc) over the LDAP V3 protocol without
defining a String representation for this attributes.
A Client which want to handle this types of attributes
should be able to handle ASN.1.

Helmut 

> From: Ramsay, Ron [mailto:[email-masked]]
> Sent: Dienstag, 18. Dezember 2001 05:49
> To: Kurt D. Zeilenga; [email-masked]
> Subject: RE: Binary Syntax (consensus confirmation)
> 
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 18 Dec 2001 02:48:23 -0800

Your post appears to use the term binary inconsistently.
Please repost qualifying each use of the word Binary to
indicate whether you are referring to the binary transfer
option or the binary syntax.  Otherwise your post is
hard to understand.

Note as well that the binary syntax is not used for X.509
certificates and CRLs.  These each of specific syntaxes
in LDAP which come from X.500, which are transferred using
the ;binary transfer option.  They are not impacted by the
removal of the binary syntax (which, to the best of my
knowledge, is LDAP specific) from the specification.

The binary syntax can be used two different ways:
        a) to hold arbitrary BER encoded data where they
        want that value to be preserved (all existing
        LDAP servers preserve values of octet string, but
        do not necessarily preserve representations of
        values),
        b) as a shortcut for folks who are unwilling or
        unable to define a specific LDAP syntax.

One can argue that both a) and b) are useful, though in each
case there are significant limits to their usefulness.  The
problem we have is that the ASN.1 data definition of the binary
syntax is not defined.   While why can argue until we are blue
regarding which of the two interpretations is most consistent
with the technical specification, the fact is that there are
two interpretations.

The poll taken at IETF#52 appears to indicate that a sizable
portion of that not only are both reasonable, that WG favors
a) over b) [it was 2:1 for a)].  However, it appeared that
a significant portion of the working group could swing either
way so consensus was not declared.

It was also noted during the meeting that this is not the
only interoperability issue with regards to the binary syntax.
There are clients implementations which require the binary syntax
to be transferred using the ;binary transfer option and client
implementations which require the syntax to be transferred without
the ;binary transfer option.  There are also server implementations
which cannot generate both (are not required to) transfer encodings,
let alone generate the ;binary transfer encoding expected by the
client.  Hence, if left in, the WG would also have to reach consensus
on how the binary syntax is to be transferred (with or without
;binary transfer option).  While disallowing use of the ;binary
transfer option for values of the binary syntax would remove the
ASN.1 contention (as both ASN.1 lead to the same native string
encoding), restricting the syntax to only the native string
encoding (no ;binary transfer option) would likely be
contentious as well (regardless of which ASN.1 was chosen).

It is noted that removing the binary syntax from the core specification
does not preclude a future extension document from reintroducing
the binary syntax and correcting the technical errors and/or
omissions.  Such a document would likely have to first submitted
as a Proposed Standard, not as a Draft Standard, due to nature of
the technical errors and/or omissions.  This facet of the decision
likely impacted the poll to remove the schema element from the
technical specification.

The proposal was to remove the binary syntax (NOT the binary
transfer option) from the technical specification and to provide
in an appendix detail as to why had immediate, quite strong
consensus (close to unanimous -- I didn't see a hand, but I might
have missed it).

I note Ron's and your dissent.

Please note there are numerous issues with regard to ;binary transfer
option, the preservation of values, and the preservation of representation
of values.  These issues are being addressed separately (as part of
the protocol I-D discussions).

---

From: "Volpers, Helmut" <[email-masked]>
Date: Tue, 18 Dec 2001 13:31:37 +0100

You are correct.
I meant everywhere the Transfer syntax ;binary.

Helmut

> Sent: Dienstag, 18. Dezember 2001 11:48
> To: Volpers, Helmut
> Cc: 'Ramsay, Ron'; [email-masked]