RFC 4514

Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names

📅 published June 2006, from ietf

Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names 💖

  • Network Working Group, Request for Comments: 4514 🎀
  • Authors: K. Zeilenga, Ed. (OpenLDAP Foundation) 🧚
  • Date: June 2006 🌸
  • Category: Standards Track ✨
  • Obsoletes: RFC 2253 💅

Status of This Memo

okay so this one is a real Internet standards track protocol for the Internet community 🔥 It's basically asking everyone to talk about it and suggest improvements. For the official standardization state and status, you check the current edition of "Internet Official Protocol Standards" (STD 1) 👑 And distribution of this memo is unlimited, so share it with everyone bestie 💜

Copyright (C) The Internet Society (2006). 🦋

Abstract

the X.500 Directory uses distinguished names (DNs) as its primary keys for entries in the directory 🗝️ This document defines the string representation that the Lightweight Directory Access Protocol (LDAP) uses to transfer distinguished names. The vibe is a clean, easy-to-read format for the DNs people actually use every day, and it still has to be able to represent any distinguished name, no exceptions 💅

1. Background and Intended Usage ✨

so X.500-based directory systems, including the ones you reach through LDAP [RFC4510], use distinguished names (DNs) to refer to directory entries without any ambiguity [X.501][RFC4512] 🧚

The structure of a DN [X.501] is described with ASN.1 [X.680]. In the X.500 Directory Access Protocol [X.511] (and other ITU-defined directory protocols), DNs get encoded with the Basic Encoding Rules (BER) [X.690]. In LDAP, though, DNs show up in the string form this document describes 🎀

It's super important to have one common format so a distinguished name can be represented unambiguously 🙈 The main goal here is ease of encoding and decoding. A secondary goal is making names that humans can read. Honestly, LDAP apps with a human-facing UI probably won't show these strings raw to users. They'll most likely translate things, like writing attribute type names in the local language 🌈

This document defines the string representation of Distinguished Names used in LDAP [RFC4511][RFC4517]. Section 2 walks through the RECOMMENDED algorithm for turning a DN from its ASN.1 structured form into a string 🦋 Section 3 goes the other way, showing how to turn a string back into the ASN.1 structured representation 💖

Other documents are allowed to define other algorithms for going from the ASN.1 structured representation to a string, but all of those algorithms MUST produce strings that follow the requirements in Section 3 🔥

This document does NOT define a canonical string representation for DNs 🙅‍♀️ If you want to check whether two DNs are equal, you do that with the distinguishedNameMatch matching rule [RFC4517] 💅

This document is an integral part of the LDAP technical specification [RFC4510]. That spec obsoletes the earlier LDAP technical specification, RFC 3377, in its entirety. This document obsoletes RFC 2253, and you can see what changed since RFC 2253 in Appendix B 🌸

This spec assumes you're already familiar with X.500 [X.500] and the concept of a Distinguished Name [X.501][RFC4512] 🧚

1.1. Conventions

okay this part is the key word glossary 👑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] 💜

Character names in this document use the code point and name notation from the Unicode Standard [Unicode]. For example, the letter "a" may be written as either <U+0061> or <LATIN SMALL LETTER A> 🦋

Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel]. 🧚

2. Converting DistinguishedName from ASN.1 to a String 🦋

X.501 [X.501] defines the ASN.1 [X.680] structure of a distinguished name. The following is a variant offered up for discussion purposes 🫶

   DistinguishedName ::= RDNSequence

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
       AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {
       type  AttributeType,
       value AttributeValue }

This section defines the RECOMMENDED algorithm for converting a distinguished name from its ASN.1-structured representation into a UTF-8 [RFC3629] encoded Unicode [Unicode] character string 💖 Other documents may describe other algorithms for converting a distinguished name to a string, but only strings that conform to the grammar defined in Section 3 SHALL be produced by LDAP implementations 🔥

2.1. Converting the RDNSequence

If the RDNSequence is an empty sequence, the result is the empty or zero-length string 🙈

Otherwise, the output is the string encodings of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first 🔄

The encodings of adjoining RelativeDistinguishedNames are separated by a comma (, U+002C) character 🎀

2.2. Converting RelativeDistinguishedName

When you convert an ASN.1 RelativeDistinguishedName to a string, the output is the string encodings of each AttributeTypeAndValue (according to Section 2.3), in any order 🌈

If you've got a multi-valued RDN, the outputs from adjoining AttributeTypeAndValues get separated by a plus sign (+ U+002B) character ➕ ✨

2.3. Converting AttributeTypeAndValue

An AttributeTypeAndValue is encoded as the string representation of the AttributeType, then an equals sign (= U+003D) character, then the string representation of the AttributeValue. Section 2.4 has the encoding for the AttributeValue 🦋

