RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

["Steven Legg" <steven.legg@adacel.com.au>]

David,

David Chadwick wrote:
> I think the new text for attribute descriptions is very good. Much
> better than before, especially the description of subtyping. However,
> the subsection on Binary Option (4.1.5.1) could still do with some
> improvement I feel. Firstly, the section is not as clear as
> recent email
> we have had on the list, explaining that the attribute value, whatever
> it is, is treated (or turned into) as an octet string containing BER,
> and then a TL octet wrapper is placed around it.

This is not the interpretation Kurt and I have been describing. An
AttributeValue in LDAP is an OCTET STRING. The contents octets of this
OCTET STRING are either a series of UTF8 encoded characters (being a
human-readable native LDAP encoding), a series of arbitrary octets
(being the native LDAP encoding for, e.g., the Octet String syntax -
1.3.6.1.4.1.1466.115.121.1.40) or a BER encoded value (comforming to
the ASN.1 type corresponding to the LDAP syntax).
There is no extra OCTET STRING wrapper around the BER encoding.

By way of example, the contents octets of AttributeValue for the value
"foo" returned as a value of cn would be (in hexadecimal): 66 6F 6F .

Returned as a value of cn;binary it would be: 13 03 66 6F 6F,
the BER for a value of the printableString alternative from the
DirectoryString{} CHOICE. No OCTET STRING tags to be seen.

>
> Secondly, the section talks about overriding the native encoding and
> sending it as BER instead. But then your example uses
> certificates, that
> are native BER encoded.

The Certificate syntax does not have a native encoding in LDAPv3.

> So what overriding is there to take place. It
> would seem like none, and therefore the effect of ;binary is null.

"Overriding" is perhaps the wrong way to describe it, since for some
syntaxes there is no native LDAP encoding to override. I prefer to think
of binary as an *alternative* way of encoding a value. For some syntaxes,
like Certificate, there is no choice because there is only one alternative
defined.

> In
> other words the section does not clearly indicate to me what the
> difference would be in transferring a certificate without ;binary and
> one with i.e. certificate;binary.

The difference is that "certificate" without ";binary" is illegal.
The native LDAP encoding is, at present, undefined.

> This is unfortunate and
> confusing to
> the reader. I suggest you use an example that is not a
> certificate, but
> is a simple string. You might then also add text to say what
> the effect
> of ;binary is on a value that is already BER encoded.
>
> I find this sentence particular confusing
>
> "Instead the attribute is to be transferred as
>    a binary value encoded using the Basic Encoding Rules [X.690]."
>
> The reason it is confusing is that all values in BER are binary. So if
> the value is already BER what more needs to be done to it? It
> would seem
> nothing.

RFC 2252 allows a server to store a value in any format it likes.
If a value is stored as BER then it can be returned in ";binary"
form without conversion. If stored in the native LDAP encoding
then to be returned in ";binary" form it must first be re-encoded
(as BER). The converse applies if the value is requested in native
LDAP form.

>
> Perhaps the sentence might read better as
>
> "Instead the attribute value is transferred as an ASN.1
> OctetStringType,
> where the embedded octet string value is itself a BER encoded value"

No, this suggests an extra OCTET STRING wrapper.

>
>
> The second sentence
> "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."
>
> also has some errors in it, and could then be changed to
>
> "The syntax of the BER encoded value is an ASN.1 data type, which
> must conform to the "SYNTAX" part of the AttributeTypeDescription."
>
> Is that any better?

I would prefer:

"The value is BER encoded according to the ASN.1 data type
corresponding to the attribute's LDAP syntax. The LDAP syntax is
indicated by the "SYNTAX" part of the AttributeTypeDescription."

... with corresponding ASN.1 types nominated for each syntax in RFC 2252bis.

Regards,
Steven