[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: Incomplete Syntaxes Referenced by RFC 2252

To: <steven.legg@adacel.com.au>, <ietf-ldapbis@OpenLDAP.org>
Subject: RE: Incomplete Syntaxes Referenced by RFC 2252
From: "Jim Sermersheim" <jimse@novell.com>
Date: Wed, 21 Feb 2001 01:02:05 -0700
Content-disposition: inline
Section 4.2 in RFC 1778 gives a more detailed string encoding definition of OID than does Section 4.1, RFC 2252. Does oid in 2252 obsolete oid in 1778?  If so, why was the possibility of "ds.4.10" removed? (just curious).

Related to this, RFC 3061 was recently published, and it references oid in RFC 1778, not RFC 2252.

Jim

>>> "Steven Legg" <steven.legg@adacel.com.au> 2/20/01 11:28:24 PM >>>

Folks,

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.

Regards,
Steven

----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.1
  RFC 2252 NAME: ACI Item
STRING ENCODING: None,
               : Section 6.2.1.1, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: ACIItem, Clause 16.2.1, X.501 (2nd edition)
    CONFORMANCE: unspecified
          NOTES: default encoding is ;binary
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.2
  RFC 2252 NAME: Access Point
STRING ENCODING: Section 6.2.1.2, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: AccessPoint, Clause 10.8, X.518 (2nd edition)
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.3
  RFC 2252 NAME: Attribute Type Description
STRING ENCODING: Section 4.2, RFC 2252
     ASN.1 TYPE: AttributeTypeDescription, Clause 14.7.4, X.501 (2nd
edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, attributeTypes is a MUST)
----------------------------------------------------------------------------
--
            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

----------------------------------------------------------------------------
--
            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.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.6
  RFC 2252 NAME: Bit String
STRING ENCODING: Section 6.3, RFC 2252
     ASN.1 TYPE: BIT STRING, Clause 21, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.7
  RFC 2252 NAME: Boolean
STRING ENCODING: Section 6.4, RFC 2252
     ASN.1 TYPE: BOOLEAN, Clause 17, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.8
  RFC 2252 NAME: Certificate
STRING ENCODING: None - Section 6.5, RFC 2252
     ASN.1 TYPE: Certificate, Clause 8, X.509 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
          NOTES: default encoding is ;binary
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.9
  RFC 2252 NAME: Certificate List
STRING ENCODING: None - Section 6.6, RFC 2252
     ASN.1 TYPE: CertificateList, Clause 11.2, X.509 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
          NOTES: default encoding is ;binary
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.10
  RFC 2252 NAME: Certificate Pair
STRING ENCODING: None - Section 6.7, RFC 2252
     ASN.1 TYPE: CertificatePair Clause 8, X.509 (2nd edition)
    CONFORMANCE: (implied SHOULD, crossCertificatePair is a SHOULD)
          NOTES: default encoding is ;binary
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.11
  RFC 2252 NAME: Country String
STRING ENCODING: Section 6.8, RFC 2252
     ASN.1 TYPE: CountryName, Clause 5.3.1, X.520 (4th edition), or
               : countryName.&Type, Clause 5.3.1, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.12
  RFC 2252 NAME: DN
STRING ENCODING: Sections 2 & 3, RFC 2253
     ASN.1 TYPE: DistinguishedName, Clause 9.2, X.501 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, modifiersName is a MUST)

The DistinguishedName type has been extended in the third and fourth
editions of X.501. These extensions are not supported by the current LDAP
string encoding.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.13
  RFC 2252 NAME: Data Quality Syntax
STRING ENCODING: Section 5.2.2.3, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: DataQualitySyntax, from the ISODE 8.0 Quipu sources.
               :
               : DataQualitySyntax ::= SEQUENCE {
               :     namespace-completeness   Completeness,
               :     defaultAttributeQuality  AttributeQuality,
               :     attributeQuality         SET OF SEQUENCE {
               :                                  type     AttributeType,
               :                                  quality
 AttributeQuality },
               :     description              PrintableString OPTIONAL
               : }
               :
               : AttributeQuality ::= SEQUENCE {
               :     maintenance-level       ENUMERATED {
               :                                 unknown           (1),
               :                                 external          (2),
               :                                 system-maintained (3),
               :                                 user-supplied     (4) },
               :     attribute-completeness  Completeness OPTIONAL
               :         -- DEFAULT full
               :         -- according to the other source
               : }
               :
               : Completeness ::= ENUMERATED {
               :     none        (1),
               :     sample      (2),
               :     selected    (3),
               :     substantial (4),
               :     full        (5) }
               :
    CONFORMANCE: unspecified

