RE: Incomplete Syntaxes Referenced by RFC 2252

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

Mark,

Mark Wahl wrote:
>
> Steven Legg wrote:
> >

> >             OID: 1.3.6.1.4.1.1466.115.121.1.54
> >   RFC 2252 NAME: LDAP Syntax Description
> > STRING ENCODING: Section 4.3.3, RFC 2252
> >      ASN.1 TYPE: None
> >     CONFORMANCE: (implied MUST, ldapSyntaxes is a MUST?)
> >
> > To legitimize the use of objectIdentifierFirstComponentMatch as the
equality
> > matching rule for the ldapSyntaxes attribute I suggest this ASN.1 in the
> > successor to RFC 2252 (plus the commented out things while we're about
it
> > ?):
>
> As a new feature?  I don't think there are two independent
> implementations of
> RFC 2252's LDAP Syntax Description which have an OBSOLETE field.

I remember someone on the list suggesting that OBSOLETE and NAME fields
ought to be added to LDAP Syntax Description, though I can't find the
relevant
message in the archive. Maybe it was on ldapext. I was just keeping the
option open.


> >             OID: 1.3.6.1.4.1.1466.115.121.1.56
> >   RFC 2252 NAME: LDAP Schema Definition
> > STRING ENCODING: Appendix A.2, RFC 2927
> >      ASN.1 TYPE: None
> >     CONFORMANCE: unspecified
> >
> > I suggest the following ASN.1 for this syntax:
> >
> >     LDAPSchemaDefinition ::= SEQUENCE {
> >         identifier      OBJECT IDENTIFIER,
> >         name            SET OF DirectoryString { ub-schema } OPTIONAL,
> >         obsolete        BOOLEAN DEFAULT FALSE,
> >         imports         SET OF OBJECT IDENTIFIER OPTIONAL,
> >         classes         SET OF OBJECT-CLASS.&id OPTIONAL,
> >         attributes      SET OF ATTRIBUTE.&id OPTIONAL,
> >         matching-rules  SET OF MATCHING-RULE.&id OPTIONAL,
> >         syntaxes        SET OF OBJECT IDENTIFIER
> >     }
>
> ASN.1 purists would be unhappy that there are SET OF x
> OPTIONAL elements in
> series which could not be resolved.

Would you believe I was using automatic tagging ? :-)
I'll put the tags in :-(.

> And doesn't a SET OF
> allow for zero
> elements?

Without a SIZE constraint it does, but making the SET OFs optional
will have some benefits for value notation, TER and XER, where a present
but empty list still shows up in the encoding. For example, in value
notation,

	imports {},
	classes {},
	attributes {},
	matching-rules {},
	syntaxes {}

If the fields are OPTIONAL these bits of syntactic fluff can be omitted.
An even better definition would be:

	SET SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL


> >             OID: 1.3.6.1.4.1.1466.115.121.1.57
> >   RFC 2252 NAME: LDAP Schema Description
> > STRING ENCODING: unspecified
> >      ASN.1 TYPE: unspecified
> >     CONFORMANCE: unspecified
> >
> > I couldn't find any information on this syntax.
>
> Wasn't published in RFC 2927.  Should be removed from the
> spec as there are
> no implementations.

I'll note this in the DEPOSITION for this syntax.

Regards,
Steven

>
> Mark Wahl
> Sun Microsystems Inc.
>