RFC 2781

UTF-16, an encoding of ISO 10646

📅 published February 2000, from ietf

RFC 2781: UTF-16, an encoding of ISO 10646 🎀

Part 1 of 3 🧚

  • Network Working Group 💅
  • Authors: P. Hoffman (Internet Mail Consortium) and F. Yergeau (Alis Technologies) 💖
  • Category: Informational ✨
  • Date: February 2000 📅
  • Obsoletes / Updates: The header doesn't list anything this one obsoletes or updates 🙈

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

1. Introduction 🦋

Okay so this document describes the UTF-16 encoding of Unicode/ISO-10646. It also tackles how to serialize UTF-16 as an octet stream so it can go over the Internet, talks about MIME charset naming as described in [CHARSET-REG], and registers three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little-endian), and UTF-16. Iconic stuff 👑

1.1 Background and motivation 🌈

The Unicode Standard [UNICODE] and ISO/IEC 10646 [ISO-10646] together define a coded character set (CCS), which we'll just call Unicode from here on. It covers most of the world's writing systems [WORKSHOP]. ✨

UTF-16 is the star of this spec, and it's one of the standard ways to encode Unicode character data. It's giving efficiency: every character currently defined in plane 0 (the BMP) fits in exactly two octets, and any other character likely to be defined (in the next 16 planes) fits in exactly four octets. 🔥

The Unicode Standard also defines extra character properties and other application details that implementers will be obsessed with. Up until now, changes to Unicode and amendments to ISO/IEC 10646 have tracked each other, so the character repertoires and code point assignments have stayed in sync. The relevant standards committees have committed to keeping that synchronism going, and to not assigning characters outside the 17 planes UTF-16 can reach. Main character energy from both of them 💅

The IETF policy on character sets and languages [CHARPOLICY] says that IETF protocols MUST be able to use the UTF-8 character encoding scheme [UTF-8]. Some products and network standards already specify UTF-16, so it's an important encoding for the Internet 🫶 This document is not an update to [CHARPOLICY]. It's only a description of the UTF-16 encoding, no drama 🍓

1.2 Terminology 💜

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 RFC 2119 [MUSTSHOULD]. 📖

Throughout this document, character values are written in hexadecimal. For example, 0x013C is the character whose value is the character assigned the integer value 316 (decimal) in the CCS. 🔢

2. UTF-16 definition 💅

UTF-16 is described in the Unicode Standard, version 3.0 [UNICODE]. The definitive reference is Annex Q of ISO/IEC 10646-1 [ISO-10646]. This section gives you the simple version of that definition. 💖

In ISO 10646, every character gets a number, which Unicode calls the Unicode scalar value. That number is the same as the UCS-4 value of the character. This document calls it the "character value" to keep things short. In UTF-16, characters are represented using either one or two unsigned 16-bit integers, depending on the character value. Section 3 covers how those integers get serialized into a byte stream. 🌸

Here are the rules for how characters get encoded in UTF-16:

  • Characters with values less than 0x10000 are represented as a single 16-bit integer whose value equals the character number. 🦋
  • Characters with values between 0x10000 and 0x10FFFF are represented by a 16-bit integer with a value between 0xD800 and 0xDBFF (the so-called high-half zone or high surrogate area), followed by a 16-bit integer with a value between 0xDC00 and 0xDFFF (the so-called low-half zone or low surrogate area). 🌈
  • Characters with values greater than 0x10FFFF cannot be encoded in UTF-16. 🚫
Note: Values between 0xD800 and 0xDFFF are specifically reserved for use with UTF-16, and don't have any characters assigned to them. 🙈

2.1 Encoding UTF-16 ✨