I found another source for the definition of DataQualitySyntax,
http://ftp.uni-erlangen.de/cgi-bin/view/pub/pc/magazine/ISO/osi-ds/osi-ds-15 
-01.txt
however there is a discrepancy between the string encoding and this ASN.1
type definition (it defines the maintenance-level ENUMERATED type
differently), so I've used the Quipu definition (tidied up).
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.14
  RFC 2252 NAME: Delivery Method
STRING ENCODING: Section 6.1, RFC 2256
     ASN.1 TYPE: preferredDeliveryMethod.&Type,
               : Clause 5.8.1, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2256
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.15
  RFC 2252 NAME: Directory String
STRING ENCODING: Section 6.10, RFC 2252
     ASN.1 TYPE: DirectoryString{}, Clause 5, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, supportedSASLMechanisms is a MUST?)

The definition of DirectoryString{} in the fourth edition of X.520 is more
interesting since it includes UTF8String as an alternative.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.16
  RFC 2252 NAME: DIT Content Rule Description
STRING ENCODING: Section 6.11, RFC 2252
     ASN.1 TYPE: DITContentRuleDescription, Clause 14.7.2, X.501 (2nd
edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.17
  RFC 2252 NAME: DIT Structure Rule Description
STRING ENCODING: Section 6.33, RFC 2252
     ASN.1 TYPE: DITStructureRuleDescription,
               : Clause 14.7.1, X.501 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.18
  RFC 2252 NAME: DL Submit Permission
STRING ENCODING: Section 2.34, RFC 1778
     ASN.1 TYPE: DLSubmitPermission, ...
    CONFORMANCE: unspecified

I haven't got the relevant X.400 standard (yet) to confirm the reference
for the ASN.1 type.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.19
  RFC 2252 NAME: DSA Quality Syntax
STRING ENCODING: Section 5.2.2.2, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: DSAQualitySyntax, from the ISODE 8.0 Quipu sources.
               :
               : DSAQualitySyntax ::= SEQUENCE {
               :     serviceQuality  ENUMERATED {
               :                         defunct       (0),
               :                         experimental  (1),
               :                         best-effort   (2),
               :                         pilot-service (3),
               :                         full-service  (4) },
               :     description     PrintableString OPTIONAL }
               :
    CONFORMANCE: unspecified

An identical definition for DSAQualitySyntax is given in
http://ftp.uni-erlangen.de/cgi-bin/view/pub/pc/magazine/ISO/osi-ds/osi-ds-15 
-01.txt
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.20
  RFC 2252 NAME: DSE Type
STRING ENCODING: Section 6.2.1.5, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: DSEType, Clause 19.4.2, X.501 (2nd edition)
    CONFORMANCE: unspecified

The fourth edition of X.501 has three more bits defined for DSEType.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.21
  RFC 2252 NAME: Enhanced Guide
STRING ENCODING: Section 6.2, RFC 2256
     ASN.1 TYPE: EnhancedGuide, Clause 5.5.3, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2256
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.22
  RFC 2252 NAME: Facsimile Telephone Number
STRING ENCODING: Section 6.12, RFC 2252
     ASN.1 TYPE: FacsimileTelephoneNumber, Clause 5.7.4, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.23
  RFC 2252 NAME: Fax
STRING ENCODING: Section 6.13, RFC 2252
     ASN.1 TYPE: CHOICE {
               :     g3-facsimile  [3] G3FacsimileBodyPart
               : }
               : Section 9.3.7 or 9.3.43, RFC 1274
    CONFORMANCE: SHOULD, Section 6, RFC 2252

I suggest we pull the ASN.1 type definition into the successor to RFC 2252
and give the CHOICE a useful type name, e.g.

    Fax ::= CHOICE {
        g3-facsimile  [3] G3FacsimileBodyPart
    }

It's not clear how to interpret Section 6.13 given the ASN.1 type.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.24
  RFC 2252 NAME: Generalized Time
STRING ENCODING: Section 6.14, RFC 2252
     ASN.1 TYPE: GeneralizedTime, Clause 41, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, createTimestamp is a MUST)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.25
  RFC 2252 NAME: Guide
STRING ENCODING: Section 6.3, RFC 2256
     ASN.1 TYPE: Guide, Clause 5.5.2, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2256

The ABNF for the string encoding needs fixing, it is ambiguous for parsing.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.26
  RFC 2252 NAME: IA5 String
