<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-codere-ldapsyntax-10"
  ipr="trust200902"
  obsoletes=""
  updates=""
  xml:lang="en"
  version="3">
<!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="LDAP Additional syntaxes">Lightweight Directory Access Protocol (LDAP):
                      Additional Syntaxes</title>
    <seriesInfo name="Internet-Draft" value="draft-codere-ldapsyntax-10"/>
   
    <author fullname="Carl Eric Codere" initials="C. E." role="editor" surname="Codère">
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>Optima SC Inc.</organization>
      <address>
        <postal>
          <country>CA</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>carl.codere@optimasc.com</email>  
        <!-- Can have more than one <email> element -->
        <uri>http://www.optimasc.com</uri>
      </address>
    </author>
   
    <date year="2026"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>datatype</keyword>
    <keyword>object identifier</keyword>
    <keyword>LDAP</keyword>
    <keyword>Syntax definitions</keyword>
    
    <abstract>
      <t>This document registers additional syntax definitions for 
        use in Lightweight Directory Access Protocol (LDAP) directory and Directory services series X.500. This
        includes widely used datatypes and syntaxes. </t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t>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 IDENTIFIER types. Furthermore, these syntax
	  definitions can 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.</t>
      
      <section>
        <name>Conventions</name>
        <t>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 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
		  
		<t>Some of the syntax definitions are defined according to the regular expressions
		  defined in <xref target="RFC9485"/>.</t>
      </section>

    </section>
    <section>
      <name>Syntaxes</name>
      <t>The following additional syntaxes and their associated descriptions and OBJECT IDENTIFIER types are defined.</t>
	  
	  <section>
	    <name>ASN.1 Syntax Definitions</name>
		
	    <t>The following additional syntaxes are defined and are based on <xref target="ASN.1"/>.</t>
	    
	    <section anchor="DateSyntax">
	      <name>Date</name>
	      
	      <t>The Date type represents a date in the Gregorian calendar. It is defined as a useful TIME type 
	        in <xref target="ASN.1"/> and conforms to the extended format syntax of a calendar date as defined 
	        in <xref target="ISO.8601.2004"/>.</t> 
	        
	        
	        <t>A Date value <bcp14>SHALL</bcp14> 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. </t>
	      
	      <t>Examples:</t>
	      
	      <ul>
	        <li>9999-02-25</li>
	        <li>1583-01-31</li>
	      </ul>
	      
	      <t>The LDAP definition for the Date syntax is:</t>
	      
	      <ul>
	        <li>( 1.3.6.1.4.1.61799.5.40.31 DESC 'Date' )</li>
	      </ul>
	      
	      <t>This syntax corresponds to the DATE ASN.1 type from <xref target="ASN.1"/>.</t>
	    </section>
	    
	    
	    
	    <section>
	      <name>Date-Time</name>
	      
	      <t>The Date-time type represents a date and local time using a 24 hour clock. It is defined as a useful TIME type 
	        in <xref target="ASN.1"/> and conforms to the extended format syntax of a date and time without
	        any timezone specifier as defined in <xref target="ISO.8601.2004"/>.</t>
	      
	      <t>A Date-Time value <bcp14>SHALL</bcp14> 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.</t>
	      
	      
	      <t>Examples:</t>
	      
	      <ul>
	        <li>1583-01-01T00:59:59</li>
	        <li>1975-01-19T23:45:34</li>
	      </ul>
	      
	      <t>The LDAP definition for the Date-Time syntax is:</t>
	      
	      <ul>
	        <li>( 1.3.6.1.4.1.61799.5.40.33 DESC 'Date-Time' )</li>
	      </ul>
	      
	      <t>This syntax corresponds to the DATE-TIME ASN.1 type from <xref target="ASN.1"/>.</t>
	    </section>
	    
	    
	    <section anchor="DurationSyntax">
	      <name>Duration</name>
	      
	      <t>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 <xref target="ASN.1"/> and conforms to a subset of the extended format syntax of a time interval by duration as 
	        defined in <xref target="ISO.8601.2004"/>.</t>     
	      
	      <t>A duration syntax value <bcp14>SHALL</bcp14> conform to the following regular expression, 
	        and additionally at least one component designator and its associated value<bcp14>SHALL</bcp14> be present 
	        (i.e., the strings "P" and "PT" are not valid Duration values):</t>
	      
	      <sourcecode>P([0-9]+Y)?([0-9]+M)?([0-9]+D)?(T([0-9]+H)?([0-9]+M)?([0-9]+(\.[0-9]{1,3})?S)?)?</sourcecode>
	      
	      <t>If the number of years, months, days, hours, minutes, or seconds in any expression equals zero, 
	        the number and its corresponding designator <bcp14>MAY</bcp14> be omitted. 
	        However, at least one number and its designator <bcp14>SHALL</bcp14> be present.</t>
	      
	      <t>Examples:</t>
	      
	      <ul>
	        <li>P29M0D   -- 29 months, 0 days to an accuracy of 1 day. </li>
	        <li>P29MT0S  -- 29 months, 0 days, 0 hours, 0 minutes, 0 seconds, to an accuracy of 1 second.</li>
	        <li>PT3445.5S  -- 3445.5 seconds</li>
	      </ul>
	      
	      <t>The LDAP definition for the Duration syntax is:</t>
	      
	      <ul>
	        <li>( 1.3.6.1.4.1.61799.5.40.34 DESC 'Duration' )</li>
	      </ul>
	      
	      <t>This syntax corresponds to a very strict subset of the DURATION ASN.1 type from <xref target="ASN.1"/>, in that
	        the order of parameters need to be respected and fractional values <bcp14>SHALL</bcp14> only apply to the seconds designation
	        and when present, are limited up to 3 digits (millisecond precision).</t>	      
	    </section>
	    
	    <section anchor="RealSyntax">
	      <name>Real</name>
	      
	      <t>The Real type represents the computational approximations to the mathematical "real number". The
	        format for the Real is as defined in Section 21 of <xref target="ASN.1"/>.</t> 
	      
	      <t>A Real syntax value <bcp14>SHALL</bcp14> conform to the following regular expression:</t>
	      
	      <sourcecode>([-]?[0-9]+(\.[0-9]+)?([E][-]?[0-9]+)?)|PLUS-INFINITY|MINUS-INFINITY|NOT-A-NUMBER</sourcecode>
	      
	      <t>Examples:</t>
	      
	      <ul>
	        <li>3.14159</li>
	        <li>MINUS-INFINITY</li>
	        <li>0</li>
	        <li>-5.3E4 -- Equal to -53000</li>
	        <li>5E3 -- 5000</li>
	      </ul>
	      
	      <t>The LDAP definition for the Real syntax is:</t>
	      
	      <ul>
	        <li>( 1.3.6.1.4.1.61799.5.40.9 DESC 'Real' )</li>
	      </ul>
	      
	      <t>This syntax corresponds to a subset of the REAL ASN.1 type from
	        <xref target="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, where the preceding optional "+" sign is prohibited in both
	        the mantissa and the exponent, and where leading zeros in the integer
	        part <bcp14>SHALL NOT</bcp14> be present unless the integer part is
	        "0".
	      </t>
	    </section>
	    
	    <section anchor="TimeOfDaySyntax">
	      <name>Time Of Day</name>
	      
	      <t>The Time Of Day type represents a local time using a 24 hour clock. It is defined as a useful TIME type 
	        in <xref target="ASN.1"/> and conforms to the extended format syntax of a local time as defined 
	        in <xref target="ISO.8601.2004"/>. </t>
	      
	      <t>A Time Of Day value <bcp14>SHALL</bcp14> 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.</t>
	      
	      <t>Examples for Time Of Day:</t>
	      
	      <ul>
	        <li>00:59:59</li>
	        <li>01:45:54</li>
	      </ul>
	      
	      <t>The LDAP definition for the Time Of Day syntax is:</t>
	      
	      <ul>
	        <li>( 1.3.6.1.4.1.61799.5.40.32 DESC 'Time Of Day' )</li>
	      </ul>
	      
	      <t>This syntax corresponds to the TIME-OF-DAY ASN.1 type from <xref target="ASN.1"/>.</t>
	    </section>
	    
	    
	    <section anchor="VisibleStringSyntax">
	      <name>Visible String</name>
	      
	      <t>The Visible String type represents a character repertoire that contains the printable ASCII character 
	        set (in the Unicode range U+0020 to U+007E). It is defined in 
	        <xref target="ASN.1"/>.</t>
	      
	      <t>This syntax value <bcp14>SHALL</bcp14> conform to the following regular expression:</t>
	      
	      <sourcecode>[0-9A-Za-z !&quot;#$%&amp;&apos;()*+,\-./:;&lt;=&gt;?@\[\\\]^_`{|}~]*</sourcecode>
	      
	      <t>Examples:</t>
	      
	      <ul>
	        <li>hello world</li>
	        <li>(x+y)=z</li>
	      </ul>
	      
	      <t>The LDAP definition for the Visible String syntax is:</t>
	      
	      <ul>
	        <li>( 1.3.6.1.4.1.61799.5.40.26 DESC 'Visible String' )</li>
	      </ul>
	      
	      <t>This syntax corresponds to the VisibleString ASN.1 type from <xref target="ASN.1"/>.</t>
	    </section>
	    

	  </section>
      
      <section>
	      <name>Constrained ASN.1 Syntax Definitions</name>
	      
	      <t>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. </t>
	       
        
        <section>
          <name>Float32</name>
          
          <t>The Float32 type represents a real number which fits in the range of a <xref target="IEEE_754_2019"/> single precision floating
            point value.</t>
          
          <t>The Float32 syntax follows the base 10 syntax of the real type (See <xref target="RealSyntax"/>) with a constrained range.
            For equality matching purposes, negative zero <bcp14>SHALL</bcp14> be considered equal to positive zero and
            NOT-A-NUMBER <bcp14>SHALL NOT</bcp14> be considered equal to any value, including itself.</t>
          
          <t>Examples:</t>
          
          <ul>
            <li>3.14159 -- value will be rounded to the nearest representable value</li>
            <li>MINUS-INFINITY</li>
            <li>-5.3E4 -- Equal to -53000</li>
          </ul>
          
          <t>The LDAP definition for the Float32 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.9.4 DESC 'Float32' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          <sourcecode type="asn.1">
Float32 ::= REAL (WITH COMPONENTS {
  mantissa (-16777215..16777215),
  base (2),
  exponent (-149..104) })
        </sourcecode>
        </section>
        
        <section>
          <name>Float64</name>
          
          <t>The Float64 type represents a real number which fits in the range of a <xref target="IEEE_754_2019"/> double precision floating
            point value.</t>
          
          
          <t>The Float64 syntax follows the base 10 syntax of the real type (See <xref target="RealSyntax"/>) with a constrained range.
            For equality matching purposes, negative zero <bcp14>SHALL</bcp14> be considered equal to positive zero and
            NOT-A-NUMBER <bcp14>SHALL NOT</bcp14> be considered equal to any value, including itself.</t>
          
          <t>Examples:</t>
          
          <ul>
            <li>3.1415926535897932 -- value will be rounded to the nearest representable value</li>
            <li>NOT-A-NUMBER</li>
            <li>-5.3E4 -- Equal to -53000</li>
          </ul>
          
          <t>The LDAP definition for the Float64 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.9.8 DESC 'Float64' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          <sourcecode type="asn.1">
Float64 ::= REAL (WITH COMPONENTS {
 mantissa (-9007199254740991..9007199254740991),
 base (2),
 exponent (-1074..971) })
          </sourcecode>
        </section>
        
        
        <section>
          <name>UInt8</name>
          
          <t>The UInt8 type represents an unsigned integer value within the range 0 to 255 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>0</li>
            <li>34</li>
          </ul>
          
          <t>The LDAP definition for the UInt8 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.21 DESC 'UInt8' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">UInt8 ::= INTEGER(0..255)</sourcecode>
          
        </section>
        
        <section>
          <name>UInt16</name>
          
          <t>The UInt16 type represents an unsigned integer value within the range 0 to 65535 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>0</li>
            <li>64991</li>
          </ul>
          
          <t>The LDAP definition for the UInt16 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.22 DESC 'UInt16' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">UInt16 ::= INTEGER(0..65535)</sourcecode>
          
        </section>
        
        <section>
          <name>UInt32</name>
          
          <t>The UInt32 type represents an unsigned integer value within the range 0 to 4294967295 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>0</li>
            <li>40000000</li>
          </ul>
          
          <t>The LDAP definition for the UInt32 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.24 DESC 'UInt32' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">UInt32 ::= INTEGER(0..4294967295)</sourcecode>
          
        </section>
        
        <section>
          <name>UInt64</name>
          
          <t>The UInt64 type represents an unsigned integer value within the range 0 to 18446744073709551615 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>0</li>
            <li>844674407370955</li>
          </ul>
          
          <t>The LDAP definition for the UInt64 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.28 DESC 'UInt64' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">UInt64 ::= INTEGER(0..18446744073709551615)</sourcecode>
          
        </section>
        
        
        
        <section>
          <name>Int8</name>
          
          <t>The Int8 type represents a signed integer value within the range -128 to 127 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>0</li>
            <li>-123</li>
          </ul>
          
          <t>The LDAP definition for the Int8 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.1 DESC 'Int8' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">Int8 ::= INTEGER(-128..127)</sourcecode>
          
        </section>
        
        <section>
          <name>Int16</name>
          
          <t>The Int16 type represents a signed integer value within the range -32768 to 32767 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>15667</li>
            <li>-32000</li>
          </ul>
          
          <t>The LDAP definition for the Int16 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.2 DESC 'Int16' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">Int16 ::= INTEGER(-32768 .. 32767)</sourcecode>
          
        </section>
        
        
        <section>
          <name>Int32</name>
          
          <t>The Int32 type represents a signed integer value within the range -2147483648 to 2147483647 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>15667</li>
            <li>-3200000</li>
          </ul>
          
          <t>The LDAP definition for the Int32 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.4 DESC 'Int32' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">Int32 ::= INTEGER(-2147483648..2147483647)</sourcecode>
          
        </section>
        
        <section>
          <name>Int64</name>
          
          <t>The Int64 type represents a signed integer value within the range -9223372036854775808 to 9223372036854775807 inclusive. </t>
          
          <t>Examples:</t>
          
          <ul>
            <li>-2337203685477580</li>
            <li>3372036854775807</li>
          </ul>
          
          <t>The LDAP definition for the Int64 type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.8 DESC 'Int64' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">Int64 ::= INTEGER(-9223372036854775808..9223372036854775807)</sourcecode>
          
        </section>
        
        <section>
          <name>Percentage</name>
          
          <t>The Percentage type represents a percentage value, that is an unsigned integer in the range 0 to 100 inclusive.</t>
          
          <t>Examples:</t>
          
          <ul>
            <li>0</li>
            <li>99</li>
          </ul>
          
          <t>The LDAP definition for the Percentage type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.2.20 DESC 'Percentage' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">Percentage ::= INTEGER(0..100)</sourcecode>
        </section>
        
	  
    </section>   
      
      <section>
	      <name>Other Syntax Definitions</name>
	      
	      <t>The following additional syntaxes are defined and are based on IETF RFC's, or other international standards.</t>
        
        <section>
          <name>Language</name>
          
          <t>A language provides a representation of a spoken or written language as well as an optional region and other specifiers.  The
            exact syntax allowed is defined in Section 2 of <xref target="RFC5646"/>.</t>    
          
          <t>A Language syntax value <bcp14>SHALL</bcp14> conform to the following regular expression:</t>
          
          <sourcecode>([a-zA-Z]{2,8}|x-[a-zA-Z0-9]{1,8})(-[a-zA-Z0-9]{1,8})*</sourcecode>
          
          <t>The regular expression provides a structural check only. Conformance
            to the full syntax defined in <xref target="RFC5646"/>
            is additionally required.</t>          
          
          <t>Examples:</t>
          
          <ul>
            <li>en</li>
            <li>fr-CA</li>
          </ul>
          
          
          <t>The LDAP definition for the Language syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.19.1 DESC 'Language' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/>:</t>
          
          <sourcecode type="asn.1">
Language ::= PrintableString (PATTERN "([a-zA-Z]#(2,8)|x-[a-zA-Z0-9]#(1,8))(-[a-zA-Z0-9]#(1,8))*")            
  -- ISO 639 code minimally</sourcecode>          
          
        </section>

        <section>
          <name>Media type</name>
          
          <t>The Media Type syntax identifies values that represent an IANA registered Media type <xref target="IANAREG"/>. The
            format for the MIME Media type is defined in Section 4.2 of <xref target="RFC6838"/>.</t> 
          
          <t>This syntax value <bcp14>SHALL</bcp14> conform to the following regular expression:</t>
          
          <sourcecode>[A-Za-z0-9]([A-Za-z0-9!#$&amp;^_.+-]){0,126}/[A-Za-z0-9]([A-Za-z0-9!#$&amp;^_.+-]){0,126}</sourcecode>
          
          <t>Examples:</t>
          
          <ul>
            <li>text/xhtml</li>
            <li>application/alto-costmap+json</li>
          </ul>
          
          <t>The LDAP definition for the MIME Media type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.26.5 DESC 'Media Type' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ITU.X520.2019"/>:</t>
          
          <sourcecode type="asn.1">MediaType ::= VisibleString (SIZE(3..255))</sourcecode>
          
        </section>
        
        
     <section anchor="OpenDateSyntax">
	   <name>OpenDate</name>
	   
	   <t>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 <xref target="W3C.NOTE-datetime-19980827"/> with
	     a 3 digit fraction. The time component, when present, always contains timezone information.</t>     
	    
      <t>Examples:</t>

        <ul>
         <li>2034</li>
         <li>1975-01</li>
         <li>1975-01-19</li>
         <li>1975-01-19T19:20+01:00</li>
         <li>1975-01-19T19:20:30+01:00</li>
         <li>1975-01-19T19:20:30.451+01:00</li>
         <li>1975-01-19T18:20Z</li>
         <li>1975-01-19T18:20:30Z</li>
         <li>1975-01-19T18:20:30.451Z</li>
	   </ul>
		
   
      <t>The LDAP definition for the OpenDate syntax is:</t>

      <ul>
        <li>( 1.3.6.1.4.1.61799.5.40.14.1 DESC 'OpenDate' )</li>
      </ul>
	    
	    
	    <t>This syntax corresponds to a subset of the TIME ASN.1 type from <xref target="ASN.1"/> with the specified
	      configuration:</t>
	    
	    <sourcecode type="asn.1">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"))
	    </sourcecode>
	    
	  </section>

        <section anchor="URISyntax">
          <name>URI</name>
          
          <t>The URI syntax type identifies values that are referenced by a Uniform Resource Identifier (URI). The
            format and encoding for the URI is as defined in <xref target="RFC3986"/>. Even if relative URIs are allowed, it is 
            <bcp14>RECOMMENDED</bcp14> they not be used unless the context of use is known.</t>     
          
          <t>Examples:</t>
          
          <ul>
            <li>http://www.example.com/my/picture.jpg</li>
            <li>ldap://ldap.example.com/cn=babs%20jensen</li>
          </ul>
          
          <t>The LDAP definition for the URI syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.26.4 DESC 'URI' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ITU.X520.2019"/>:</t>
          
          <sourcecode type="asn.1">URI ::= VisibleString (SIZE (1..ub-uri-length)) -- ub-uri-length MUST be at least 2000</sourcecode>
          
          <t>The value of ub-uri-length (an integer) is implementation
            defined but <bcp14>MUST</bcp14> be at least 2000 characters.</t>        
          
        </section>
        
        
        <section anchor="NCNameSyntax">
          <name>NCName</name>
          
          <t>The NCName syntax type should be used to identify values that represent identifiers and
            local attribute names. A name is a subset of the <tt>NCName</tt> definition in <xref target="W3C.xml-names11"/>.</t>
          
          <t>This syntax value <bcp14>SHALL</bcp14> conform to the following regular expression:</t>
          
          <sourcecode>[\p{L}\p{Nl}_][\p{L}\p{Nl}\p{Nd}._-]*</sourcecode>
          
          <t>Examples:</t>
          
          <ul>
            <li>MyID</li>
            <li>attribute.0.subdivision</li>
          </ul>
          
          <t>The LDAP definition for the NCName type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.12.6 DESC 'NCName' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ITU.X520.2019"/>:</t>
          
          <sourcecode type="asn.1">
-- NOTE: This type does not capture the
-- structural constraints on permitted characters and start characters.
-- The regular expression is the normative definition of valid values
NCName ::= UnboundedDirectoryString
          </sourcecode>
          
        </section>
        
        <section anchor="QualifiedNameSyntax">
          <name>Qualified Name</name>
          
          <t>The Qualified Name syntax type identifies values that represent identifiers and
            attribute names using namespaces. This is a subset of the <tt>QName</tt> definition in <xref target="W3C.xml-names11"/>.</t>
          
          <t>This syntax value <bcp14>SHALL</bcp14> conform to the following regular expression:</t>
          
          <sourcecode>[\p{L}\p{Nl}_][\p{L}\p{Nl}\p{Nd}._-]*(:[\p{L}\p{Nl}_][\p{L}\p{Nl}\p{Nd}._-]*)?</sourcecode>
          
          <t>Examples:</t>
          
          <ul>
            <li>MyID</li>
            <li>attribute.0:subdivision</li>
          </ul>
          
          <t>The LDAP definition for the QualifiedName type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.12.7 DESC 'QualifiedName' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ITU.X520.2019"/>:</t>
          
          <sourcecode type="asn.1">
-- NOTE: This type does not capture the
-- structural constraints on permitted characters and start characters.
-- The regular expression is the normative definition of valid values
QualifiedName ::= UnboundedDirectoryString
          </sourcecode>
          
        </section>
        
        <section anchor="TextSyntax">
          <name>Text</name>
          
          <t>The Text type represents a Unicode string with a restricted character repertoire. A Text string value
            <bcp14>MUST NOT</bcp14> contain any code point that has any of the following properties, as defined in the
            Unicode Character Database <xref target="Unicode"/>:</t>
          
          <ul>
            <li>General_Category of Cc (Control), with the exception of U+0009 (CHARACTER TABULATION), U+000A (LINE FEED),
              and U+000D (CARRIAGE RETURN), which are permitted;</li>
            <li>General_Category of Cs (Surrogate);</li>
            <li>General_Category of Co (Private_Use);</li>
            <li>Noncharacter_Code_Point, as defined in PropList.txt of the Unicode Character Database. This is a fixed set
              of 66 code points: U+FDD0..U+FDEF and U+nFFFE..U+nFFFF (where n ranges from 0 to 10 in hexadecimal).</li>
          </ul>          
          
          <t>See <xref target="Security"/> for security considerations regarding the handling, 
            display, and comparison of values containing 
            format characters or bidirectional controls.</t>          
          
          <t>Examples:</t>
          
          <ul>
            <li>Hello world</li>
            <li>Ceci est une phrase qui est encore plus longue que la précédente</li>
          </ul>
          
          <t>The LDAP definition for the Text type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.12.3 DESC 'Text' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ITU.X520.2019"/>:</t>
          
          <sourcecode type="asn.1"><![CDATA[
  Text ::= CHOICE {
    printableString  PrintableString,
    bmpString        BMPString
      (FROM(
        {0, 0, 0, 9}   .. {0, 0, 0, 10}   | -- U+0009..U+000A
        {0, 0, 0, 13}  .. {0, 0, 0, 13}   | -- U+000D
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  | -- U+0020..U+007E
        {0, 0, 0, 160} .. {0, 0, 215, 255} | -- U+00A0..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} -- U+FDF0..U+FFFD
      )),
    universalString  UniversalString
      (FROM(
        {0, 0, 0, 9}   .. {0, 0, 0, 10}   | -- U+0009..U+000A
        {0, 0, 0, 13}  .. {0, 0, 0, 13}   | -- U+000D
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  | -- U+0020..U+007E
        {0, 0, 0, 160} .. {0, 0, 215, 255} | -- U+00A0..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} | -- U+FDF0..U+FFFD
        {0, 1, 0, 0}   .. {0, 1, 255, 253} | -- U+10000..U+1FFFD
        {0, 2, 0, 0}   .. {0, 2, 255, 253} | -- U+20000..U+2FFFD
        {0, 3, 0, 0}   .. {0, 3, 255, 253} | -- U+30000..U+3FFFD
        {0, 4, 0, 0}   .. {0, 4, 255, 253} | -- U+40000..U+4FFFD
        {0, 5, 0, 0}   .. {0, 5, 255, 253} | -- U+50000..U+5FFFD
        {0, 6, 0, 0}   .. {0, 6, 255, 253} | -- U+60000..U+6FFFD
        {0, 7, 0, 0}   .. {0, 7, 255, 253} | -- U+70000..U+7FFFD
        {0, 8, 0, 0}   .. {0, 8, 255, 253} | -- U+80000..U+8FFFD
        {0, 9, 0, 0}   .. {0, 9, 255, 253} | -- U+90000..U+9FFFD
        {0, 10, 0, 0}  .. {0, 10, 255, 253} | -- U+A0000..U+AFFFD
        {0, 11, 0, 0}  .. {0, 11, 255, 253} | -- U+B0000..U+BFFFD
        {0, 12, 0, 0}  .. {0, 12, 255, 253} | -- U+C0000..U+CFFFD
        {0, 13, 0, 0}  .. {0, 13, 255, 253} | -- U+D0000..U+DFFFD
        {0, 14, 0, 0}  .. {0, 14, 255, 253}  -- U+E0000..U+EFFFD
      )),
    utf8String       UTF8String
      (FROM(
        {0, 0, 0, 9}   .. {0, 0, 0, 10}   | -- U+0009..U+000A
        {0, 0, 0, 13}  .. {0, 0, 0, 13}   | -- U+000D
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  | -- U+0020..U+007E
        {0, 0, 0, 160} .. {0, 0, 215, 255} | -- U+00A0..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} | -- U+FDF0..U+FFFD
        {0, 1, 0, 0}   .. {0, 1, 255, 253} | -- U+10000..U+1FFFD
        {0, 2, 0, 0}   .. {0, 2, 255, 253} | -- U+20000..U+2FFFD
        {0, 3, 0, 0}   .. {0, 3, 255, 253} | -- U+30000..U+3FFFD
        {0, 4, 0, 0}   .. {0, 4, 255, 253} | -- U+40000..U+4FFFD
        {0, 5, 0, 0}   .. {0, 5, 255, 253} | -- U+50000..U+5FFFD
        {0, 6, 0, 0}   .. {0, 6, 255, 253} | -- U+60000..U+6FFFD
        {0, 7, 0, 0}   .. {0, 7, 255, 253} | -- U+70000..U+7FFFD
        {0, 8, 0, 0}   .. {0, 8, 255, 253} | -- U+80000..U+8FFFD
        {0, 9, 0, 0}   .. {0, 9, 255, 253} | -- U+90000..U+9FFFD
        {0, 10, 0, 0}  .. {0, 10, 255, 253} | -- U+A0000..U+AFFFD
        {0, 11, 0, 0}  .. {0, 11, 255, 253} | -- U+B0000..U+BFFFD
        {0, 12, 0, 0}  .. {0, 12, 255, 253} | -- U+C0000..U+CFFFD
        {0, 13, 0, 0}  .. {0, 13, 255, 253} | -- U+D0000..U+DFFFD
        {0, 14, 0, 0}  .. {0, 14, 255, 253}  -- U+E0000..U+EFFFD
      ))
  }
]]></sourcecode>            
        </section>
        
        
        
        <section anchor="normalizedStringSyntax">
          <name>Normalized String</name>
          
          <t>The Normalized String type represents a whitespace-normalized
            Unicode string. A Normalized String value <bcp14>SHALL</bcp14>
            conform to all the restrictions of the Text type
            (<xref target="TextSyntax"/>), with the following additional
            constraints:</t>
          
          <t>Prior to validation, the following code points
            <bcp14>SHALL</bcp14> be mapped to U+0020 (SPACE):</t>
          
          <ul>
            <li>U+0009 (CHARACTER TABULATION), U+000A (LINE FEED),
              and U+000D (CARRIAGE RETURN);</li>
            <li>Code points with General_Category Zs (Space_Separator)
              other than U+0020 (SPACE);</li>
            <li>Code points with General_Category Zl (Line_Separator)
              or Zp (Paragraph_Separator).</li>
          </ul>
          
          <t>The canonical form of a Normalized String contains only
            U+0020 SPACE as a whitespace character. All other Unicode
            scalar values permitted by the Text type are permitted.</t>
          
          
          <t>See <xref target="Security"/> for security considerations regarding the handling, 
            display, and comparison of values containing 
            format characters or bidirectional controls.</t>          
          
          <t>Examples:</t>
          
          <ul>
            <li>   Paragraph start with some leading spaces.</li>
            <li>This is some other text with spaces.</li>
          </ul>
          
          <t>The LDAP definition for the Normalized String syntax
            is:</t>

          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.12.4 DESC 'Normalized String' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type
            definition:</t>
          
          <sourcecode type="asn.1"><![CDATA[
  NormalizedString ::= CHOICE {
    printableString  PrintableString,
    bmpString        BMPString
      (FROM(
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  |  -- U+0020..U+007E
        {0, 0, 0, 161} .. {0, 0, 22, 127} |  -- U+00A1..U+167F
        {0, 0, 22, 129} .. {0, 0, 31, 255} | -- U+1681..U+1FFF
        {0, 0, 32, 11} .. {0, 0, 32, 39}  |  -- U+200B..U+2027
        {0, 0, 32, 42} .. {0, 0, 32, 46}  |  -- U+202A..U+202E
        {0, 0, 32, 48} .. {0, 0, 32, 94}  |  -- U+2030..U+205E
        {0, 0, 32, 96} .. {0, 0, 47, 255} |  -- U+2060..U+2FFF
        {0, 0, 48, 1}  .. {0, 0, 215, 255} | -- U+3001..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} -- U+FDF0..U+FFFD
      )),
    universalString  UniversalString
      (FROM(
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  |  -- U+0020..U+007E
        {0, 0, 0, 161} .. {0, 0, 22, 127} |  -- U+00A1..U+167F
        {0, 0, 22, 129} .. {0, 0, 31, 255} | -- U+1681..U+1FFF
        {0, 0, 32, 11} .. {0, 0, 32, 39}  |  -- U+200B..U+2027
        {0, 0, 32, 42} .. {0, 0, 32, 46}  |  -- U+202A..U+202E
        {0, 0, 32, 48} .. {0, 0, 32, 94}  |  -- U+2030..U+205E
        {0, 0, 32, 96} .. {0, 0, 47, 255} |  -- U+2060..U+2FFF
        {0, 0, 48, 1}  .. {0, 0, 215, 255} | -- U+3001..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} | -- U+FDF0..U+FFFD
        {0, 1, 0, 0}   .. {0, 1, 255, 253} | -- U+10000..U+1FFFD
        {0, 2, 0, 0}   .. {0, 2, 255, 253} | -- U+20000..U+2FFFD
        {0, 3, 0, 0}   .. {0, 3, 255, 253} | -- U+30000..U+3FFFD
        {0, 4, 0, 0}   .. {0, 4, 255, 253} | -- U+40000..U+4FFFD
        {0, 5, 0, 0}   .. {0, 5, 255, 253} | -- U+50000..U+5FFFD
        {0, 6, 0, 0}   .. {0, 6, 255, 253} | -- U+60000..U+6FFFD
        {0, 7, 0, 0}   .. {0, 7, 255, 253} | -- U+70000..U+7FFFD
        {0, 8, 0, 0}   .. {0, 8, 255, 253} | -- U+80000..U+8FFFD
        {0, 9, 0, 0}   .. {0, 9, 255, 253} | -- U+90000..U+9FFFD
        {0, 10, 0, 0}  .. {0, 10, 255, 253} | -- U+A0000..U+AFFFD
        {0, 11, 0, 0}  .. {0, 11, 255, 253} | -- U+B0000..U+BFFFD
        {0, 12, 0, 0}  .. {0, 12, 255, 253} | -- U+C0000..U+CFFFD
        {0, 13, 0, 0}  .. {0, 13, 255, 253} | -- U+D0000..U+DFFFD
        {0, 14, 0, 0}  .. {0, 14, 255, 253}  -- U+E0000..U+EFFFD
      )),
    utf8String       UTF8String
      (FROM(
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  |  -- U+0020..U+007E
        {0, 0, 0, 161} .. {0, 0, 22, 127} |  -- U+00A1..U+167F
        {0, 0, 22, 129} .. {0, 0, 31, 255} | -- U+1681..U+1FFF
        {0, 0, 32, 11} .. {0, 0, 32, 39}  |  -- U+200B..U+2027
        {0, 0, 32, 42} .. {0, 0, 32, 46}  |  -- U+202A..U+202E
        {0, 0, 32, 48} .. {0, 0, 32, 94}  |  -- U+2030..U+205E
        {0, 0, 32, 96} .. {0, 0, 47, 255} |  -- U+2060..U+2FFF
        {0, 0, 48, 1}  .. {0, 0, 215, 255} | -- U+3001..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} | -- U+FDF0..U+FFFD
        {0, 1, 0, 0}   .. {0, 1, 255, 253} | -- U+10000..U+1FFFD
        {0, 2, 0, 0}   .. {0, 2, 255, 253} | -- U+20000..U+2FFFD
        {0, 3, 0, 0}   .. {0, 3, 255, 253} | -- U+30000..U+3FFFD
        {0, 4, 0, 0}   .. {0, 4, 255, 253} | -- U+40000..U+4FFFD
        {0, 5, 0, 0}   .. {0, 5, 255, 253} | -- U+50000..U+5FFFD
        {0, 6, 0, 0}   .. {0, 6, 255, 253} | -- U+60000..U+6FFFD
        {0, 7, 0, 0}   .. {0, 7, 255, 253} | -- U+70000..U+7FFFD
        {0, 8, 0, 0}   .. {0, 8, 255, 253} | -- U+80000..U+8FFFD
        {0, 9, 0, 0}   .. {0, 9, 255, 253} | -- U+90000..U+9FFFD
        {0, 10, 0, 0}  .. {0, 10, 255, 253} | -- U+A0000..U+AFFFD
        {0, 11, 0, 0}  .. {0, 11, 255, 253} | -- U+B0000..U+BFFFD
        {0, 12, 0, 0}  .. {0, 12, 255, 253} | -- U+C0000..U+CFFFD
        {0, 13, 0, 0}  .. {0, 13, 255, 253} | -- U+D0000..U+DFFFD
        {0, 14, 0, 0}  .. {0, 14, 255, 253}  -- U+E0000..U+EFFFD
      ))
  }
]]></sourcecode>    
        </section>
        
        <section>
          <name>Token</name>
          
          <t>The Token type represents a whitespace-normalized
            Unicode string. A Token value <bcp14>SHALL</bcp14>
            conform to all the restrictions of the Normalized String type
            (<xref target="normalizedStringSyntax"/>), with the following additional
            constraints:</t>
          
          <ul>
            <li>No leading and trailing U+0020 SPACE characters.</li>
            <li>No consecutive U+0020 SPACE characters.</li>
          </ul>
          
          <t>This is similar to the <tt>Token</tt> datatype in <xref target="W3C.xmlschema11-2"/>.</t>
          
          <t>The resulting canonical form is either the empty string,
            or a string that does not begin or end with U+0020 SPACE
            and contains no consecutive U+0020 SPACE characters.</t>          
          
          <t>See <xref target="Security"/> for security considerations regarding the handling, 
            display, and comparison of values containing 
            format characters or bidirectional controls.</t>
          
          <t>Examples:</t>
          
          <ul>
            <li>This is a token with spaces.</li>
            <li>_Token_</li>
          </ul>
          
          <t>The LDAP definition for the Token type syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.12.5 DESC 'Token' )</li>
          </ul>
          
          <t>This syntax corresponds to the following ASN.1 type from <xref target="ASN.1"/> :</t>
          
          <sourcecode type="asn.1"><![CDATA[
  Token ::= CHOICE {
    printableString  PrintableString
      (PATTERN "([^ ]+( [^ ]+)*)?"),
    bmpString        BMPString
      (FROM(
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  |  -- U+0020..U+007E
        {0, 0, 0, 161} .. {0, 0, 22, 127} |  -- U+00A1..U+167F
        {0, 0, 22, 129} .. {0, 0, 31, 255} | -- U+1681..U+1FFF
        {0, 0, 32, 11} .. {0, 0, 32, 39}  |  -- U+200B..U+2027
        {0, 0, 32, 42} .. {0, 0, 32, 46}  |  -- U+202A..U+202E
        {0, 0, 32, 48} .. {0, 0, 32, 94}  |  -- U+2030..U+205E
        {0, 0, 32, 96} .. {0, 0, 47, 255} |  -- U+2060..U+2FFF
        {0, 0, 48, 1}  .. {0, 0, 215, 255} | -- U+3001..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} -- U+FDF0..U+FFFD
      ))
      (PATTERN "([^ ]+( [^ ]+)*)?"),
    universalString  UniversalString
      (FROM(
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  |  -- U+0020..U+007E
        {0, 0, 0, 161} .. {0, 0, 22, 127} |  -- U+00A1..U+167F
        {0, 0, 22, 129} .. {0, 0, 31, 255} | -- U+1681..U+1FFF
        {0, 0, 32, 11} .. {0, 0, 32, 39}  |  -- U+200B..U+2027
        {0, 0, 32, 42} .. {0, 0, 32, 46}  |  -- U+202A..U+202E
        {0, 0, 32, 48} .. {0, 0, 32, 94}  |  -- U+2030..U+205E
        {0, 0, 32, 96} .. {0, 0, 47, 255} |  -- U+2060..U+2FFF
        {0, 0, 48, 1}  .. {0, 0, 215, 255} | -- U+3001..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} | -- U+FDF0..U+FFFD
        {0, 1, 0, 0}   .. {0, 1, 255, 253} | -- U+10000..U+1FFFD
        {0, 2, 0, 0}   .. {0, 2, 255, 253} | -- U+20000..U+2FFFD
        {0, 3, 0, 0}   .. {0, 3, 255, 253} | -- U+30000..U+3FFFD
        {0, 4, 0, 0}   .. {0, 4, 255, 253} | -- U+40000..U+4FFFD
        {0, 5, 0, 0}   .. {0, 5, 255, 253} | -- U+50000..U+5FFFD
        {0, 6, 0, 0}   .. {0, 6, 255, 253} | -- U+60000..U+6FFFD
        {0, 7, 0, 0}   .. {0, 7, 255, 253} | -- U+70000..U+7FFFD
        {0, 8, 0, 0}   .. {0, 8, 255, 253} | -- U+80000..U+8FFFD
        {0, 9, 0, 0}   .. {0, 9, 255, 253} | -- U+90000..U+9FFFD
        {0, 10, 0, 0}  .. {0, 10, 255, 253} | -- U+A0000..U+AFFFD
        {0, 11, 0, 0}  .. {0, 11, 255, 253} | -- U+B0000..U+BFFFD
        {0, 12, 0, 0}  .. {0, 12, 255, 253} | -- U+C0000..U+CFFFD
        {0, 13, 0, 0}  .. {0, 13, 255, 253} | -- U+D0000..U+DFFFD
        {0, 14, 0, 0}  .. {0, 14, 255, 253}  -- U+E0000..U+EFFFD
      ))
      (PATTERN "([^ ]+( [^ ]+)*)?"),
    utf8String       UTF8String
      (FROM(
        {0, 0, 0, 32}  .. {0, 0, 0, 126}  |  -- U+0020..U+007E
        {0, 0, 0, 161} .. {0, 0, 22, 127} |  -- U+00A1..U+167F
        {0, 0, 22, 129} .. {0, 0, 31, 255} | -- U+1681..U+1FFF
        {0, 0, 32, 11} .. {0, 0, 32, 39}  |  -- U+200B..U+2027
        {0, 0, 32, 42} .. {0, 0, 32, 46}  |  -- U+202A..U+202E
        {0, 0, 32, 48} .. {0, 0, 32, 94}  |  -- U+2030..U+205E
        {0, 0, 32, 96} .. {0, 0, 47, 255} |  -- U+2060..U+2FFF
        {0, 0, 48, 1}  .. {0, 0, 215, 255} | -- U+3001..U+D7FF
        {0, 0, 249, 0} .. {0, 0, 253, 207} | -- U+F900..U+FDCF
        {0, 0, 253, 240} .. {0, 0, 255, 253} | -- U+FDF0..U+FFFD
        {0, 1, 0, 0}   .. {0, 1, 255, 253} | -- U+10000..U+1FFFD
        {0, 2, 0, 0}   .. {0, 2, 255, 253} | -- U+20000..U+2FFFD
        {0, 3, 0, 0}   .. {0, 3, 255, 253} | -- U+30000..U+3FFFD
        {0, 4, 0, 0}   .. {0, 4, 255, 253} | -- U+40000..U+4FFFD
        {0, 5, 0, 0}   .. {0, 5, 255, 253} | -- U+50000..U+5FFFD
        {0, 6, 0, 0}   .. {0, 6, 255, 253} | -- U+60000..U+6FFFD
        {0, 7, 0, 0}   .. {0, 7, 255, 253} | -- U+70000..U+7FFFD
        {0, 8, 0, 0}   .. {0, 8, 255, 253} | -- U+80000..U+8FFFD
        {0, 9, 0, 0}   .. {0, 9, 255, 253} | -- U+90000..U+9FFFD
        {0, 10, 0, 0}  .. {0, 10, 255, 253} | -- U+A0000..U+AFFFD
        {0, 11, 0, 0}  .. {0, 11, 255, 253} | -- U+B0000..U+BFFFD
        {0, 12, 0, 0}  .. {0, 12, 255, 253} | -- U+C0000..U+CFFFD
        {0, 13, 0, 0}  .. {0, 13, 255, 253} | -- U+D0000..U+DFFFD
        {0, 14, 0, 0}  .. {0, 14, 255, 253}  -- U+E0000..U+EFFFD
      ))
      (PATTERN "([^ ]+( [^ ]+)*)?")
  }
]]></sourcecode>
        </section>
        
        
        
        <section anchor="TimeOfDayWithTimezoneSyntax">
          <name>Time Of Day with Timezone</name>


          <t>The Time Of Day with Timezone syntax type represents a time with explicit timezone information using a 24 hour clock. 
            It is defined as a TIME type in <xref target="ASN.1"/> and conforms to the extended format syntax of a time either
            represented as a local time followed by a UTC offset or as a UTC time indicated by the 'Z' designator, as defined in <xref target="ISO.8601.2004"/>. </t>
          
          <t>A Time Of Day with Timezone value <bcp14>SHALL</bcp14> 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.</t>
          
          <t>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 <xref target="ASN.1"/>.</t>
          
          <t>Examples:</t>
          
          <ul>
            <li>00:59:59Z</li>
            <li>01:45:54-01:00</li>
          </ul>
          
          <t>The LDAP definition for the Time Of Day with Timezone syntax is:</t>
          
          <ul>
            <li>( 1.3.6.1.4.1.61799.5.40.35 DESC 'Time Of Day with Timezone' )</li>
          </ul>
          
          <t>This syntax corresponds to a subset of the TIME ASN.1 type from <xref target="ASN.1"/> with the specified
            configuration:</t>
          
          <sourcecode type="asn.1">
