RE: Incomplete Syntaxes Referenced by RFC 2252

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

At 02:21 PM 2/23/01 +1100, Steven Legg wrote:
>> A NOTES can also include notes regarding material augmenting the
>> description.
>If you have some examples let me know.

Any ASN.1 we might agree to add...

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

Okay.

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

RFC 2798 (inetOrgPerson)

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

I agree... but I note there are numerous examples of this in
LDAP schemas.

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

Or a statement that servers need not (or should not) enforce
these restrictions...

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

I agree... but one doesn't have to go far to find an example of
an attribute type putting a restriction upon a syntax.  altServer
comes to mind.

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

Well, if audio is kept, yes.  I'd prefer audio to be axed.
See my post regarding trimming syntaxes.

>> >            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
>I will note down the alternative interpretation.

That's fine for now.

>The question we really need answered for this syntax is what is it meant to be used for ?

Yes, that's the question.  I suggest we take this to another
thread.