If the AttributeType is defined to have a short name (descriptor) [RFC4512], and that short name is known to be registered [REGISTRY] [RFC4520] as identifying the AttributeType, then that short name, a <descr>, is used. Otherwise, the AttributeType is encoded as the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid> are defined in [RFC4512] 🧚

Implementations are not expected to dynamically update their knowledge of registered short names. However, implementations SHOULD provide a mechanism that lets them update their knowledge of registered short names 🔥

2.4. Converting an AttributeValue from ASN.1 to a String

If the AttributeType is of the dotted-decimal form, the AttributeValue is represented by a number sign (# U+0023) character, followed by the hexadecimal encoding of each of the octets of the BER encoding of the X.500 AttributeValue 🙈 This form is also used when the syntax of the AttributeValue doesn't have an LDAP-specific ([RFC4517], Section 3.1) string encoding defined for it, or when the LDAP-specific string encoding isn't restricted to UTF-8-encoded Unicode characters. This form can also be used in other cases, such as when you want a reversible string representation (see Section 5.2) 🌸

Otherwise, if the AttributeValue has a syntax with an LDAP-specific string encoding, the value gets converted first to a UTF-8-encoded Unicode string according to its syntax specification (see [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode string does NOT have any of the following characters that need escaping, then that string can be used as the string representation of the value 💅

  • a space (' ' U+0020) or number sign ('#' U+0023) occurring at the beginning of the string;
  • a space (' ' U+0020) character occurring at the end of the string;
  • one of the characters '"', '+', ',', ';', '<', '>', or '\' (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, respectively);
  • the null (U+0000) character.

Other characters MAY be escaped 🫶

Each octet of the character to be escaped is replaced by a backslash and two hex digits, which together form a single octet in the code of the character. Alternatively, if and only if the character to be escaped is one of

' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
 U+003C, U+003D, U+003E, U+005C, respectively)

it can be prefixed by a backslash (\ U+005C) 🌈

Examples of the escaping mechanism are shown in Section 4 ✨

3. Parsing a String Back to a Distinguished Name ✨

okay so the string version of Distinguished Names is restricted to UTF-8 [RFC3629] encoded Unicode [Unicode] characters 💅. Its structure is spelled out with this Augmented BNF [RFC4234] grammar, and I'm keeping it exactly as is because every character matters 🫶:

distinguishedName = [ relativeDistinguishedName
    *( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
    *( PLUS attributeTypeAndValue )
attributeTypeAndValue = attributeType EQUALS attributeValue
attributeType = descr / numericoid
attributeValue = string / hexstring

; The following characters are to be escaped when they appear
; in the value to be encoded: ESC, one of <escaped>, leading
; SHARP or SPACE, trailing SPACE, and NULL.
string =   [ ( leadchar / pair ) [ *( stringchar / pair )
   ( trailchar / pair ) ] ]

leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
   %x3D / %x3F-5B / %x5D-7F

trailchar  = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /

   %x3D / %x3F-5B / %x5D-7F

stringchar = SUTF1 / UTFMB
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
   %x3D / %x3F-5B / %x5D-7F

pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
hexstring = SHARP 1*hexpair
hexpair = HEX HEX

The productions <descr>, <numericoid>, <COMMA>, <DQUOTE>, <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, <SPACE>, <SHARP>, and <UTFMB> all come from [RFC4512] 🌸.

Each <attributeType> is either a <descr> or a <numericoid>, and it points at the attribute type of an attribute value assertion (AVA) 🦋. After it comes an <EQUALS> and then an <attributeValue>, which is either a <string> or a <hexstring> 💜.

If it's the <string> form, you can get the LDAP string representation of the asserted value by swapping out each <pair> (left to right, non-recursively) like this:

replace <ESC><ESC> with <ESC>;
replace <ESC><special> with <special>;
replace <ESC><hexpair> with the octet indicated by the <hexpair>.

If it's the <hexstring> form, you get a BER representation by turning each <hexpair> into the octet it indicates 🔥.

A relative distinguished name has one or more attribute value assertions, separated by <PLUS> 🧚. A distinguished name has zero or more relative distinguished names, separated by <COMMA> ✨.

Implementations MUST recognize AttributeType name strings (descriptors) listed in the following table, but MAY recognize other name strings 💖. Here's the table, in code because it's a table:

String  X.500 AttributeType
------  --------------------------------------------
CN      commonName (2.5.4.3)
L       localityName (2.5.4.7)
ST      stateOrProvinceName (2.5.4.8)
O       organizationName (2.5.4.10)
OU      organizationalUnitName (2.5.4.11)
C       countryName (2.5.4.6)
STREET  streetAddress (2.5.4.9)
DC      domainComponent (0.9.2342.19200300.100.1.25)
UID     userId (0.9.2342.19200300.100.1.1)

These attribute types are described in [RFC4519] 📚.

Implementations MAY recognize other DN string representations 🌈. But since nothing requires alternative DN string representations to be recognized (or, if they are, how they should be), implementations SHOULD only generate DN strings in accordance with Section 2 of this document 🙈.

4. Examples 🍓

This notation was designed to be convenient for the common forms of name 💅. So let's look at a few examples of distinguished names written this way, starting with a name that has three relative distinguished names (RDNs) 🎀:

UID=jsmith,DC=example,DC=net

Next is a name with three RDNs where the first RDN is multi-valued 👑:

OU=Sales+CN=J.  Smith,DC=example,DC=net

This one shows how to escape special characters inside a common name 🙈:

CN=James \"Jim\" Smith\, III,DC=example,DC=net

Here's how you encode a value that has a carriage return character 🦋:

CN=Before\0dAfter,DC=example,DC=net

In this RDN, the type is unrecognized, and the value is the BER encoding of an OCTET STRING with two octets, 0x48 and 0x69 💀:

1.3.6.1.4.1.1466.0=#04024869

Finally, this example has an RDN whose commonName value is 5 letters long 🥹:

Unicode Character                Code       UTF-8   Escaped
-------------------------------  ------     ------  --------
LATIN CAPITAL LETTER L           U+004C     0x4C    L
LATIN SMALL LETTER U             U+0075     0x75    u
LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
LATIN SMALL LETTER I             U+0069     0x69    i
LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87

This can be encoded in printable ASCII [ASCII] (handy for debugging) like so 🧚:

CN=Lu\C4\8Di\C4\87

5. Security Considerations 🔐

These security considerations are specific to handling distinguished names 💜. LDAP security considerations are covered in [RFC4511] and the other documents that make up the LDAP Technical Specification [RFC4510], so go check those too 🫶.

5.1. Disclosure 🙊

Distinguished Names usually hold descriptive info about whatever they name, and that could be people, organizations, devices, or other real-world objects 😭. This often includes some of the following:

  • the common name of the object (i.e., a person's full name)
  • an email or TCP/IP address
  • its physical location (country, locality, city, street address)
  • organizational attributes (such as department name or affiliation)

Sometimes that info is sensitive, and honestly, that's a big deal ⚠️. In lots of countries, privacy laws ban disclosing certain kinds of descriptive info (like email addresses) 🚫. So server implementers are encouraged to support Directory Information Tree (DIT) structural rules and name forms [RFC4512], since they give admins a way to pick the right naming attributes for entries 🌸. Admins are also encouraged to use mechanisms, access controls, and other admin controls that might be available to limit using sensitive attributes when naming entries 🛡️. And using authentication and data security services in LDAP [RFC4513][RFC4511] should be considered 💅.

5.2. Use of Distinguished Names in Security Applications 🔑

Converting an AttributeValue from its X.501 form to an LDAP string representation isn't always reversible back to the same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules) form 😳. One situation that needs the DER form of a distinguished name is verifying an X.509 certificate 📜.

For example, say a distinguished name has one RDN with one AVA, where the type is commonName and the value uses the TeletexString choice with the letters 'Sam' 🧸. In LDAP, that becomes the string <CN=Sam>. Another distinguished name where the value is still 'Sam' but uses the PrintableString choice would end up with the exact same representation, <CN=Sam> 🤯.

Applications that need to rebuild the DER form of the value SHOULD NOT use the string representation of attribute syntaxes when converting a distinguished name to LDAP format 🚫. Instead, they SHOULD use the hexadecimal form prefixed by the number sign ('#' U+0023), as described in the first paragraph of Section 2.4 🌟.

6. Acknowledgements 🫶

This document updates RFC 2253, which was written by Mark Wahl, Tim Howes, and Steve Kille 💖. RFC 2253 came out of the IETF ASID Working Group 🌈.

This document is a product of the IETF LDAPBIS Working Group 👑.

7. References 📚

7.1. Normative References 💜

  • [REGISTRY] IANA, Object Identifier Descriptors Registry, <http://www.iana.org/assignments/ldap-parameters>.
  • [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
  • [X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
  • [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
  • [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
  • [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
  • [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
  • [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
  • [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
  • [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

7.2. Informative References ✨

Okay bestie, these are the informative refs, which means they're the background reading that helps you understand the spec. Here they are:

  • [ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
  • [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
  • [Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
  • [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
  • [X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
  • [X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (also ISO/IEC 8825-1:1998).
  • [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.

Appendix A. Presentation Issues 🎀

This appendix is provided for informational purposes only, so it's not a normative part of this spec. Nothing in here is required. It's just helpful tips 💖

Okay so the string form of a DN isn't really meant to be shown to humans as-is without translating it first. BUT sometimes you do want to show a non-translated DN string to a user, and that's where this section comes in. It covers presentation issues for non-translated DN strings only. Translated DN strings and transcoding issues are not covered here.

This appendix gives guidance for apps that show DN strings to users. It's not the full story though. It doesn't cover every presentation issue you might run into 🙈

Not every user interface can display the full set of Unicode characters, and some Unicode characters just can't be displayed at all. Sad but true 😭

It is recommended that human interfaces use the optional hex pair escaping mechanism (Section 2.3) to produce a string representation suitable for display to the user. For example, an app can generate a DN string for display that escapes all non-printable characters in the AttributeValue's string representation (as demonstrated in the final example of Section 4). Main character escaping energy 💅

When a DN string shows up in free-form text, you usually need to make it stand out from the text around it. You can do that with whitespace (as shown in Section 4), but heads up: DN strings may end with whitespace, so that doesn't always work. Careful readers of Section 3 will notice that the characters < (U+003C) and > (U+003E) may only appear in the DN string if they're escaped. These characters are meant for free-form text, so they can tell a DN string apart from the words around it. For example, <CN=Sam\ > distinguishes the string representation of the DN made of one RDN with one AVA (the commonName (CN) value 'Sam ') from the surrounding text. You should also tell the user that the wrapping < and > characters are not part of the DN string 🧚

DN strings can get really long, so it's often nice to line-wrap them in presentations. Line wrapping should be done by inserting whitespace after the RDN separator character or, if necessary, after the AVA separator character. You should also tell the user that the inserted whitespace is not part of the DN string and must be removed before use in LDAP. For example, this DN string is long:

      CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
      O=OpenLDAP Foundation,ST=California,C=US

So it's been line-wrapped for readability. That extra whitespace has to come out before the DN string gets used in LDAP. 🫶

Inserting whitespace isn't really advised, though, because the user might not be able to tell which whitespace is part of the DN and which was just added to make it readable. Ngl, that's a lot of confusion 💀

Another option is the LDAP Data Interchange Format (LDIF) [RFC2849]. For example:

      # This entry has a long DN...
      dn: CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
       O=OpenLDAP Foundation,ST=California,C=US
      CN: Kurt D.  Zeilenga
      SN: Zeilenga
      objectClass: person

Appendix B. Changes Made since RFC 2253 🌸

This appendix is also just for info and isn't a normative part of this spec. It's the glow-up log, bestie 🦋

Here are the substantive changes made to RFC 2253:

  • Removed the IESG Note. The IESG Note has been addressed.
  • Replaced all references to ISO 10646-1 with [Unicode].
  • Clarified (in Section 1) that this document does not define a canonical string representation.
  • Clarified that Section 2 describes the RECOMMENDED encoding algorithm and that alternative algorithms are allowed. Some encoding options described in RFC 2253 are now treated as alternative algorithms in this specification.
  • Revised the specification (in Section 2) to allow short names of any registered attribute type to appear in string representations of DNs, instead of being restricted to a "published table". Removed the "as an example" language. Added a statement (in Section 3) allowing recognition of additional names, but requiring recognition of those names in the published table. The table now appears in Section 3.
  • Removed the specification of additional requirements for LDAPv2 implementations which also support LDAPv3 (RFC 2253, Section 4), since LDAPv2 is now Historic.
  • Allowed recognition of alternative string representations.
  • Updated Section 2.4 to allow hex pair escaping of all characters, and clarified escaping for when multiple octet UTF-8 encodings are present. Indicated that the null (U+0000) character is to be escaped. Indicated that the equals sign ('=' U+003D) character may be escaped as '\='.
  • Rewrote Section 3 to use ABNF as defined in RFC 4234.
  • Updated the Section 3 ABNF. Changes include:
    • allowed AttributeType short names of length 1 (e.g., 'L'),
    • used the more restrictive <oid> production in AttributeTypes,
    • did not require escaping of the equals sign ('=' U+003D) characters,
    • did not require escaping of non-leading number sign ('#' U+0023) characters,
    • allowed space (' ' U+0020) to be escaped as '\ ',
    • required hex escaping of null (U+0000) characters, and
    • removed LDAPv2-only constructs.
  • Updated Section 3 to describe how to parse elements of the grammar.
  • Rewrote the examples.
  • Added a reference to documentation containing general LDAP security considerations.
  • Added a discussion of presentation issues (Appendix A).
  • Added this appendix.

On top of that, there were lots of editorial changes. Slay the editing ✨

Editor's Address 💜

Kurt D. Zeilenga OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🦋

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 👑

📦 where this page comes from