RE: Incomplete Syntaxes Referenced by RFC 2252

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

Kurt,

Kurt D. Zeilenga wrote:
> 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."

Or for it to say "Clients and servers need not implement
all the syntaxes listed here" (4.3.2).


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

Okay. I'll change the wording.


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

I'll do that.


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

If you have some examples let me know.


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

For what it's worth, the write-up in
draft-ietf-asid-ldapv3-attributes-03.txt
intends it to be a syntax restriction.


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

Which RFC ? RFC 2748 is The COPS Protocol.


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

It's not a good idea for an attribute type to qualify the syntax
semantics because it means that knowledge of the syntax alone is no
longer enough for a client or server to know what to do with the values.
Either special treatment for particular attribute types has to be
hardwired in (which is what having defined syntaxes is meant to avoid)
or some additional schema configuration mechanism needs to be provided.

The full semantics should be conveyed by the syntax identifier,
not the combination of syntax and attribute type.

I would prefer us to say Audio is u-law, and if anybody wants to use
a different format they will have to define a new syntax.


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

As I recall, your view is that a request for the ;binary encoding of
a Binary syntax attribute is invalid, so the only place the precise
ASN.1 type of the syntax becomes relevant is when the attribute is
transferred by DSP or DISP. From the X.500 perspective, having
OCTET STRINGs with embedded BER encodings, instead of open types,
isn't particularly useful.

I will note down the alternative interpretation. The question we really
need answered for this syntax is what is it meant to be used for ?

Regards,
Steven