Here's how you encode a single character from an ISO 10646 character value into UTF-16. Let U be the character number, which is no greater than 0x10FFFF.

  1. If U < 0x10000, encode U as a 16-bit unsigned integer and terminate.
  2. Let U' = U - 0x10000. Because U is less than or equal to 0x10FFFF, U' must be less than or equal to 0xFFFFF. That means U' can be represented in 20 bits. 🔥
  3. Initialize two 16-bit unsigned integers, W1 and W2, to 0xD800 and 0xDC00, respectively. Each of these integers has 10 bits free to encode the character value, for a total of 20 bits. 💜
  4. Assign the 10 high-order bits of the 20-bit U' to the 10 low-order bits of W1, and the 10 low-order bits of U' to the 10 low-order bits of W2. Terminate. 🎀

Graphically, steps 2 through 4 look like this:

U' = yyyyyyyyyyxxxxxxxxxx
W1 = 110110yyyyyyyyyy
W2 = 110111xxxxxxxxxx

2.2 Decoding UTF-16 🧚

Here's how you go the other way, decoding a single character from UTF-16 into an ISO 10646 character value. Let W1 be the next 16-bit integer in the sequence representing the text. Let W2 be the (eventual) next integer after W1. 🫶

  1. If W1 < 0xD800 or W1 > 0xDFFF, the character value U is the value of W1. Terminate. ✨
  2. Determine whether W1 is between 0xD800 and 0xDBFF. If it isn't, the sequence is in error and no valid character can be obtained using W1. Terminate. 💀
  3. If there is no W2 (that is, the sequence ends with W1), or if W2 is not between 0xDC00 and 0xDFFF, the sequence is in error. Terminate. 😭
  4. Construct a 20-bit unsigned integer U', using the 10 low-order bits of W1 as its 10 high-order bits and the 10 low-order bits of W2 as its 10 low-order bits. 🌸
  5. Add 0x10000 to U' to obtain the character value U. Terminate. 🦋

Steps 2 and 3 indicate errors. This document doesn't specify error recovery. When terminating with an error in steps 2 and 3, it may be wise to set U to the value of W1, so the caller can diagnose the error and not lose information. Also, a string decoding algorithm (as opposed to the single-character decoding described above) need not terminate when it detects an error, as long as proper error reporting and/or recovery is provided. 🙈

3. Labelling UTF-16 text 🧚

Appendix A of this specification contains registrations for three MIME charsets: "UTF-16BE", "UTF-16LE", and "UTF-16". MIME charsets combine a CCS (a coded character set) with a CES (a character encoding scheme). Here the CCS is Unicode/ISO 10646, and the CES is the same in all three cases. The only differences are the serialization order of the octets in each character, and how you externally determine which serialization is being used. 💖

This section describes which of the three labels to apply to a stream of text. Section 4 describes how to interpret those labels on a stream of text. 🌈

3.1 Definition of big-endian and little-endian 🎀

Historically, computer hardware has processed two-octet entities, such as 16-bit integers, in one of two ways. So-called "big-endian" hardware handles two-octet entities with the higher-order octet first, meaning it sits at the lower address in memory. When it gets written out to disk or to a network interface (serializing), the high-order octet appears first in the data stream. "Little-endian" hardware does the opposite and handles the lower-order octet first. Both kinds of hardware are common today. 💅

For example, the unsigned 16-bit integer that represents the decimal number 258 is 0x0102. Its big-endian serialization is the octet 0x01 followed by the octet 0x02. Its little-endian serialization is the octet 0x02 followed by the octet 0x01. The following C code fragment shows one way to write 16-bit quantities to a file in big-endian order, no matter the hardware's native byte order. 🧠

void write_be(unsigned short u, FILE f)  /* assume short is 16 bits */
{
  putc(u >> 8,   f);                     /* output high-order byte */
  putc(u & 0xFF, f);                     /* then low-order */
}

The term "network byte order" has shown up in many RFCs to mean big-endian serialization, although the term hasn't been formally defined in a standards-track document yet. ISO 10646 prefers big-endian serialization (section 6.3 of [ISO-10646]), but little-endian order is also sometimes used on the Internet. 🌸

3.2 Byte order mark (BOM) 💜

