Internet-Draft | LDAP Additional syntaxes | September 2025 |
Codère | Expires 1 April 2026 | [Page] |
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directoy services series X.500. This includes widely used datatypes and syntaxes.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Lightweight Directory Access Protocol (LDAP) directory defines several data types which specify the syntax definitions of attributes. These are identified by ASN.1 OBJECT IDENTIFIERS. Furthermore, these syntax definitions could be used to uniquely identify data types as character representations in other applications. Some widely used syntax specifications are missing from the initial LDAP specification. This document provides additional syntax definitions that have been registered and may be used by application providers.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Syntax definitions are written according to the regular expressions defined in [RFC9485].¶
The following additional syntaxes and their associated descriptions and OBJECT IDENTIFIER are defined.¶
The following additional syntaxes are defined and are based on [ASN.1].¶
The Date type represents a date in the Gregorian calender. It is defined as a useful TIME type in [ASN.1] and conforms to the extended format syntax of a calendar date as defined in [ISO.8601.2004].¶
A Date value SHALL be written using the following syntax: YYYY-MM-DD where YYYY represents a year between 1582 and 9999, MM the month value from 01 to 12 and DD a day in the month from 01 to 31.¶
Examples¶
The LDAP definition for the Date syntax is:¶
This syntax corresponds to the DATE ASN.1 type from [ASN.1].¶
The Date-time type represents a date and local time using a 24 hour clock. It is defined as a useful TIME type in [ASN.1] and conforms to the extended format syntax of a date and time without any timezone specifier as defined in [ISO.8601.2004].¶
A Date-Time value SHALL be written using the following syntax: YYYY-MM-DDThh:mm:ss where YYYY represents a year between 1582 and 9999, MM the month value from 01 to 12, DD a day in the month from 01 to 31, hh the hour from 00 to 24, mm the minute from 00 to 59, and ss the seconds with allowed values of 00 to 60 where 60 represents a leap second¶
Examples¶
The LDAP definition for the Date-Time syntax is:¶
This syntax corresponds to the DATE-TIME ASN.1 type from [ASN.1].¶
The Duration type represents an elapsed time with a resolution of up to a fractions of seconds. It is defined as a useful TIME type in [ASN.1] and conforms to the extended format syntax of a time interval by duration as defined in [ISO.8601.2004].¶
A duration syntax value SHALL conform to the following regular expression¶
P([0-9]+Y)?([0-9]+M)?([0-9]+D)?(T([0-9]+H)?([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)?¶
Examples¶
The LDAP definition for the Duration syntax is:¶
This syntax corresponds to a very strict subset of DURATION ASN.1 type from [ASN.1], in that the order of parameters need to be respected.¶
The Real type represents the computational approximations to the mathematical "real number". The format for the Real is as defined in Section 21 of [ASN.1].¶
A Real syntax value SHALL conform to the following regular expression¶
([-]?[0-9]+\.?[0-9]+([E][-]?[0-9]+)?)|PLUS-INFINITY|MINUS-INFINITY|NOT-A-NUMBER¶
Examples¶
The LDAP definition for the Real syntax is:¶
This syntax corresponds to a subset of the REAL ASN.1 type from [ASN.1] where the sequence syntax is not allowed, the values are limited to base ten, where a digit before the decimal point is required, where only the character 'E' is allowed to specify the exponent and that the preceding optional "+" sign is prohibited in the exponent.¶
The Time Of Day type represents a local time using a 24 hour clock. It is defined as a useful TIME type in [ASN.1] and conforms to the extended format syntax of a local time as defined in [ISO.8601.2004].¶
A Time Of Day value SHALL be written using the following syntax: hh:mm:ss where hh represents the hour from 00 to 24, mm represents the minute from 00 to 59, and ss represents the seconds with allowed values of 00 to 60 where 60 represents a leap second.¶
Examples for Time Of Day:¶
The LDAP definition for the Time Of Day syntax is:¶
This syntax corresponds to the TIME-OF-DAY ASN.1 type from [ASN.1].¶
The Visible string type represents a character repertoire that the contains printable ASCII character set (in the range 0020-007E hexadecimal). It is defined in [ASN.1].¶
This syntax value SHALL conform to the following regular expression¶
[0-9A-Za-z !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~]¶
Examples¶
The LDAP definition for the Visible String syntax is:¶
This syntax corresponds to the VisibleString ASN.1 type from [ASN.1].¶
The following additional syntaxes are defined as constraints of basic ASN.1 types that may be used to be more precise in encoding and input validation.¶
The Short String type represents a string that is limited to 31 characters when encoded.¶
The length was chosen so that when using DER encoding, using the worst-case scenario of 4 octets per character in UTF-8, the string can be encoded using one length octet. It is also sufficient for labels and short titles.¶
Examples¶
The LDAP definition for the Short String type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ITU.X520.2019]:¶
Shortstring ::= DirectoryString{31}¶
The Long String type represents a string that is limited to 250 characters when encoded.¶
The length was chosen so that when using CER encoding, using the worst-case scenario of 4 octets per character, the string can still be encoded using a primitive construct. This length seems sufficient for descriptive text.¶
Examples¶
The LDAP definition for the Long String type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ITU.X520.2019]:¶
Longstring ::= DirectoryString{250}¶
The text type represents a string that is limited to 16383 characters when encoded. .¶
The length was mainly defined based on historical system constraints of 65535 octets using the worst case scenario of 4 octets per character.¶
Examples¶
The LDAP definition for the Text type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ITU.X520.2019]:¶
Text ::= DirectoryString{16383}¶
The Float32 type represents a real number which fits in the range of a [IEEE_754_2019] single precision floating point value.¶
The Float32 syntax follows the syntax of the real type (See Section 2.1.4) with a constrained range.¶
Examples¶
The LDAP definition for the Float32 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Float32 ::= REAL (WITH COMPONENTS { mantissa (-16777215..16777215), base (2), exponent (-149..104) })¶
The Float64 type represents a real number which fits in the range of a [IEEE_754_2019] double precision floating point value.¶
The Float64 syntax follows the syntax of the real type (See Section 2.1.4) with a constrained range.¶
Examples¶
The LDAP definition for the Float64 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Float64 ::= REAL (WITH COMPONENTS { mantissa (-9007199254740991..9007199254740991), base (2), exponent (-1074..971) })¶
The UInt8 type represents an unsigned integer value within the range 0 to 255 inclusive.¶
Examples¶
The LDAP definition for the UInt8 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
UInt8 ::= INTEGER(0..255)¶
The UInt16 type represents an unsigned integer value within the range 0 to 65535 inclusive.¶
Examples¶
The LDAP definition for the UInt16 type syntax is:¶
This syntax syntax corresponds to the following ASN.1 type from [ASN.1]:¶
UInt16 ::= INTEGER(0..65535)¶
The UInt32 type represents an unsigned integer value within the range 0 to 4294967295 inclusive.¶
Examples¶
The LDAP definition for the UInt32 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
UInt32 ::= INTEGER(0..4294967295)¶
The UInt64 type represents an unsigned integer value within the range 0 to 18446744073709551615 inclusive.¶
Examples¶
The LDAP definition for the UInt64 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
UInt64 ::= INTEGER(0..18446744073709551615)¶
The Int8 type represents a signed integer value within the range -128 to 127 inclusive.¶
Examples¶
The LDAP definition for the Int8 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Int8 ::= INTEGER(-128..127)¶
The Int16 type represents a signed integer value within the range -32768 to 32767 inclusive.¶
Examples¶
The LDAP definition for the Int16 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Int16 ::= INTEGER(-32768 .. 32767)¶
The Int32 type represents a signed integer value within the range -2147483648 to 2147483647 inclusive.¶
Examples¶
The LDAP definition for the Int32 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Int32 ::= INTEGER(-2147483648..2147483647)¶
The Int64 type represents a signed integer value within the range -9223372036854775808 to 9223372036854775807 inclusive.¶
Examples¶
The LDAP definition for the Int64 type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Int64 ::= INTEGER(-9223372036854775808..9223372036854775807)¶
The Percentage type represents a percentage value, that is an unsigned integer in the range 0 to 100 inclusive.¶
Examples¶
The LDAP definition for the Percentage type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Percentage ::= INTEGER(0..100)¶
The following additional syntaxes are defined and are based on IETF RFC's, or other international standards.¶
DCMIType is a controlled vocabulary to describe the type of a resource. It is specified in [DCMIType]¶
Examples¶
The LDAP definition for the DCMIType syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
DCMIType ::= VisibleString ("Collection" | "Dataset" | "Event" | "Image" | "Interactive Resource" | "Moving Image" | "Physical Object" | "Service" | "Software" | "Sound" | "Still Image" | "Text")¶
A language provides a representation of a spoken or written language as well as an optional locale specifier. The exact syntax allowed is defined in Section 2 of [RFC5646].¶
A Language syntax value SHALL conform to the following regular expression¶
[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*¶
Examples¶
The LDAP definition for the Language syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
Language ::= VisibleString (PATTERN "[a-zA-Z]#(1,8)(-[a-zA-Z0-9]#(1,8))*") -- ISO 639 code minimally¶
The Media Type syntax type should be used to identify values that represent a Media type. The format for the MIME Media type is defined in Section 5.1 of [RFC6838].¶
This syntax value SHALL conform to the following regular expression¶
[A-Za-z0-9]([A-Za-z0-9!#$&^_.+-]){0,126}/[A-Za-z0-9]([A-Za-z0-9!#$&^_.+-]){0,126}¶
Examples¶
The LDAP definition for the MIME Media type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
MediaType ::= VisibleString (SIZE(3..255)) -- IANA Registered Media type¶
An OpenDate represents either part of a Date or a Date and Time in extended format as specified in ISO 8601. The exact syntax allowed is defined by W3C Date and Time formats [W3C.NOTE-datetime-19980827] with a 3 digit fraction. The time component, when present, always contains timezone information.¶
Examples for OpenDate:¶
The LDAP definition for the OpenDate syntax is:¶
This syntax corresponds to a subset of the TIME ASN.1 type from [ASN.1] with the specified configuration:¶
OpenDate ::= TIME((SETTINGS "Basic=Date Date=Y Year=Basic")| (SETTINGS "Basic=Date Date=YM Year=Basic")| (SETTINGS "Basic=Date Date=YMD Year=Basic")| (SETTINGS "Basic=Date-Time Date=YMD Year=Basic Time=HM Local-or-UTC=LD")| (SETTINGS "Basic=Date-Time Date=YMD Year=Basic Time=HMS Local-or-UTC=LD")| (SETTINGS "Basic=Date-Time Date=YMD Year=Basic Time=HMSF3 Local-or-UTC=LD")| (SETTINGS "Basic=Date-Time Date=YMD Year=Basic Time=HM Local-or-UTC=Z")| (SETTINGS "Basic=Date-Time Date=YMD Year=Basic Time=HMS Local-or-UTC=Z")| (SETTINGS "Basic=Date-Time Date=YMD Year=Basic Time=HMSF3 Local-or-UTC=Z"))¶
The URI syntax type should be used to identify values that are referenced by a Uniform Resource Identifier (URI). The format and encoding for the URI is as defined in [RFC3986]. Even if relative URI's are allowed, it is recommended they not be used unless the context of use is known.¶
Examples¶
The LDAP definition for the URI syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1]:¶
URI ::= VisibleString (SIZE(1..ub-uri-length))¶
The value of ub-uri-length (an integer) is implementation defined but must be at least 2000 octets.¶
The NCName syntax type should be used to identify values that represent identifiers and
local attribute names. A name is a subset of the NCName
definition in [W3C.xmlschema11-2].¶
This syntax value SHALL conform to the following regular expression¶
[\p{L}\p{Nl}_][\p{L}\p{Nl}\p{Nd}.-_]*¶
Examples¶
The LDAP definition for the NCName type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ITU.X520.2019]:¶
NCName ::= UnboundedDirectoryString¶
The Normalized String syntax type represents white space normalized strings.
A Normalized String is a string that does not contain any control characters including
the carriage return (%xD), line feed (%xA) or tab (%x9) character.
This is similar to the NormalizedString
datatype in [W3C.xmlschema11-2] based on the
Char
type defined in [W3C.xml].¶
Examples¶
The LDAP definition for the Normalized String type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1] :¶
NormalizedString ::= CHOICE { printableString PrintableString, bmpString BMPString (FROM( {0, 0, 0, 32} .. {0, 0, 215, 255} | {0, 0, 224, 0} .. {0, 0, 255, 253})), universalString UniversalString (FROM( {0, 0, 0, 32} .. {0, 0, 215, 255} | {0, 0, 224, 0} .. {0, 0, 255, 253} | {0, 1, 0, 0} .. {0, 16, 255, 253})), uTF8String UTF8String (FROM( {0, 0, 0, 32} .. {0, 0, 215, 255} | {0, 0, 224, 0} .. {0, 0, 255, 253} | {0, 1, 0, 0} .. {0, 16, 255, 253})) }¶
The QualifiedName syntax type may be used to identify values that represent identifiers and
attribute names using namespaces. This is a subset of the QName
definition in [W3C.xmlschema11-2].¶
This syntax value SHALL conform to the following regular expression¶
[\p{L}\p{Nl}_][\p{L}\p{Nl}\p{Nd}.-_]*(:)?[\p{L}\p{Nl}\p{Nd}.-_]+¶
Examples¶
The LDAP definition for the QualifiedName type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ITU.X520.2019]:¶
QualifiedName ::= UnboundedDirectoryString¶
The Time Of Day type with Timezone represents a time with explicit timezone information using a 24 hour clock. It is defined as a TIME type in [ASN.1] and conforms to the extended format syntax of a time either represented as a Local time and the difference from UTC or UTC of day as defined in [ISO.8601.2004].¶
A Time Of Day with Timezone value SHALL be written using the following syntax: hh:mm:ss where hh represents the hour from 00 to 24, mm represents the minute from 00 to 59, and ss represents the seconds with allowed values of 00 to 60 where 60 represents a leap second followed by a timezone indicator.¶
The timezone indicator is in the form +hh:mm where hh represents the number of hours and mm the number of minutes if the local time is ahead of or equal to UTC time. The timezone indicator is -hh:mm if the local time is behind UTC time. If the time represents an UTC time, the time shall be followed without space, by the timezone UTC designator [Z]. This standard supports time differences in the range –15 hours to +15 hours to align with [ASN.1].¶
Examples for Time Of Day with Timezone:¶
The LDAP definition for the Time Of Day with Timezone syntax is:¶
This syntax corresponds to a subset of the TIME ASN.1 type from [ASN.1] with the specified configuration:¶
Time-with-timezone ::= TIME((SETTINGS "Basic=Time Time=HMS Local-or-UTC=LD")| (SETTINGS "Basic=Time Time=HMS Local-or-UTC=Z"))¶
The Token syntax type represents white space normalized strings.
A Normalized String is a string that does not contain any control characters including
the carriage return (%xD), line feed (%xA) or tab (%x9) character, that have no leading or trailing
spaces (%x20) and that have no internal sequences of two or more spaces.
This is similar to the Token
datatype in [W3C.xmlschema11-2] based on the
Char
type defined in [W3C.xml].¶
Examples¶
The LDAP definition for the Token type syntax is:¶
This syntax corresponds to the following ASN.1 type from [ASN.1] :¶
Token ::= CHOICE { printableString PrintableString(PATTERN "[^ ]+( [^ ]+)*"), bmpString BMPString (FROM( {0, 0, 0, 32} .. {0, 0, 215, 255} | {0, 0, 224, 0} .. {0, 0, 255, 253})) (PATTERN "[^ ]+( [^ ]+)*"), universalString UniversalString (FROM( {0, 0, 0, 32} .. {0, 0, 215, 255} | {0, 0, 224, 0} .. {0, 0, 255, 253} | {0, 1, 0, 0} .. {0, 16, 255, 253})) (PATTERN "[^ ]+( [^ ]+)*"), uTF8String UTF8String (FROM( {0, 0, 0, 32} .. {0, 0, 215, 255} | {0, 0, 224, 0} .. {0, 0, 255, 253} | {0, 1, 0, 0} .. {0, 16, 255, 253})) (PATTERN "[^ ]+( [^ ]+)*") }¶
The IANA has registered the LDAP values [RFC4520] specified in this document.¶
Object Identifier | Syntax |
---|---|
1.3.6.1.4.1.61799.5.40.31 | Date |
1.3.6.1.4.1.61799.5.40.33 | Date-Time |
1.3.6.1.4.1.61799.5.40.19.2 | DCMIType |
1.3.6.1.4.1.61799.5.40.34 | Duration |
1.3.6.1.4.1.61799.5.40.9.4 | Float32 |
1.3.6.1.4.1.61799.5.40.9.8 | Float64 |
1.3.6.1.4.1.61799.5.40.2.1 | Int8 |
1.3.6.1.4.1.61799.5.40.2.2 | Int16 |
1.3.6.1.4.1.61799.5.40.2.4 | Int32 |
1.3.6.1.4.1.61799.5.40.2.8 | Int64 |
1.3.6.1.4.1.61799.5.40.19.1 | Language |
1.3.6.1.4.1.61799.5.40.26.6 | NCName |
1.3.6.1.4.1.61799.5.40.12.4 | Normalized String |
1.3.6.1.4.1.61799.5.40.12.1 | Short String |
1.3.6.1.4.1.61799.5.40.12.2 | Long String |
1.3.6.1.4.1.61799.5.40.26.5 | Media Type |
1.3.6.1.4.1.61799.5.40.14.1 | OpenDate |
1.3.6.1.4.1.61799.5.40.2.20 | Percentage |
1.3.6.1.4.1.61799.5.40.26.7 | QualifiedName |
1.3.6.1.4.1.61799.5.40.9 | Real |
1.3.6.1.4.1.61799.5.40.12.3 | Text |
1.3.6.1.4.1.61799.5.40.12.5 | Token |
1.3.6.1.4.1.61799.5.40.32 | Time Of Day |
1.3.6.1.4.1.61799.5.40.35 | Time Of Day with Timezone |
1.3.6.1.4.1.61799.5.40.2.21 | UInt8 |
1.3.6.1.4.1.61799.5.40.2.22 | UInt16 |
1.3.6.1.4.1.61799.5.40.2.24 | UInt32 |
1.3.6.1.4.1.61799.5.40.2.28 | UInt64 |
1.3.6.1.4.1.61799.5.40.26.4 | URI |
1.3.6.1.4.1.61799.5.40.26 | Visible String |
This document should not affect the security of the Internet.¶
This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz.¶
This document was sponsored by Andy Newton of the IETF ART group.¶
Sean Turner acted as a shepherd for this document to help it become a proposed standard.¶
This document was reviewed and improved with the help of Howard Chu.¶