[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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.
----------------------------------------------------------------------------
--