RE: Incomplete Syntaxes Referenced by RFC 2252

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

At 05:28 PM 2/21/01 +1100, Steven Legg wrote:
>Here is a survey of the attribute syntaxes listed in the table in Section
>4.3.2 of RFC 2252, in syntax OID order. A fair number of syntaxes are only
>defined in an expired Internet draft. If anyone has corrections,
>clarifications, or better references, send them to me. I'll maintain the
>list and post revisions.

Great.

A few general comments:

On the CONFORMANCE issue, I note that RFC 2251, 6.1 states:
   The server MUST be capable of recognizing all the mandatory
   attribute type names and implement the syntaxes specified in
   [5].

This statement, in my opinion, should be interpeted as:
   The server MUST implement [5].

That is, the table of syntaxes in [5] is not a specification,
but a list of syntaxes which have be specified (in many cases
elsewhere).

Otherwise, it's kind of pointless for [5] to state: "Servers
SHOULD recognize all the syntaxes described in this section."
Jim, I think we should consider a clarification to 2251, 6.1.

Instead of saying "default encoding is ;binary", I'd prefer
";binary transfer required" (the wording currently used in
the TS).

As we sort out the deposition of each item, we should add
a DEPOSITION field.  Where the deposition is "removed from
TS", there should be a brief rational such as:
        Obsolete, deprecated by XXX, Lack of maturity,
        Lack of independently developed interoperable implementations,
        etc.

A NOTES can also include notes regarding material augmenting the
description.

Before we address deposition issues (including implementation
reports), the table needs to be reviewed for accuracy.

I only have a couple comments to consider in that regard:

>----------------------------------------------------------------------------
>--
>            OID: 1.3.6.1.4.1.1466.115.121.1.4
>  RFC 2252 NAME: Audio
>STRING ENCODING: Section 5.2.2.1, draft-ietf-asid-ldapv3-attributes-03.txt
>     ASN.1 TYPE: OCTET STRING, Clause 22, X.680:1997
>    CONFORMANCE: unspecified
>
>I had to look through the ISODE 8.0 Quipu sources to confirm the ASN.1 type
>for this one. I suggest we provide an explicit ASN.1 type assignment in
>the successor to RFC 2252 to give the syntax a useful type name, e.g.
>
>    Audio ::= OCTET STRING

I concur.

I do note that RFC 1274 (PS), 9.3.45 states the 'audio' attribute
uses the u-law format.  However, it's not clear to me whether
this is a syntax restriction or an attribute type restriction.

I also note that RFC 2748 (Info), describes an 'audio' attribute
which, IMO, incorrectly uses the octet string syntax, not audio
syntax.

Assuming there are multiple interoperable implementations of this
syntax, I suggest the syntax described as "An octet string
containing audio in any format" with a note that attribute types
may place restrictions upon allowed values (such as a u-law format
restriction).


>----------------------------------------------------------------------------
>--
>            OID: 1.3.6.1.4.1.1466.115.121.1.5
>  RFC 2252 NAME: Binary
>STRING ENCODING: None,
>               : alternatively, the BER encoding, Clause 8, X.690:1997
>     ASN.1 TYPE: ATTRIBUTE.&Type, Clause 12.4.6, X.501 (2nd edition)
>    CONFORMANCE: SHOULD, Section 6, RFC 2252
>
>The default encoding is LDAP string, where that is defined to be the
>BER encoding.

I note [and only note, this is another thread] my alternative view
that the ASN.1 type is OCTET STRING whose value is restricted to BER
encoded data and the string encoding is this value.