Subject: RE: AttributeTypeValue and binary

From: Christopher Oliva <[email-masked]>
Date: Thu, 18 Jan 2001 11:29:06 -0500

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

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

-----Original Message-----
From: Salter, Thomas A [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 9:25 AM
To: Kurt D. Zeilenga
Cc: [email-masked]
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:[email-masked]]
 > Sent: Wednesday, January 17, 2001 4:21 PM
 > To: [email-masked]
 > 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?
 >

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 19 Jan 2001 14:30:59 +1100

Christopher,

> From: [email-masked]
[mailto:[email-masked]]On Behalf Of Christopher Oliva
> Sent: Friday, 19 January 2001 3:29
> To: 'Salter, Thomas A'; Kurt D. Zeilenga
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.

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Jan 2001 19:18:45 -0800

At 02:30 PM 1/19/01 +1100, Steven Legg wrote:
>For most current syntaxes the default encoding is SSER.

One could argue that most syntaxes have no default encoding.
That is, there is no statement in the TS that states that
unless otherwise specified the default encoding is SSER.
However, one could argue that the intent and common interpretation
is for SSER to be the default encoding.   We should either
clarify that there is no default encoding or specify one.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Jan 2001 21:01:43 -0800

I think the RFC2252 specification of the binary syntax quite lacking.

6.2. Binary
   ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
   Values in this syntax are encoded as described in section 4.3.1.

4.3.1  Binary Transfer of Values
   This encoding format is used if the binary encoding is requested by
   the client for an attribute, or if the attribute syntax name is
   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP 
   AttributeValue or AssertionValue field is a BER-encoded instance of
   the attribute value or a matching rule assertion value ASN.1 data
   type as defined for use with X.500. (The first byte inside the OCTET
   STRING wrapper is a tag octet.  However, the OCTET STRING is still
   encoded in primitive form.)

Though the first sentence says it applies to both ";binary" and the
binary syntax, the second sentence makes no sense in the context of
the binary syntax.  I believe the intent of the binary syntax is to
allow values conforming to any BER-encoded instance of any ASN.1
data type definition and, like other syntaxes, attribute type
specifications may specify additional restrictions such as limiting
the values to any BER-encoded instance of a specific ASN.1 data type.
The uses of this syntax that I've seen use it in this manner.

I suggest 4.3.1 be stricken and 6.2 be replaced with:

6.2. Binary

   ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )

   Each value of this syntax is a BER-encoded instance of
   an ASN.1 data type definition.  (The first octet inside
   the OCTET STRING wrapper is a tag octet.  However, the
   OCTET STRING is still encoded in primitive form). Values
   of this syntax MUST NOT be transferred using Binary Option
   [RFC2251, 4.1.5.1].

   Attribute type, matching rule, and other specifications
   which make use of this syntax MAY place further restrict
   upon values of this syntax including restricting values to
   instances of a specific ASN.1 data type or restricting
   values to those produced by a subset of BER.  Enforcement
   of additional restrictions is OPTIONAL.

Comments?

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 22 Jan 2001 12:30:29 +1100

Kurt,

> [mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
> Sent: Saturday, 20 January 2001 14:19
> To: [email-masked]

Exactly so with the RFCs as written, but if we choose to adopt this notion
of there being a default encoding for each attribute syntax then most
current syntaxes would obviously have SSER as that default.

> clarify that there is no default encoding or specify one.

Isn't the first step to decide if there is consensus on making this
idea of a per-syntax default encoding overt in the revised LDAP
specifications ? Then we decide whether each syntax states its default,
or the default is assumed to be SSER unless otherwise stated, etc.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 21 Jan 2001 18:50:03 -0800

At 12:30 PM 1/22/01 +1100, Steven Legg wrote:
>specifications ?

My point was only that, IMO, some clarification as to which
interpretations is correct is needed.  This, of course, is a
debatable point.  I didn't intend to offer an opinion as to
which interpretation I favor nor any specific suggestion for
how to clarify the specification.  I think we need further
discussion on the issue before any consensus can be drawn.