Subject: RE: Incomplete Syntaxes Referenced by RFC 2252

From: "Steven Legg" <[email-masked]>
Date: Wed, 21 Feb 2001 17:28:24 +1100

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 13:53:51 -0800

>clarifications, or better references, send them to me. I'll maintain the

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

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.

---

From: Mark Wahl <[email-masked]>
Date: Thu, 22 Feb 2001 17:55:44 -0600

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.

ASN.1 purists would be unhappy that there are SET OF x OPTIONAL elements in
series which could not be resolved.  And doesn't a SET OF allow for zero 
elements?

Wasn't published in RFC 2927.  Should be removed from the spec as there are
no implementations.

Mark Wahl
Sun Microsystems Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 16:03:53 -0800

>RFC 2252's LDAP Syntax Description which have an OBSOLETE field.

Also, LDAPsyntax don't have NAMEs.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 23 Feb 2001 14:21:03 +1100

Kurt,

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

> ";binary transfer required" (the wording currently used in

Okay. I'll change the wording.

>         Lack of independently developed interoperable implementations,

I'll do that.

> A NOTES can also include notes regarding material augmenting the

If you have some examples let me know.

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

> which, IMO, incorrectly uses the octet string syntax, not audio

Which RFC ? RFC 2748 is The COPS Protocol.

> may place restrictions upon allowed values (such as a u-law format

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.

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 20:20:20 -0800

>If you have some examples let me know.

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

>intends it to be a syntax restriction.

Okay.

>Which RFC ? RFC 2748 is The COPS Protocol.

RFC 2798 (inetOrgPerson)

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

>or some additional schema configuration mechanism needs to be provided.

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

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

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

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

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 23 Feb 2001 15:48:14 +1100

Mark,

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

> 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

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

> Wasn't published in RFC 2927.  Should be removed from the

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

Regards,
Steven

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 23 Feb 2001 16:59:13 +1100

Folks,

Here is version 2 of the syntax survey. We have a deposition for 1 syntax,
only 57 to go ! :-)

These are the changes.

1) Revised the wording for attributes requiring binary transfer.

2) Noted the alternative interpretation of the Binary syntax.

3) Noted that the string encoding reference for MHS OR Address has been
revised from the one in RFC 2252.

4) Noted the dependencies some string encodings have on other
specifications.

5) Improved the suggested ASN.1 for LDAPSchemaDescription. I fixed the
tagging and broke out the invariant parts of the LDAPSchemaDefinition
in the same manner as the X.500 schema definitions.

6) Added the DEPOSITION for LDAP Schema Description.

          NOTES: ;binary transfer required

    Audio ::= OCTET STRING

A alternative interpretation for this syntax is that values are
OCTET STRINGs containing BER encodings of values of any ASN.1 type.
The formal ASN.1 type definition would be:

     ASN.1 TYPE: OCTET STRING ( CONSTRAINED BY
               :     { -- content octets are any valid BER encoding -- } )
               : Clause 22, X.680:1997, Clause 9, X.682:1997, and
               :         Clause 8, X.690:1997 -- } )

The STRING ENCODING would be equivalent to the Octet String syntax.
          NOTES: ;binary transfer required
          NOTES: ;binary transfer required
          NOTES: ;binary transfer required
               : Has a dependency in ISO 3166

               : Has a dependency on RFC 2044 (UTF-8)
               : References ISO 10646-1:1993

               : Has a dependency on ITU-T E.123
               : Has a dependency on ITU-T T.4

    Fax ::= CHOICE {

               : Has a dependency on "JPEG File Interchange Format"

    JPEG ::= OCTET STRING

               : RFC 2252 references the obsolete RFC 1327

          NOTES: ;binary transfer required
               : Has a dependency on ITU-T E.123

        information     LDAPSchemaInformation
    }

    LDAPSchemaInformation ::= SEQUENCE {
        imports         [0] SET SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL,
        classes         [1] SET SIZE (1..MAX) OF OBJECT-CLASS.&id OPTIONAL,
        attributes      [2] SET SIZE (1..MAX) OF ATTRIBUTE.&id OPTIONAL,
        matching-rules  [3] SET SIZE (1..MAX) OF MATCHING-RULE.&id OPTIONAL,
        syntaxes        [4] 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
     DEPOSITION: REMOVED from TS.
               : A definition hasn't been published.
               : There are no implementations.
----------------------------------------------------------------------------
--
            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)