Time-with-timezone ::=  
  TIME((SETTINGS "Basic=Time Time=HMS Local-or-UTC=LD")|
       (SETTINGS "Basic=Time Time=HMS Local-or-UTC=Z"))
          </sourcecode>
        </section>
        
        
	  
    </section>   
    </section>

    <section anchor="matchRules">
      <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>Matching rules</name>
      
      <t>This section defines matching rules for syntaxes that require comparison semantics beyond simple 
        string matching. Syntaxes not listed here use existing matching rules from
        <xref target="RFC4517"/>: integer types (Int8, Int16, Int32,
        Int64, UInt8, UInt16, UInt32, UInt64, Percentage) use
        <tt>integerMatch</tt> and <tt>integerOrderingMatch</tt>; string types (Text,
        Normalized String, Token, Visible String, NCName, Qualified Name)
        use <tt>caseExactMatch</tt>; Language and Media Type use <tt>caseIgnoreMatch</tt>;
        and Date and Date-Time use <tt>caseExactMatch</tt> and
        <tt>caseExactOrderingMatch</tt>.</t>

    <section>
      <name>uriMatch</name>
      
      <t>The uriMatch rule compares for equality a presented value with an attribute value of type 
        URI (<xref target="URISyntax"/>).</t>
      
       <t>The comparison is done using syntax-based normalization as defined in Section 6.2.2 of 
         <xref target="RFC3986"/>.</t>
      
      
      <t>The LDAP definition for the uriMatch rule is:</t>
      
      <ul>
        <li>( 1.3.6.1.4.1.61799.5.13.26.4 NAME 'uriMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.26.4 )</li>
      </ul>
      
      
      <t>The rule returns TRUE if the attribute value represents the same URI as the presented value.</t>
      
    </section>
      
      <section anchor="openDateMatch">
        <name>openDateMatch</name>
      
        <t>The openDateMatch rule compares for equality a presented value with an attribute value of type 
          OpenDate (<xref target="OpenDateSyntax"/>).</t>

        <t>For comparison purposes, OpenDate values <bcp14>SHALL</bcp14> first be normalized
          to a full date-time in UTC timezone using the following rules:</t>
        <ol>
          <li>If the month component is absent it is assumed to be one.</li>
          <li>If the day component is absent it is assumed to be one.</li>
          <li>If the hours component is absent it is assumed to be zero.</li>
          <li>If the minutes component is absent it is assumed to be zero.</li>
          <li>If the seconds component is absent it is assumed to be zero.</li>
          <li>If the decimal fraction component is absent it is assumed to be zero.</li>
          <li>If a timezone is present the date and time is normalized to the UTC timezone.</li>
          <li>If no timezone is present it is assumed, by convention, to be in the UTC timezone.</li>
          <li>If the time component indicates a value of 24:00:00 it is replaced by 00:00:00 and the day is incremented by one.</li>
        </ol>
        
        <t>This normalization procedure is inspired by, but not identical
          to, the implicit timezone and value comparison rules defined in
          Section 9.4 of <xref target="W3C.xpath-functions-31"/>. After
          normalization, values are compared chronologically.</t>
        
        <t>The LDAP definition for the openDateMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.14.1 NAME 'openDateMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.14.1 )</li>
        </ul>
        
        
      <t>The rule returns TRUE if the attribute value represents the same OpenDate as the presented value.</t>
      </section>
      
     <section anchor="openDateOrderingMatch">
        <name>openDateOrderingMatch</name>
      
      <t>The openDateOrderingMatch rule compares the ordering a presented value with an attribute value of type 
        OpenDate (<xref target="OpenDateSyntax"/>).</t>
        
       <t>Values are first normalized using the algorithm in <xref target="openDateMatch"/>. 
         The normalized values are then compared chronologically.</t>
        
        <t>The LDAP definition for the openDateOrderingMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.14.1.1 NAME 'openDateOrderingMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.14.1 )</li>
        </ul>
      
      <t>The rule returns TRUE if the attribute value represents an OpenDate which is earlier than the presented OpenDate.</t>
    </section>
      
      <section anchor="timeMatch">
        <name>timeMatch</name>
        
        <t>The timeMatch rule compares for equality a presented value with an attribute value of type 
          Time Of Day (<xref target="TimeOfDaySyntax"/>).</t>
        
        <t>Values are compared component by component (hours, minutes,
          seconds) in order of significance. A time
          value of 24:00:00 is considered end of day, and is therefore not equal to 00:00:00.</t>  
        
        <t>The LDAP definition for the timeMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.32 NAME 'timeMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.32 )</li>
        </ul>
        
        <t>The rule returns TRUE if the attribute value represents the same Time Of Day as the presented value.</t>
      </section>
      
      <section anchor="timeOrderingMatch">
        <name>timeOrderingMatch</name>
        
        <t>The timeOrderingMatch rule compares the ordering of a presented value with an attribute value of type 
          Time Of Day (<xref target="TimeOfDaySyntax"/>).</t>
        
        <t>Values are compared component by component (hours, minutes,
          seconds) in order of significance. A time
          value of 24:00:00 is considered end of day, and is therefore
          greater than 00:00:00.</t>  
        
        <t>The LDAP definition for the timeOrderingMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.32.1 NAME 'timeOrderingMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.32 )</li>
        </ul>
        
        <t>The rule returns TRUE if the attribute value represents a Time Of Day which is earlier than the presented Time Of Day.</t>
      </section>
      
      <section anchor="timeWithTZMatch">
        <name>timeWithTZMatch</name>
        
        <t>The timeWithTZMatch rule compares for equality a presented value with an attribute value of type 
          Time Of Day with Timezone (<xref target="TimeOfDayWithTimezoneSyntax"/>).</t>
        
        <t>Before comparison, both values are normalized to UTC. During
          normalization, a time value of 24:00:00 is replaced with
          00:00:00. After normalization, values are equal if and only if
          their hours, minutes and seconds components
          are identical.</t>
        
        <t>The LDAP definition for the timeWithTZMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.35 NAME 'timeWithTZMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.35 )</li>
        </ul>
        
        <t>The rule returns TRUE if the attribute value represents the same Time Of Day with Timezone as the presented value.</t>
      </section>
      
      <section anchor="timeWithTZOrderingMatch">
        <name>timeWithTZOrderingMatch</name>
        
        <t>The timeWithTZOrderingMatch rule compares the ordering of a presented value with an attribute value 
          of type Time Of Day with Timezone (<xref target="TimeOfDayWithTimezoneSyntax"/>).</t>
        
        <t>Before comparison, both values are normalized to UTC. During
          normalization, a time value of 24:00:00 is replaced with
          00:00:00. After normalization, values are compared component
          by component (hours, minutes, seconds) in
          order of significance.</t>
        
        <t>The LDAP definition for the timeWithTZOrderingMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.35.1 NAME 'timeWithTZOrderingMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.35 )</li>
        </ul>
        
        <t>The rule returns TRUE if the attribute value represents a Time Of Day with Timezone which is earlier than the presented 
          Time Of Day with Timezone.</t>
      </section>
      
      <section anchor="realMatch">
        <name>realMatch</name>
        
        <t>The realMatch rule compares for equality a presented value
          with an attribute value of type Real
          (<xref target="RealSyntax"/>).</t>
        
        <t>This matching rule also applies to the Float32 and Float64
          syntaxes, which are constrained subsets of the Real syntax.</t>        
        
        <t>Values are compared by their mathematical value.
          NOT-A-NUMBER is not equal to any value, including itself.
          Negative zero is equal to positive zero.
          MINUS-INFINITY is equal only to itself, and
          PLUS-INFINITY is equal only to itself.</t>        
        
        <t>The LDAP definition for the realMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.9 NAME 'realMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.9 )</li>
        </ul>
        
        <t>The rule returns TRUE if the attribute value represents
          the same Real value as the presented value.</t>
      </section>
      
      <section>
        <name>realOrderingMatch</name>
        
        <t>The realOrderingMatch rule compares the ordering of a
          presented value with an attribute value of type Real
          (<xref target="RealSyntax"/>).</t>
        
        <t>This matching rule also applies to the Float32 and Float64
          syntaxes, which are constrained subsets of the Real syntax.</t>        
        
        <t>MINUS-INFINITY is less than all finite values and
          PLUS-INFINITY is greater than all finite values.
          Negative zero is equal to positive zero for ordering
          purposes. NOT-A-NUMBER is greater than all other values,
          including PLUS-INFINITY. All NOT-A-NUMBER values are
          considered equal for ordering purposes.</t>
        
        <t>Note: IEEE-754 <xref target="IEEE_754_2019"/> arithmetic comparison leaves NOT-A-NUMBER
          unordered with respect to all values. This rule instead
          assigns NOT-A-NUMBER a conventional position to ensure
          a total ordering, which is required for consistent
          indexing, sorting, and evaluation of inequality filters
          by directory implementations.</t>        
        
        <t>The LDAP definition for the realOrderingMatch rule is:</t>
        
        <ul>
          <li>( 1.3.6.1.4.1.61799.5.13.9.1 NAME 'realOrderingMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.9 )</li>
        </ul>
        
        <t>The rule returns TRUE if the attribute value is
          less than the presented value.</t>
      </section>      
    
    <section>
      <name>durationMatch</name>
      
      <t>The durationMatch rule compares for equality a presented
        value with an attribute value of type Duration (<xref target="DurationSyntax"/>).</t>
      
      <t>Two duration values are equal if and only if they
        represent the same total number of months and the same
        total number of milliseconds, where:</t>
      <ul>
        <li>Total months is (years x 12) + months.</li>
        <li>Total milliseconds is (days x 86400000) +
          (hours x 3600000) + (minutes x 60000) +
          (seconds x 1000) + milliseconds.</li>
      </ul>
      
      <t>Note that month components and day-time components are compared independently and are never 
        converted into each other. Consequently, a duration such as P1M (one month) is never equal to P30D (thirty days), 
        even though they may represent the same elapsed time for certain dates. 
        This behavior is intentional and consistent with the abstract definition of duration.</t>
      
      <t>Implementations <bcp14>SHOULD</bcp14> use integer
        arithmetic for these computations to avoid
        floating-point precision issues.</t>
      
      <t>The LDAP definition for the durationMatch rule is:</t>
      
      <ul>
        <li>( 1.3.6.1.4.1.61799.5.13.34 NAME 'durationMatch' SYNTAX 1.3.6.1.4.1.61799.5.40.34 )</li>
      </ul>
      
      <t>The rule returns TRUE if the attribute value represents the same duration as the presented value.</t>
    </section>    
    </section>  
    
    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      
      <t>IANA is requested to assign the LDAP values <xref target="RFC4520"/> specified in this
        document to <eref target="https://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml" />.</t>
      
      <section>
        <name>Syntax registration</name>
        
        <dl>
          <dt>Subject:</dt>
          <dd>Request for LDAP Syntax Registration</dd>
          <dt>Object Identifier:</dt>
          <dd>See table below</dd>
          <dt>Description:</dt>
          <dd>List of additional useful LDAP syntaxes</dd>
          <dt>Person &amp; email address to contact for further information:</dt>
          <dd>carl.codere@optimasc.com</dd>
          <dt>Specification/Reference: [ RFC-to-be ]</dt>
          <dd></dd>
          <dt>Author/Change Controller/Owner:</dt>
          <dd>IESG</dd>
          <dt>Comments: </dt>
          <dd>See table for list of additional syntaxes</dd>
        </dl>
        
        <table>
          <name>List of additional LDAP syntaxes</name>
          <thead><tr><th>Object Identifier</th><th>Syntax</th></tr></thead>
          <tbody>
            <tr><td>1.3.6.1.4.1.61799.5.40.31</td><td>Date</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.33</td><td>Date-Time</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.34</td><td>Duration</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.9.4</td><td>Float32</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.9.8</td><td>Float64</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.1</td><td>Int8</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.2</td><td>Int16</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.4</td><td>Int32</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.8</td><td>Int64</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.19.1</td><td>Language</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.12.6</td><td>NCName</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.12.4</td><td>Normalized String</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.26.5</td><td>Media Type</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.14.1</td><td>OpenDate</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.20</td><td>Percentage</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.12.7</td><td>QualifiedName</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.9</td><td>Real</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.12.3</td><td>Text</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.12.5</td><td>Token</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.32</td><td>Time Of Day</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.35</td><td>Time Of Day with Timezone</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.21</td><td>UInt8</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.22</td><td>UInt16</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.24</td><td>UInt32</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.2.28</td><td>UInt64</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.26.4</td><td>URI</td></tr>
            <tr><td>1.3.6.1.4.1.61799.5.40.26</td><td>Visible String</td></tr>
          </tbody>
        </table>
      </section>
      
      <section>
        <name>Object Identifier Descriptors registration</name>
        
        <dl>
          <dt>Subject:</dt>
          <dd>Request for LDAP Descriptor Registration</dd>
          <dt>Descriptor (short name):</dt>
          <dd>See table below</dd>
          <dt>Object Identifier:</dt>
          <dd>See table below</dd>
          <dt>Usage:</dt>
          <dd>matching rule</dd>
          <dt>Person &amp; email address to contact for further information:</dt>
          <dd>carl.codere@optimasc.com</dd>
          <dt>Specification/Reference: [ RFC-to-be ]</dt>
          <dd></dd>
          <dt>Author/Change Controller/Owner:</dt>
          <dd>IESG</dd>
          <dt>Comments: </dt>
          <dd>See table for list of additional matching rules</dd>
        </dl>
        
        <table>
          <name>List of additional descriptor registrations</name>
          <thead><tr><th>Name</th><th>OID</th></tr></thead>
          <tbody>
            <tr><td>durationMatch</td><td>1.3.6.1.4.1.61799.5.13.34</td></tr>
            <tr><td>openDateMatch</td><td>1.3.6.1.4.1.61799.5.13.14.1</td></tr>
            <tr><td>openDateOrderingMatch</td><td>1.3.6.1.4.1.61799.5.13.14.1.1</td></tr>
            <tr><td>realMatch</td><td>1.3.6.1.4.1.61799.5.13.9</td></tr>
            <tr><td>realOrderingMatch</td><td>1.3.6.1.4.1.61799.5.13.9.1</td></tr>
            <tr><td>timeMatch</td><td>1.3.6.1.4.1.61799.5.13.32</td></tr>
            <tr><td>timeOrderingMatch</td><td>1.3.6.1.4.1.61799.5.13.32.1</td></tr>
            <tr><td>timeWithTZMatch</td><td>1.3.6.1.4.1.61799.5.13.35</td></tr>
            <tr><td>timeWithTZOrderingMatch</td><td>1.3.6.1.4.1.61799.5.13.35.1</td></tr>
            <tr><td>uriMatch</td><td>1.3.6.1.4.1.61799.5.13.26.4</td></tr>
          </tbody>
        </table>
      </section>
      
      
    </section>
    
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>When interpreting security-sensitive fields (in particular, fields
        used to grant or deny access), implementations MUST ensure that any matching rule 
        comparisons are done on the underlying abstract value, regardless of the particular encoding used.</t>
      
      <section>
        <name>Text, Normalized String and Token</name>
        
        <t>The Text, Normalized String, and Token syntaxes have been
          defined for general textual information. For this reason,
          and for forward compatibility with future versions of the
          Unicode Standard, the prohibited code points have been kept
          to a minimum.</t>
        
        <t>These syntaxes permit Unicode format characters
          (General_Category Cf) because they are required for the
          correct representation of text in several scripts. 
          However, some format characters may pose security risks 
          when values are displayed or compared without 
          appropriate normalization. Applications <bcp14>MAY</bcp14> 
          impose additional restrictions on permitted code points 
          as a matter of local policy.</t>        
        
        <t>These syntaxes <bcp14>SHOULD NOT</bcp14> be used for
          security-sensitive attributes such as identifiers, group
          names, or access control labels. The NCName
          (<xref target="NCNameSyntax"/>) or Qualified Name
          (<xref target="QualifiedNameSyntax"/>) syntaxes
          <bcp14>SHOULD</bcp14> be used for such purposes
          instead.</t>
        
        <t>Text, Normalized String, and Token values
          <bcp14>SHOULD</bcp14> be matched and compared according
          to specific comparison rules, such as those defined in
          <xref target="RFC4518"/> or the PRECIS OpaqueString
          profile (<xref target="RFC8265"/>).</t>
        
      </section>
    </section>
    
    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9485.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml6/reference.R.IEEE.754-2019.xml"/>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4520.xml"/>
        
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.NOTE-datetime-19980827.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.xml-names11.xml" />        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.xmlschema11-2.xml"/>
        
         
        <!-- The recommended and simplest way to include a well known reference -->
        
          <reference anchor="ASN.1">
            <front>
              <title>Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
              <author>
                <organization>International Telecommunication Union</organization>
              </author>
              <date month="February" year="2021"/>
            </front>
            <seriesInfo name="ITU-T" value="Recommendation X.680"/>
          </reference>
        <reference anchor="ISO.8601.2004">
          <front>
            <title>Data elements and interchange formats - Information interchange - Representation of dates and times</title>
            <author>
              <organization>International Organization for Standardization</organization>
            </author>
            <date month="December" year="2004"/>
          </front>
          <seriesInfo name="ISO" value="Standard 8601"/>
        </reference>      
        <reference anchor="ITU.X520.2019">
          <front>
            <title>Information Technology - Open Systems Interconnection - The Directory: Selected attribute types</title>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date month="October" year="2019"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.520"/>
          <seriesInfo name="ISO" value="Standard 9594-7"/>
        </reference>
        <reference anchor="Unicode" target="http://www.unicode.org/versions/latest/">
          <front>
            <title>The Unicode Standard</title>
            <author>
              <organization>The Unicode Consortium</organization>
            </author>
          </front>
        </reference>        
        
      </references>
 
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4517.xml"/>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4518.xml"/>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8265.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.xpath-functions-31.xml"/>
        
        <reference anchor="ITU.X500.2019">
          <front>
            <title>Information Technology - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Services</title>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date month="October" year="2019"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.500"/>
          <seriesInfo name="ISO" value="Standard 9594-1"/>
        </reference>                
        <reference anchor="IANAREG" target="https://www.iana.org/assignments/media-types/media-types.xhtml">
          <front>
            <title>Media Types</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>                
      </references>
    
    </references>
    
    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>This document was sponsored by Andy Newton of the IETF ART group.</t>
      <t>Sean Turner acted as a shepherd for this document to help it become a proposed standard.</t>
    </section>
    
    <section anchor="Contributors" numbered="false">
      <name>Contributors</name>
      <t>This document was reviewed and improved with the help of Howard Chu. </t>
      
    </section>
    
 </back>
</rfc>
