RE: Binary Syntax (consensus confirmation)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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

At 12:39 AM 2001-12-18, Volpers, Helmut wrote:
>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 
>
>> -----Original Message-----
>> From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
>> Sent: Dienstag, 18. Dezember 2001 05:49
>> To: Kurt D. Zeilenga; ietf-ldapbis@OpenLDAP.org
>> Subject: RE: Binary Syntax (consensus confirmation)
>> 
>> 
>> 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:Kurt@OpenLDAP.org]
>> Sent: Tuesday, 18 December 2001 14:33
>> To: ietf-ldapbis@OpenLDAP.org
>> Subject: Binary Syntax (consensus confirmation)
>> 
>> 
>> 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
>>