The Unicode Standard and ISO 10646 define the character "ZERO WIDTH NON-BREAKING SPACE" (0xFEFF), which is also informally known as "BYTE ORDER MARK" (abbreviated "BOM"). That second name hints at another possible use for the character, besides its normal job as a genuine "ZERO WIDTH NON-BREAKING SPACE" inside text. Unicode section 2.4 and ISO 10646 Annex F (informative) suggest prepending a 0xFEFF character to a stream of Unicode characters as a "signature". A receiver of such a serialized stream can then use that first character as a hint that the stream holds Unicode characters, and as a way to recognize the serialization order. 🦋

In serialized UTF-16 with that signature, the order is big-endian if the first two octets are 0xFE followed by 0xFF. If they're 0xFF followed by 0xFE, the order is little-endian. Note that 0xFFFE is not a Unicode character, precisely so that 0xFEFF stays useful as a byte-order mark. 🌈

It's important to understand that the character 0xFEFF appearing at any position other than the beginning of a stream MUST be interpreted with the semantics of the zero-width non-breaking space, and MUST NOT be interpreted as a byte-order mark. The reverse isn't always true: the character 0xFEFF in the first position of a stream MAY be interpreted as a zero-width non-breaking space, and it isn't always a byte-order mark. For example, if a process splits a UTF-16 string into many parts, one part might begin with 0xFEFF because there was a zero-width non-breaking space at the start of that substring. 🙈

The Unicode Standard also suggests that an initial 0xFEFF character may be stripped before processing the text. The reasoning is that a character in the initial position may be an artifact of the encoding (an encoding signature), not a genuine intended "ZERO WIDTH NON-BREAKING SPACE". Stripping might affect an external process at a different layer (such as a digital signature, or a count of the characters) that relies on all characters being present in the stream. 💅

In particular, in UTF-16 plain text it's likely, but not certain, that an initial 0xFEFF is a signature. When concatenating two strings, you need to strip out those signatures. Otherwise the resulting string may contain an unintended "ZERO WIDTH NON-BREAKING SPACE" at the connection point. Some specifications also mandate an initial 0xFEFF character in objects labelled as UTF-16, and specify that this signature is not part of the object. 🫶

Part 2 picks up right here, bestie 💖🔥

3.3 Choosing a label for UTF-16 text 🎀

okay so any labelling app that uses UTF-16 character encoding, explicitly labels the text, AND knows the serialization order of the characters in the text 🤓 SHOULD label it as either "UTF-16BE" or "UTF-16LE", whichever matches the endianness of the text. This is giving clarity 💖 because apps that process the text but can't look inside it can know the serialization for sure ✨

Text in the "UTF-16BE" charset MUST be serialized with the octets that make up a single 16-bit UTF-16 value in big-endian order. Systems labelling UTF-16BE text MUST NOT prepend a BOM to the text. no BOM, bestie 🙅‍♀️

Text in the "UTF-16LE" charset MUST be serialized with the octets that make up a single 16-bit UTF-16 value in little-endian order. Systems labelling UTF-16LE text MUST NOT prepend a BOM to the text. same energy, just flipped 🔁

Any labelling app that uses UTF-16 character encoding, puts an explicit charset label on the text, and does not know the serialization order of the characters in the text MUST label it as "UTF-16", and SHOULD make sure the text starts with 0xFEFF. this is the "I don't know the order, so I'll flag it" move 🚩

An exception to the "SHOULD" rule of using "UTF-16BE" or "UTF-16LE" would occur with document formats that mandate a BOM in UTF-16 text, thereby requiring the use of the "UTF-16" tag only. so if the format itself insists on a BOM, the "UTF-16" tag is the only one that makes sense 🫶

4. Interpreting text labels ✨

okay now the fun part: reading the labels 👀 When a program sees text labelled as "UTF-16BE", "UTF-16LE", or "UTF-16", it can make some assumptions, based on the labelling rules in the previous section. those assumptions let the program actually process the text 💅

4.1 Interpreting text labelled as UTF-16BE

