RE: AttributeTypeValue and binary

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

Christopher,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Christopher Oliva
> Sent: Friday, 19 January 2001 3:29
> To: 'Salter, Thomas A'; Kurt D. Zeilenga
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: AttributeTypeValue and binary
>
>
> It should also explain that "string" encoding does not have to be a
printable
> value. So an attribute with an Octet String syntax can be transmitted as a
> string where the value is the sequence of bytes comprising its value
(without
> the binary option and without the ASN.1 OCTET STRING tag). Section 4.1.6
> implies this but it would be clearer if it said "Attribute string syntaxes
> may be defined which have arbitrary or non-printable syntax".

I agree with the clarifications/interpretations that you and Thomas have
proposed.

> There's definitely a terminology problem in this issue. We say binary when
> we really mean "ASN.1 encoded" and we say string when we really mean
> "ldap syntax".

To be pedantic, we say binary when we really mean BER encoded.

>From my perspective the values we store in the directory are all ASN.1
values.
An ASN.1 value has a number of possible encodings for transfer in protocols
(none, one or more of which may be used by the directory server to
physically
store values in its internal database). X.500 only uses BER for transfer.
LDAP allows both BER and "LDAP syntax" encodings. I tend to think of the
latter as Syntax-specific String Encoding Rules (SSER, for short) to
distinguish them from the Generic String Encoding Rules (GSER) I devised
for the component matching rules. I hesitate to use the word "string" in
both
cases but I haven't thought of anything better. Some time in the future
we might also want to use the XML Encoding Rules (XER) or Text Encoding
Rules (TER), both of which are current work items in the ASN.1 working
group.

The ;binary attribute option allows us to request the BER encoding
(;ber would have been a better label) and it is easy to imagine
new attribute encoding options, say ;gser, ;xer, ;ter, and also ;sser,
to explicitly request the other encodings.

A useful way of modelling the relationship of encodings to attribute
syntaxes is to assume each attribute syntax has a default encoding to
be used when attributes of the syntax are requested without an encoding
attribute option. For most current syntaxes the default encoding is SSER.
At some point we could add the chosen default as an explicit field in
the values of the ldapSyntaxes operational attribute.

Before I go any further I want to make it clear that I'm not suggesting
we make any such extensions in LDAPBIS. They belong with LDAPEXT and ELSE.
I'm merely suggesting a model that ldapbis editors might like to keep in
mind
as they revise the LDAP core specifications.

A notional default encoding for each syntax answers the question about
what should be returned for userCertificate as opposed to
userCertificate;binary. If the default encoding rules for the Certificate
syntax are taken to be BER then both of the above return BER encoded values.

What we have in RFC 2252 and RFC 2256 at the moment are:

1) some attribute syntaxes (e.g. Directory String) that have both SSER
and BER encodings and default to SSER,

2) some syntaxes (e.g. Certificate) that have a BER encoding, but no SSER
encoding, and default to BER,

3) some syntaxes (e.g. DIT Content Rule Description) that have a BER
encoding, no SSER encoding, but should probably be regarded as
incompletely specified rather than defaulting to BER. I volunteered
to fix this for ELSE. They could be regarded as defaulting to BER,
in which case their future string encodings would have to be explicitly
requested with a ;sser or ;gser attribute option.

4) and some syntaxes (e.g. LDAP Syntax Description) that have an SSER
encoding, but no BER encoding, and default to SSER. I intend to address
the BER encoding for these as part of the adjunct ASN.1 syntaxes document
for component matching.

Any syntax with a BER encoding notionally has (will have) a GSER, XER or
TER encoding defined as well.

In the component matching rules draft I introduced a number of syntaxes
that have BER and GSER encodings and default to GSER.

I consider the Binary syntax (i.e. 1.3.6.1.4.1.1466.115.121.1.5) to
be an unspecified ASN.1 syntax that has its values transfered in BER
by default. In the component matching rules draft I introduced a
somewhat similar syntax (OpenType) which is a variable ASN.1 syntax
with BER and GSER encodings, that defaults to GSER instead.

Comments anyone?

Regards,
Steven

>
> -----Original Message-----
> From: Salter, Thomas A [mailto:Thomas.Salter@unisys.com]
> Sent: Thursday, January 18, 2001 9:25 AM
> To: Kurt D. Zeilenga
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: AttributeTypeValue and binary
>
>
> I agree.  I especially want to see the explanation that "binary" means
"BER
> encoding of an ASN.1 data type" included in the first reference to the
> binary option.  First-time readers tend to think that binary means JPEGs
and
> other non-printable things.
>
>
>  > -----Original Message-----
>  > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>  > Sent: Wednesday, January 17, 2001 4:21 PM
>  > To: ietf-ldapbis@OpenLDAP.org
>  > Subject: AttributeTypeValue and binary
>  >
>  >
>  > RFC 2251, 4.1.6:
>  >    A field of type AttributeValue takes on as its value
>  > either a string
>  >    encoding of a AttributeValue data type, or an OCTET
>  > STRING containing
>  >    an encoded binary value, depending on whether the
>  > "binary" option is
>  >    present in the companion AttributeDescription to this
>  > AttributeValue.
>  >         AttributeValue ::= OCTET STRING
>  >
>  > This wording can be interpreted as either:
>  >    A field of type AttributeValue is an OCTET STRING which contains
>  >    either a string encoding of a AttributeValue data type or an
>  >    binary encoded value depending on whether the "binary" option is
>  >    present in the companion AttributeDescription to this
>  > AttributeValue.
>  >
>  > or:
>  >    A field of type AttributeValue is an OCTET STRING which contains
>  >    either a string encoding of a AttributeValue data type or an
>  >    OCTET STRING containing an binary encoded value depending on
>  >    whether the "binary" option is present in the companion
>  >    AttributeDescription to this AttributeValue.
>  >
>  > RFC 2252, 4.3.1 provides clarification that the correct
>  > interpretation
>  > is the former.  I think RFC 2251 should be clarified to remove any
>  > doubt.
>  >
>  > Actually, I suggest that the description of the "binary" transfer
>  > option be described completely within (and only within) RFC 2251
>  > and that "binary" syntax be described within RFC 2252.
>  >
>  > Also as previously noted on the LDAPext mailing list (see archives
>  > for discussion), "binary" transfer of values of "binary" syntax
>  > makes little sense and likely should be disallowed.
>  >
>  > Comments?
>  >