STRING ENCODING: Section 6.15, RFC 2252
     ASN.1 TYPE: IA5String, Clause 36, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, altServer is a MUST?)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.27
  RFC 2252 NAME: INTEGER
STRING ENCODING: Section 6.16, RFC 2252
     ASN.1 TYPE: INTEGER, Clause 18, X.680
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, supportedLDAPVersion is a MUST?)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.28
  RFC 2252 NAME: JPEG
STRING ENCODING: Section 6.17, RFC 2252
     ASN.1 TYPE: OCTET STRING, Clause 22, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252

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.

    JPEG ::= OCTET STRING

----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.29
  RFC 2252 NAME: Master And Shadow Access Points
STRING ENCODING: Section 6.2.1.6, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: MasterAndShadowAccessPoints, Clause 10.8, X.518 (2nd
edition)
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.30
  RFC 2252 NAME: Matching Rule Description
STRING ENCODING: Section 4.5, RFC 2252
     ASN.1 TYPE: MatchingRuleDescription, Clause 14.7.3, X.501 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, matchingRules is a MUST)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.31
  RFC 2252 NAME: Matching Rule Use Description
STRING ENCODING: Section 4.5, RFC 2252
     ASN.1 TYPE: MatchingRuleUseDescription, Clause 14.7.7, X.501 (2nd
edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, matchingRuleUse is a MUST)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.32
  RFC 2252 NAME: Mail Preference
STRING ENCODING: Section 2.32, RFC 1778
     ASN.1 TYPE: ENUMERATED {
               :     no-list-inclusion(0),
               :     any-list-inclusion(1),  -- may be added to any lists
               :     professional-list-inclusion(2)
               :         -- may be added to lists
               :         -- which the list provider
               :         -- views as related to the
               :         -- users professional inter-
               :         -- ests, perhaps evaluated
               :         -- from the business of the
               :         -- organisation or keywords
               :         -- in the entry.
               : }
               : Section 9.3.37, RFC 1274
    CONFORMANCE: unspecified

I suggest we pull the ASN.1 type definition into the successor to RFC 2252
and give the ENUMERATED type a useful type name, e.g.

    MailPreference ::= ENUMERATED { ... }

----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.33
  RFC 2252 NAME: MHS OR Address
STRING ENCODING: Section 4.1, RFC 2156
     ASN.1 TYPE: ORAddress, ...
    CONFORMANCE: SHOULD, Section 6, RFC 2252

I haven't got the relevant X.400 standard (yet) to confirm the reference
for the ASN.1 type.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.34
  RFC 2252 NAME: Name And Optional UID
STRING ENCODING: Section 6.21, RFC 2252
     ASN.1 TYPE: NameAndOptionalUID, Clause 5.10.3, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.35
  RFC 2252 NAME: Name Form Description
STRING ENCODING: Section 6.22, RFC 2252
     ASN.1 TYPE: NameFormDescription, Clause 14.7.6, X.501 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.36
  RFC 2252 NAME: Numeric String
STRING ENCODING: Section 6.23, RFC 2252
     ASN.1 TYPE: NumericString, Clause 36, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.37
  RFC 2252 NAME: Object Class Description
STRING ENCODING: Section 4.4, RFC 2252
     ASN.1 TYPE: ObjectClassDescription, Clause 14.7.5, X.501 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, objectClasses is a MUST)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.38
  RFC 2252 NAME: OID
STRING ENCODING: Section 4.1, RFC 2252
     ASN.1 TYPE: OBJECT IDENTIFIER, Clause 31, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
               : (implied MUST, supportedExtension is a MUST?)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.39
  RFC 2252 NAME: Other Mailbox
STRING ENCODING: Section 6.26, RFC 2252
     ASN.1 TYPE: SEQUENCE {
               :     mailboxType    PrintableString,
               :     mailbox        IA5String
               : }
               : Section 9.3.18, RFC 1274
    CONFORMANCE: SHOULD, Section 6, RFC 2252

I suggest we pull this definition into the successor to RFC 2252 and give
the SEQUENCE a useful type name, e.g.

    OtherMailbox ::= SEQUENCE {
        mailboxType    PrintableString,
        mailbox        IA5String
    }

----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.40
  RFC 2252 NAME: Octet String
STRING ENCODING: Section 6.4, RFC 2256
     ASN.1 TYPE: OCTET STRING, Clause 22, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2256
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.41
  RFC 2252 NAME: Postal Address
STRING ENCODING: Section 6.27, RFC 2252
     ASN.1 TYPE: PostalAddress, Clause 5.6.1, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.42
  RFC 2252 NAME: Protocol Information