Text labelled "UTF-16BE" can always be interpreted as being big-endian. The detection of an initial BOM does not affect deserialization of text labelled as UTF-16BE. Finding 0xFF followed by 0xFE is an error since there is no Unicode character 0xFFFE. 🚨 that 0xFFFE thing is not a real character, so spotting that pattern means something went wrong

4.2 Interpreting text labelled as UTF-16LE

Text labelled "UTF-16LE" can always be interpreted as being little-endian. The detection of an initial BOM does not affect deserialization of text labelled as UTF-16LE. Finding 0xFE followed by 0xFF is an error since there is no Unicode character 0xFFFE, which would be the interpretation of those octets under little-endian order. the byte-swap sneaky twist 🌀 same error, different disguise

4.3 Interpreting text labelled as UTF-16

Text labelled with the "UTF-16" charset might be serialized in either big-endian or little-endian order. If the first two octets of the text is 0xFE followed by 0xFF, then the text can be interpreted as being big-endian. If the first two octets of the text is 0xFF followed by 0xFE, then the text can be interpreted as being little-endian. If the first two octets of the text is not 0xFE followed by 0xFF, and is not 0xFF followed by 0xFE, then the text SHOULD be interpreted as being big-endian. 🎯 when in doubt, go big-endian

All applications that process text with the "UTF-16" charset label MUST be able to read at least the first two octets of the text and be able to process those octets in order to determine the serialization order of the text. Applications that process text with the "UTF-16" charset label MUST NOT assume the serialization without first checking the first two octets to see if they are a big-endian BOM, a little-endian BOM, or not a BOM. All applications that process text with the "UTF-16" charset label MUST be able to interpret both big-endian and little-endian text. checking those first two bytes is non-negotiable, periodt 💀

5. Examples 🍓

For the sake of example, let's suppose that there is a hieroglyphic character representing the Egyptian god Ra with character value 0x12345. this character does not exist at present in Unicode, so we're just pretending 🧚

The examples here all evaluate to the phrase:

*=Ra

where the "*" represents the Ra hieroglyph (0x12345).

Text labelled with UTF-16BE, without a BOM:

D8 08 DF 45 00 3D 00 52 00 61

Text labelled with UTF-16LE, without a BOM:

08 D8 45 DF 3D 00 52 00 61 00

Big-endian text labelled with UTF-16, with a BOM:

FE FF D8 08 DF 45 00 3D 00 52 00 61

Little-endian text labelled with UTF-16, with a BOM:

FF FE 08 D8 45 DF 3D 00 52 00 61 00

look at the bytes flip 🔄 same phrase, four different outfits 👗✨

6. Versions of the standards 📚

ISO/IEC 10646 is updated from time to time by published amendments. similarly, different versions of the Unicode standard exist: 1.0, 1.1, 2.0, 2.1, and 3.0 as of this writing. Each new version replaces the previous one, but implementations, and more significantly data, are not updated instantly. the standards keep evolving, but your old data is still hanging around 🕰️

In general, the changes amount to adding new characters, which does not pose particular problems with old data. Amendment 5 to ISO/IEC 10646, however, has moved and expanded the Korean Hangul block, thereby making any previous data containing Hangul characters invalid under the new version. Unicode 2.0 has the same difference from Unicode 1.1. The official justification for allowing such an incompatible change was that no significant implementations and data containing Hangul existed, a statement that is likely to be true but remains unprovable. The incident has been dubbed the "Korean mess", and the relevant committees have pledged to never, ever again make such an incompatible change. 😭

the "Korean mess" is the reason everyone is extra careful about breaking changes now. never, ever again 🙏

New versions, and in particular any incompatible changes, have consequences regarding MIME character encoding labels, to be discussed in Appendix A. 🎀

7. IANA Considerations 🌸

IANA is to register the character sets found in Appendixes A.1, A.2, and A.3 according to RFC 2278, using registration templates found in those appendixes. so IANA is the one doing the official paperwork 📝

8. Security Considerations 🔐

this section is SERIOUS, so pay attention 👀 but it's also kind of dramatic and I love it 💅