---

From: Chris Ridd <[email-masked]>
Date: Fri, 23 Feb 2001 12:52:25 -0000

> I haven't got the relevant X.400 standard (yet) to confirm the reference

X.402(1992) has this:

DLSubmitPermission ::= CHOICE {
    individual      [0] ORName,
    member-of-dl    [1] ORName,
    pattern-match   [2] ORNamePattern,
    member-of-group [3] Name }

Incidentally, X.402 actually defines an OID for this syntax:

id-as-mhs-dl-submit-permission ID ::= { 2 6 5 3 0 }

Incidentally what is the purpose of the 'LDAP OID' for this syntax? Does it
merely define the LDAP string representation of these values? If so, why
define LDAP OIDs for the syntaxes like ACI item that don't have a string
representation? Or is that a bug?

> I haven't got the relevant X.400 standard (yet) to confirm the reference

The ASN.1 definition for ORAddress (and ORName, see DLSubmitPermission) is
found in X.411(1992). It's a bit too big to include here :-)

It also has a syntax OID specified for it:

id-as-mhs-or-address ID ::= { 2 6 5 3 1 } 

Cheers,

Chris

---

From: "Ryan Moats" <[email-masked]>
Date: Sat, 24 Feb 2001 18:09:31 -0600

A nice list, and (in my mind) it brings up the question
of what to include in 2252bis...

Thinking about it, I would propose to not include any of the
unspecified conformance items in 2252bis.  I think that SHOULD
and implied SHOULD ought to be included, but I can see an
argument for going through the implied SHOULDs on a case by
case basis.  Of course, I'm open to discussing special cases ;-).

Ryan

P.S.  I don't have time to volunteer to do the same thing with
matching rules, but does somebody else have the time?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steven Legg
Sent: Thursday, February 22, 2001 11:59 PM
To: [email-masked]
Subject: Syntax Survey Version 2

Folks,

These are the changes.

    Audio ::= OCTET STRING

    Fax ::= CHOICE {

    JPEG ::= OCTET STRING

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 26 Feb 2001 18:10:22 +1100

Chris,

> representation? Or is that a bug?

The LDAP syntax OID is meant to be more general than just identifying
a specific string encoding. It is meant to indicate what sort of thing
an attribute type is representing, for presentation and other purposes.
For example, it is useful to know that an attribute is holding X.509
Certificates even though there is no string encoding for certificates.
LDAP clients and servers can be made extensible rather than being
hard-wired to perform certain actions on certain known attribute types.

> id-as-mhs-or-address ID ::= { 2 6 5 3 1 }

This is a different beast to the LDAP syntax OID. The 1988 edition of X.500
defined attribute syntaxes, which comprised an ASN.1 type and the associated
matching semantics, each with a distinct OID. The 1993 edition of X.500
deprecated the attribute syntaxes from the 1988 edition and introduced
matching rules to replace them. The 1993 attribute definitions explicitly
reference equality, ordering and substrings matching rules to define
the intended matching semantics. The LDAP syntax OID is just an alternative
means of identifying the data type (ASN.1 type) of an attribute. No matching
semantics are implied.

Since X.411(1992) is referencing 1988 X.500 concepts we will want to refer
to a later edition in the successors to RFC 2252 and 2256, if the X.400
syntaxes don't get thrown out. In the meantime, I'll put your references
into the syntax survey.

Thanks,
Steven