STRING ENCODING: Section 6.2.1.14, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: ProtocolInformation, Clause 5.9.3, X.520 (2nd edition)
    CONFORMANCE: (implied SHOULD, protocolInformationMatch is a SHOULD)
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.43
  RFC 2252 NAME: Presentation Address
STRING ENCODING: RFC 1278
     ASN.1 TYPE: PresentationAddress
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.44
  RFC 2252 NAME: Printable String
STRING ENCODING: Section 6.29, RFC 2252
     ASN.1 TYPE: PrintableString, Clause 36, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.45
  RFC 2252 NAME: Subtree Specification
STRING ENCODING: Section 6.2.1.10, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: SubtreeSpecification, Clause 11.3, X.501 (2nd edition)
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.46
  RFC 2252 NAME: Supplier Information
STRING ENCODING: Section 6.2.1.11, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: SupplierInformation, Clause 20.2.1.5, X.501 (2nd edition)
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.47
  RFC 2252 NAME: Supplier Or Consumer
STRING ENCODING: Section 6.2.1.12, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: SupplierOrConsumer, Clause 20.2.1.5, X.501 (2nd edition)
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.48
  RFC 2252 NAME: Supplier And Consumer
STRING ENCODING: Section 6.2.1.13, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: SupplierAndConsumer, Clause 20.2.1.7, X.501 (2nd edition)
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.49
  RFC 2252 NAME: Supported Algorithm
STRING ENCODING: None - Section 6.7, RFC 2256
     ASN.1 TYPE: SupportedAlgorithm, Clause 12.2.2.8, X.509 (3rd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2256
          NOTES: default encoding is ;binary
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.50
  RFC 2252 NAME: Telephone Number
STRING ENCODING: Section 6.30, RFC 2252
     ASN.1 TYPE: TelephoneNumber, Clause 5.7.1, X.520 (4th edition), or
               : telephoneNumber.&Type, Clause 5.7.1, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.51
  RFC 2252 NAME: Teletex Terminal Identifier
STRING ENCODING: Section 6.5, RFC 2256
     ASN.1 TYPE: TeletexTerminalIdentifier, Clause 5.7.3, X.520 (2nd
edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2256
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.52
  RFC 2252 NAME: Telex Number
STRING ENCODING: Section 6.6, RFC 2256
     ASN.1 TYPE: TelexNumber, Clause 5.7.2, X.520 (2nd edition)
    CONFORMANCE: SHOULD, Section 6, RFC 2256
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.53
  RFC 2252 NAME: UTC Time
STRING ENCODING: Section 6.31, RFC 2252
     ASN.1 TYPE: UTCTime, Clause 42, X.680:1997
    CONFORMANCE: SHOULD, Section 6, RFC 2252
----------------------------------------------------------------------------
--
            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
?):

    LDAPSyntaxDescription ::= SEQUENCE {
        identifier       OBJECT IDENTIFIER,
        -- name             SET OF DirectoryString { ub-schema } OPTIONAL,
        description      DirectoryString { ub-schema } OPTIONAL --,
        -- obsolete         BOOLEAN DEFAULT FALSE,
        -- defaultEncoding  OBJECT IDENTIFIER OPTIONAL,
    }

----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.55
  RFC 2252 NAME: Modify Rights
STRING ENCODING: Section 6.2.2.1, draft-ietf-asid-ldapv3-attributes-03.txt
     ASN.1 TYPE: ModifyRight, Section 6.2.2.1,
               : draft-ietf-asid-ldapv3-attributes-03.txt
    CONFORMANCE: unspecified
----------------------------------------------------------------------------
--
            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
    }

----------------------------------------------------------------------------
--
            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.
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.58
  RFC 2252 NAME: Substring Assertion
STRING ENCODING: Section 8.3, RFC 2252
     ASN.1 TYPE: SubstringAssertion, Clause 6.1.3, X.520 (2nd edition)
    CONFORMANCE: (implied SHOULD, caseIgnoreSubstringsMatch is a SHOULD)

The SubstringAssertion type has been extended in the fourth edition of
X.520.
The extension is not supported by the LDAP string encoding.
----------------------------------------------------------------------------
--
Follow-Ups:
- OID syntax (was: Incomplete Syntaxes Referenced by RFC 2252)
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Prev by Date: RE: AttributeTypeValue and binary
Next by Date: Re: ABNF for draft-smith-ldapv3-filter-update-01.txt
Index(es):
- Chronological
- Thread