UTF-16 is based on the ISO 10646 character set, which is frequently being added to, as described in Section 6 and Appendix A of this document. Processors must be able to handle characters that are not defined at the time that the processor was created in such a way as to not allow an attacker to harm a recipient by including unknown characters. new characters keep showing up, so processors have to be ready for ones they've never seen 🛡️

Processors that handle any type of text, including text encoded as UTF-16, must be vigilant in checking for control characters that might reprogram a display terminal or keyboard. Similarly, processors that interpret text entities (such as looking for embedded programming code), must be careful not to execute the code without first alerting the recipient. 🚨 control characters can literally reprogram your terminal, so keep your eyes open

Text in UTF-16 may contain special characters, such as the OBJECT REPLACEMENT CHARACTER (0xFFFC), that might cause external processing, depending on the interpretation of the processing program and the availability of an external data stream that would be executed. This external processing may have side-effects that allow the sender of a message to attack the receiving system. 😱 a single special character could trigger outside processing, and that can be a whole attack route

Implementors of UTF-16 need to consider the security aspects of how they handle illegal UTF-16 sequences (that is, sequences involving surrogate pairs that have illegal values or unpaired surrogates). It is conceivable that in some circumstances an attacker would be able to exploit an incautious UTF-16 parser by sending it an octet sequence that is not permitted by the UTF-16 syntax, causing it to behave in some anomalous fashion. 🕵️‍♀️ if your parser gets careless with illegal sequences, an attacker can use that to make it act weird

9. References 📖

[CHARPOLICY]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, January 1998.

[CHARSET-REG] Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", BCP 19, RFC 2278, January 1998.

[HTTP-1.1]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[ISO-10646]   ISO/IEC 10646-1:1993. International Standard --
              Information technology -- Universal Multiple-Octet
              Coded Character Set (UCS) -- Part 1: Architecture and
              Basic Multilingual Plane. 22 amendments and two
              technical corrigenda have been published up to now.
              UTF-16 is described in Annex Q, published as Amendment
              1. Many other amendments are currently at various
              stages of standardization. A second edition is in
              preparation, probably to be published in 2000; in this
              new edition, UTF-16 will probably be described in Annex
              C.

[MUSTSHOULD]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[UNICODE]     The Unicode Consortium, "The Unicode Standard --
              Version 3.0", ISBN 0-201-61633-5. Described at

              <http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.

[UTF-8]       Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

[WORKSHOP]    Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
              Atkinson, R., Crispin., M. and P. Svanberg, "Report of
              the IAB Character Set Workshop", RFC 2130, April 1997.

that's the whole reading list, bestie 📚💜

10. Acknowledgments 🫶

Deborah Goldsmith wrote a great deal of the initial wording for this specification. Martin Duerst proposed numerous significant changes. Other significant contributors include:

Mati Allouche
Walt Daniels
Mark Davis
Ned Freed
Asmus Freytag
Lloyd Honomichl
Dan Kegel
Murata Makoto
Larry Masinter
Markus Scherer
Keld Simonsen
Ken Whistler

Some of the text in this specification was copied from [UTF-8], and that document was worked on by many people. Please see the acknowledgments section in that document for more people who may have contributed indirectly to this document. so many people made this possible, and I'm lowkey obsessed with that 🌈✨

A. Charset registrations ✨

okay so this memo is basically the paperwork for registering three MIME charsets [CHARSET-REG] 📝. The proposed ones are "UTF-16BE", "UTF-16LE", and "UTF-16" 💖. These labels are for objects holding text made of characters from the ISO/IEC 10646 repertoire, including all amendments at least up to amendment 5 (Korean block) 🇰🇷, encoded into a sequence of octets using the encoding and serialization schemes outlined above 🦋.

bestie, this part is important tea 🫖: "UTF-16BE", "UTF-16LE", and "UTF-16" are NOT suitable for use in media types under the "text" top-level type 🙅‍♀️, because they don't encode line endings the way MIME "text" media types need 😭. HTTP is the exception 🌈. It uses a MIME-like mechanism but is exempt from the restrictions on the text top-level type (see section 19.4.2 of HTTP 1.1 [HTTP-1.1]) ✨.

