RE: Binary Syntax

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

You can try and argue that jpegPhoto is a constrained octet string, but this
would be an ellipsis for:

. syntax is octet string
. string representation is the jpeg binary data
. the string representation is always used.

I personally do not believe a binary blob can be called a string
representation, though.

As regards binary, it certainly isn't an octet string. I believe its
definition is ANY. In this it is similar to certificates. When sending a
certificate, you send only the encoding of the certificate, you do not send
an octet string wrapper (leaving aside the manner in which it is encoded in
protocol, which you must do or else you have to admit that octet strings are
doubly wrapped when sent with ;binary).

The truth is that a jpeg will be wrapped in an octet string if ;binary is
used, simply because RFC 2251 says it will. Compare this with certificate
where there is no octet string wrapper, even though ;binary is used.

It is a pity that those who thought to redefine 'binary' to be octet string
didn't simply use octet string!

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 19 December 2001 13:03
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Binary Syntax


At 04:31 PM 2001-12-18, Ramsay, Ron wrote:
>You're right, that ;binary option was a bad idea. In effect, it only
applies
>to attributes which have an ASN.1 syntax. Other binary syntaxes, like
audio,
>jpeg and binary, don't take it.

Obviously the word 'binary' is a bit overloaded.  I prefer
refer to the audio, jpeg, and binary as constrained octet string
syntaxes.  It can be argued their ASN.1 data definitions are:
        audio ::= OCTET STRING ; constrained to a u-law format (pilot
schema)
        jpeg  ::= OCTET STRING ; constrained to a jpeg photo (LDAPv2 schema)

and, likewise for binary:
        binary ::= OCTET STRING ; constrained to BER encoded data

>The notion that binary could mean octet
>string may have been a misinterpretation of the ASN.1

Could be... or it could assumed to like the many other constrained
octet string syntaxes.

>RFC 2251 seems, on reflection, to confuse elements of protocol with
elements of the data model.

Every properly defined LDAP syntax has an associated ASN.1 data type
definition.  If it omitted, implementors will guess and this will
lead to interoperability problems.  The LDAPbis document should
eliminate the guess work.

>Getting rid of everything with the word 'binary' in it would draw no
>criticism from me,

Noted.

>but what about the previous LAW regarding certificates?

I'm not sure what you mean by LAW, but...

The X.509 certificate schema will dropped from the next revision
of the syntax and schema I-Ds per previously gauged WG consensus.

Currently there is no proposal to remove the ;binary transfer
option.  You are welcomed to make such a proposal.