Subject: RE: Syntax Survey Version 2

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 28 Feb 2001 16:25:17 +1100

Steven,

I note that inetOrgPerson contains the attribute 'photo' without defining
the syntax. A look at RFC 1274 reveals that it is actually binary. While the
COSINE document is quite old, RFC 2798 is prolonging its life. I'm wondering
if it is now necessary to define the syntax for 'photo'? I would think that
either
a. inetOrgPerson is supported by the LDAP specification and the syntax of
'photo' is defined in that specification, or
b. inetOrgPerson is not supported and RFC 2798 should define the syntax.

Ron.

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Friday, 23 February 2001 16:59
To: [email-masked]
Subject: Syntax Survey Version 2

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.

----------------------------------------------------------------------------
--
            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: ;binary transfer required
----------------------------------------------------------------------------
--
            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.

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.
----------------------------------------------------------------------------
--
            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: ;binary transfer required
----------------------------------------------------------------------------
--
            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: ;binary transfer required
----------------------------------------------------------------------------
--
            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: ;binary transfer required
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.11
  RFC 2252 NAME: Country String
STRING ENCODING: Section 6.8, RFC 2252
               : Has a dependency in ISO 3166
     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
               : Has a dependency on RFC 2044 (UTF-8)
               : References ISO 10646-1:1993
     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
               : Has a dependency on ITU-T E.123
     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
               : Has a dependency on ITU-T T.4
     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
               : Has a dependency on "JPEG File Interchange Format"
     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
               : RFC 2252 references the obsolete RFC 1327
     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: ;binary transfer required
----------------------------------------------------------------------------
--
            OID: 1.3.6.1.4.1.1466.115.121.1.50
  RFC 2252 NAME: Telephone Number
STRING ENCODING: Section 6.30, RFC 2252
               : Has a dependency on ITU-T E.123
     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,
        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)

The SubstringAssertion type has been extended in the fourth edition of
X.520.
The extension is not supported by the LDAP string encoding.
----------------------------------------------------------------------------
--

---

From: Mark Smith <[email-masked]>
Date: Wed, 28 Feb 2001 09:29:23 -0500

> b. inetOrgPerson is not supported and RFC 2798 should define the syntax.

I vote for choice "b."  RFC 2798 is an Informational RFC and as part of
the LDAPBIS work we are not obligated to do any extra work to support
inetOrgPerson.  I doubt photo is used much, if at all, in deployed
directories and I for one would not like to encourage its use by adding
it to a standards track RFC.

-Mark Smith
 Netscape Communications Corp.    Got inetOrgPerson?  Get it!