It's also noteworthy that these labels don't include a version identification and just refer generically to ISO/IEC 10646 🧚. This is intentional, and here's the reasoning 💅:

A MIME charset is designed to give just the information needed to interpret a sequence of bytes received on the wire into a sequence of characters, nothing more (see RFC 2045, section 2.2, in [MIME]) 🎀. As long as a character set standard doesn't change incompatibly, version numbers serve no purpose 🙈. One gains nothing by learning from the tag that newly assigned characters may be received that one doesn't know about. The tag itself doesn't teach anything about the new characters, which are going to be received anyway 💀.

So as long as the standards evolve compatibly, the apparent advantage of having labels that identify the versions is only that, apparent 🫠. But version-dependent labels have a downside 😬. When an older application receives data with a newer, unknown label, it may fail to recognize the label and be completely unable to deal with the data 😭. A generic, known label would have triggered mostly correct processing of the data instead, which may well not contain any new characters 🌸.

The "Korean mess" (ISO/IEC 10646 amendment 5) is an incompatible change, which in principle contradicts the appropriateness of a version-independent MIME charset as described above 🙃. But the compatibility problem can only appear with data containing Korean Hangul characters encoded according to Unicode 1.1 (or equivalently ISO/IEC 10646 before amendment 5). Arguably there's no such data to worry about, and that's the very reason the incompatible change was deemed acceptable 👑.

So in practice, a version-independent label is warranted, provided the label is understood to refer to all versions after Amendment 5, and provided no incompatible change actually occurs 🦋. Should incompatible changes occur in a later version of ISO/IEC 10646, the MIME charsets defined here will stay aligned with the previous version until and unless the IETF specifically decides otherwise 🫶.

A.1 Registration for UTF-16BE 💌

Here's the registration template for UTF-16BE, copied exactly 📋:

To: ietf-charsets@iana.org
Subject: Registration of new charset

Charset name(s): UTF-16BE

Published specification(s): This specification

Suitable for use in MIME content types under the
"text" top-level type: No

Person & email address to contact for further information:
Paul Hoffman <phoffman@imc.org>
Francois Yergeau <fyergeau@alis.com>

A.2 Registration for UTF-16LE 💌

Same vibe for UTF-16LE 🌈:

To: ietf-charsets@iana.org
Subject: Registration of new charset

Charset name(s): UTF-16LE

Published specification(s): This specification

Suitable for use in MIME content types under the
"text" top-level type: No

Person & email address to contact for further information:
Paul Hoffman <phoffman@imc.org>
Francois Yergeau <fyergeau@alis.com>

A.3 Registration for UTF-16 💌

And the last one, for plain UTF-16 ✨:

To: ietf-charsets@iana.org
Subject: Registration of new charset

Charset name(s): UTF-16

Published specification(s): This specification
Suitable for use in MIME content types under the
"text" top-level type: No

Person & email address to contact for further information:
Paul Hoffman <phoffman@imc.org>
Francois Yergeau <fyergeau@alis.com>

Authors' Addresses 🧳

The authors, Paul Hoffman and Francois Yergeau, can be reached at the following addresses 📮:

Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA  95060 USA

EMail: phoffman@imc.org


Francois Yergeau
Alis Technologies
100, boul. Alexis-Nihon, Suite 600
Montreal  QC  H4M 2P2 Canada

EMail: fyergeau@alis.com

Here's the legal stuff, and it's all here, complete 🎀.

The copyright line reads: Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others 🩷. Derivative works that comment on or otherwise explain it, or assist in its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind 🌷. This is fine as long as the above copyright notice and this paragraph are included on all such copies and derivative works 💜. However, this document itself may not be modified in any way 🚫. That includes removing the copyright notice or references to the Internet Society or other Internet organizations. The one exception is when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed. Translating it into languages other than English is also allowed 🌍.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 🙏. That includes 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 😭.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 🌟.

📦 where this page comes from