RFC 3533

The Ogg Encapsulation Format Version 0

📅 published May 2003, from ietf

RFC 3533: The Ogg Encapsulation Format Version 0 🎀

okay so this is the title block bit, and it's giving official paperwork 📄💅 RFC 3533 is titled The Ogg Encapsulation Format Version 0. It was written by S. Pfeiffer from CSIRO, it's dated May 2003, and its category is Informational 🌸. It doesn't say it obsoletes or updates anything, so it's a standalone doc, no drama 🫶

Status of this Memo ✨

ok so this part is the legal-ish disclaimer 🙈 It's just info for the Internet community. It is not a standard of any kind, and distribution is totally unlimited 💖

Copyright (C) The Internet Society (2003). All Rights Reserved.

so the Internet Society owns the copyright, obviously, and all rights are reserved 🔒

Abstract 🦋

so the big idea is that this doc describes Ogg bitstream format version 0 🎧. It's a general, freely available encapsulation format for media streams, which means it's like a container that can hold any kind and number of video and audio encoding formats, plus other data streams, all inside a single bitstream 🧚 literal main character energy for containers 👑

Terminology 🌈

the key words in this doc are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're meant to be read the way BCP 14, RFC 2119 [2] describes 🍓

Table of Contents 📚

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2
2. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   2
3. Requirements for a generic encapsulation format  . . . . . . .   3
4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . .   3
5. The encapsulation process  . . . . . . . . . . . . . . . . . .   6
6. The Ogg page format  . . . . . . . . . . . . . . . . . . . . .   9
7. Security Considerations  . . . . . . . . . . . . . . . . . . .  11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  12
A. Glossary of terms and abbreviations  . . . . . . . . . . . . .  13
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . .  14
   Full Copyright Statement . . . . . . . . . . . . . . . . . . .  15

1. Introduction ✨

okay so the Ogg bitstream format came out of a bigger project 💖 The goal was a set of codecs (the encoder/decoder bits for multimedia) that are freely available and freely re-implementable, in software and hardware, for the computing community at large, Internet folks included 🌍. The Ogg developers, represented by Xiph.Org, want it to be usable without intellectual property concerns 🕊️ no legal drama, bestie

This doc explains the Ogg bitstream format and how to use it to encapsulate one or several media bitstreams made by one or several encoders 🎀. The Ogg transport bitstream is built to give you framing, error protection, and seeking structure for higher-level codec streams. Those streams are raw, unencapsulated data packets, like the Vorbis audio codec or the upcoming Tarkin and Theora video codecs 🎶. It can interleave different binary media and other time-continuous data streams, which the encoder has already split into a sequence of data packets 🧚

And the best part: Ogg gives enough info to split the data back into those encoder-made data packets at the original packet boundaries, without having to decode anything to find the boundaries 🤯 that's lowkey iconic

Please note that the MIME type application/ogg has been registered with the IANA [1]. So it's officially a thing 💅

2. Definitions 🦋

ok so before we go deeper, there are some terms we need to be on the same page about 📖 Some of the big ones get defined here, and the full glossary is in the Appendix 🌸

The result of an Ogg encapsulation is called the "Physical (Ogg) Bitstream" 💜 It wraps up one or several encoder-created bitstreams, which are called "Logical Bitstreams" 🎀 Each logical bitstream has a structure: it gets split into a sequence of so-called "Packets" 🍓 These packets are made by the encoder of that logical bitstream, so they only mean something to that encoder (like, an uncompressed stream might use video frames as its packets) 🌈 They don't carry any boundary info. Strung together, they look like a stream of random bytes with no landmarks at all 😭

Please note that the term "packet" is not used in this document to signify entities for transport over a network. So don't mix it up with network packets, bestie 🙈

3. Requirements for a generic encapsulation format 🌟

okay so the whole design idea behind Ogg was a generic, linear media transport format 🎬 It should work for file-based storage and stream-based transmission of one or several interleaved media streams, no matter what encoding format the media uses 💖 A format like that needs to give you all of this:

  • framing for logical bitstreams 🖼️
  • interleaving of different logical bitstreams 🌀
  • detection of corruption 🔍
  • recapture after a parsing error 🫶
  • position landmarks for direct random access of arbitrary positions in the bitstream 📍
  • streaming capability (i.e., no seeking is needed to build a 100% complete bitstream) 🌊
  • small overhead (i.e., use no more than approximately 1-2% of bitstream bandwidth for packet boundary marking, high-level framing, sync and seeking) 🥹 just 1-2%, that's so efficient
  • simplicity to enable fast parsing ⚡
  • simple concatenation mechanism of several physical bitstreams 🧩

And honestly, Ogg checks all of these boxes 👑 It handles framing and interleaving of logical bitstreams, seeking landmarks, detection of corruption, and stream resynchronisation after a parsing error, all with no more than approximately 1-2% overhead 💅 It's a generic framework for encapsulating time-continuous bitstreams, and it doesn't know anything about the specifics of the codec data it wraps, so it's independent of any media codec 🧚✨

4. The Ogg bitstream format 🧚

okay so a physical Ogg bitstream is basically a group chat of multiple logical bitstreams that take turns, and the turns are called "Pages" 💬 Whole pages get taken in order from each logical bitstream and multiplexed at the page level. Every logical bitstream has its own unique serial number, and that number shows up in the header of every page of the physical bitstream 🆔 The serial number is created randomly and has zero connection to the content or the encoder, which is very mysterious and very iconic. All the pages get concurrently interleaved, but they don't have to follow a regular order. The only thing they have to do is stay consecutive within their own logical bitstream 🦋 To undo all this, demultiplexing takes the pages in order from the physical bitstream and redirects each one to the right logical decoding entity. Ogg sorting its own chaos, bestie 💅

Each Ogg page only holds one type of data, since it belongs to one logical bitstream only 🌸 Pages are variable size and have a page header with encapsulation and error recovery information. Each logical bitstream starts with a special start page (bos, short for beginning of stream) and ends with a special page (eos, short for end of stream) 🎀

The bos page holds info that uniquely identifies the codec type, and it MAY also hold info to set up the decoding process ✨ The bos page SHOULD also contain info about the encoded media. For audio, for example, it should contain the sample rate and number of channels 🎧 By convention, the first bytes of the bos page are magic data that uniquely identifies the required codec 🔮 Anyone fielding a new codec is responsible for making sure it can be reliably told apart from every other codec in use, so no codec gets lost in the crowd 🫶 There is no fixed way to detect where the codec-identifying marker ends, which is lowkey a vibe check. The format of the bos page depends on the codec, so it MUST be given in the encapsulation specification of that logical bitstream type 📜 Ogg also allows, but doesn't require, secondary header packets after the bos page for logical bitstreams. These must also come before any data packets in any logical bitstream 🧁 Those subsequent header packets are framed into an integral number of pages, and those pages will not contain any data packets. So the physical bitstream starts with the bos pages of all logical bitstreams (one initial header packet per page), then the subsidiary header packets of all streams, then the pages holding data packets. Order is everything, periodt 👑

The encapsulation spec for one or more logical bitstreams is called a "media mapping" 🗺️ One example is "Ogg Vorbis", which uses the Ogg framework to wrap Vorbis-encoded audio for stream-based storage (like files) and transport (like TCP streams or pipes) 🎶 Ogg Vorbis puts the name and revision of the Vorbis codec, the audio rate, and the audio quality on its bos page 💿 It also uses two additional header pages per logical bitstream. The Ogg Vorbis bos page starts with the byte 0x01, followed by "vorbis", for a total of 7 bytes of identifier 🪪

Ogg knows about two kinds of multiplexing: concurrent multiplexing (called "Grouping") and sequential multiplexing (called "Chaining") 🌈 Grouping defines how to interleave several logical bitstreams page-wise in the same physical bitstream. It's needed for things like interleaving a video stream with several synchronised audio tracks that use different codecs in different logical bitstreams 🎬 Chaining is the simpler one: it concatenates physical Ogg bitstreams, which is often needed for streaming applications 🔗

For grouping, all the bos pages of all logical bitstreams MUST appear together at the beginning of the Ogg bitstream 🥂 The media mapping specifies the order of those initial pages. For instance, a grouping of a particular Ogg video and Ogg audio bitstream might say the physical bitstream MUST begin with the bos page of the logical video bitstream, followed by the bos page of the audio bitstream. Unlike bos pages, eos pages for the logical bitstreams don't all have to show up contiguously 🙃 An eos page can be a 'nil' page, which means it has no content and is just a page header with position information and the eos flag set in that header 🫧 Each grouped logical bitstream MUST have a unique serial number within the scope of the physical bitstream 🔐

For chaining, complete logical bitstreams get concatenated 🚂 The bitstreams don't overlap, so the eos page of a given logical bitstream is immediately followed by the bos page of the next one 🏃‍♀️ Each chained logical bitstream MUST have a unique serial number within the scope of the physical bitstream too 💜

It's also possible to chain groups of concurrently multiplexed bitstreams, one after another 🧩 When unchained, the groups MUST stand on their own as a valid concurrently multiplexed bitstream 🫶 The diagram below is a schematic example of a physical bitstream that follows all the rules of both grouped and chained multiplexed bitstreams 🍓

           physical bitstream with pages of
      different logical bitstreams grouped and chained
  -------------------------------------------------------------
  |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#|
  -------------------------------------------------------------
   bos bos bos             eos           eos eos bos       eos

In this example there are two chained physical bitstreams. The first one is a grouped stream of three logical bitstreams, A, B, and C 🧃 The second physical bitstream is chained after the end of the grouped bitstream, which ends after the last eos page of all its grouped logical bitstreams. Grouped bitstreams begin together, which means all of the bos pages MUST appear before any data pages 🚦 You can also see that pages from concurrently multiplexed bitstreams don't need to follow a regular order, and that a grouped bitstream can end long before the other bitstreams in its group end 🌙

Ogg doesn't know any specifics about the codec data. It only knows that each logical bitstream belongs to a different codec, that the data from the codec comes in order, and that it has position markers (called "Granule positions") 🧠 Ogg has no concept of 'time' at all. It only knows about sequentially increasing, unitless position markers 📏 An application can only get temporal info through higher layers that have access to the codec APIs, so they can assign and convert granule positions or time ⏰

A specific media mapping using Ogg may add further constraints on how it uses the Ogg bitstream format 🎀 For example, a media mapping may require that all the eos pages for all grouped bitstreams appear in direct sequence. "Ogg Vorbis" is one example of a media mapping. Another is the upcoming "Ogg Theora" specification, which encapsulates Theora-encoded video data and usually comes multiplexed with a Vorbis stream so you get an Ogg with synchronised audio and video 📺 Since Ogg doesn't specify temporal relationships between the encapsulated concurrently multiplexed bitstreams, the temporal synchronisation between the audio and video stream gets specified in that media mapping instead 🎞️ To enable streaming, pages from the various logical bitstreams will typically be interleaved in chronological order 🌊

5. The encapsulation process 💅

The multiplexing of different logical bitstreams happens at the level of pages, like we just covered ✨ The bitstreams that encoders hand over to Ogg come as so-called "Packets", and their boundaries depend on the encoding format 📦 Now we get into how packets get encapsulated into pages, which is the fun part, trust 🫶

From Ogg's perspective, packets can be any arbitrary size 📐 A specific media mapping defines how to group or break up packets from a specific media encoder. Ogg pages have a maximum size of about 64 kBytes, so sometimes a packet has to be spread across several pages 🧳 To make that easier, Ogg divides each packet into 255 byte long chunks plus a final shorter chunk. These chunks are called "Ogg Segments" 🍰 They're only a logical construct and don't have a header of their own, so they're kinda ghosty 👻

A group of contiguous segments gets wrapped into a variable length page, which comes after a header 🎁 A segment table in the page header tells you the "Lacing values" (sizes) of the segments included in the page 📋 A flag in the page header tells you whether a page contains a packet that was continued from a previous page 🔁 Here's the key bit: a lacing value of 255 means a second lacing value follows in the packet, and a value of less than 255 marks the end of the packet after that many additional bytes 🧮 A packet of 255 bytes (or a multiple of 255 bytes) is terminated by a lacing value of 0 🏁 Also, a 'nil' (zero length) packet is not an error. It's just a lacing value of zero in the header, and honestly that's giving minimalism 🫧

The encoding is optimized for speed and for the expected case where most packets are between 50 and 200 bytes large 🏎️ This is a design justification rather than a recommendation, so don't take it as a rule 🙈 The encoding avoids imposing a maximum packet size, and it also avoids imposing minimum overhead on small packets. Compare that to simply using two bytes at the head of every packet with a max packet size of 32 kBytes. That would always penalize small packets (under 255 bytes, which is the typical case) with twice the segmentation overhead 😭 With the lacing values as suggested, small packets see the minimum possible byte-aligned overhead (1 byte), and large packets (over 512 bytes) see a fairly constant ~0.5% overhead on encoding space 💖

The diagram below is a schematic example of a media mapping using Ogg and grouped logical bitstreams 🌸

       logical bitstream with packet boundaries
 -----------------------------------------------------------------
 > |       packet_1             | packet_2         | packet_3 |  <
 -----------------------------------------------------------------

                   |segmentation (logically only)
                   v

    packet_1 (5 segments)          packet_2 (4 segs)    p_3 (2 segs)
   ------------------------------ -------------------- ------------
..  |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | ..
   ------------------------------ -------------------- ------------

                   | page encapsulation
                   v

 page_1 (packet_1 data)   page_2 (pket_1 data)   page_3 (packet_2 data)
------------------------  ----------------  ------------------------
|H|------------------- |  |H|----------- |  |H|------------------- |
|D||seg_1|seg_2|seg_3| |  |D|seg_4|s_5 | |  |D||seg_1|seg_2|seg_3| | ...
|R|------------------- |  |R|----------- |  |R|------------------- |

I'll pick up with the tail of section 5, then cover the page format, security, references and appendices.

The example wraps up section 5 bestie! 🦋 Here's the snapshot: we take one logical bitstream and look at how the codec split it into packets. Ogg then chops each packet into segments. 🔪 In this example the packets are chonky, so packet_1 gets split into 5 segments: 4 are full 255-byte segments and the last one is smaller. 💅 Packet_2 gets 4 segments (3 at 255 bytes and a teeny final one), and packet_3 gets just two. Then the pages get made, and they're tiny in this example. 🌸 Page_1 holds the first three segments of packet_1, page_2 holds the remaining 2 segments from packet_1, and page_3 holds the first three pages of packet_2. Finally, this logical bitstream gets multiplexed into one physical Ogg bitstream alongside pages from other logical bitstreams. It's giving organised chaos and it's iconic 👑

6. The Ogg page format ✨

okay so a physical Ogg bitstream is just a sequence of pages stuck together one after another 🧩 Pages are variable size, usually 4-8 kB, and the max is 65307 bytes. 📏 The page header holds everything you need to pull the logical bitstreams apart again, plus basic error recovery and landmarks for seeking. 🧭 Each page is its own self-contained entity, so a decoder can recognise, verify, and handle one page at a time without needing the whole bitstream. main character energy, no cap 🎀

The Ogg page header looks like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capture_pattern: Magic number for page start "OggS"           | 0-3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version       | header_type   | granule_position              | 4-7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 8-11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | bitstream_serial_number       | 12-15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | page_sequence_number          | 16-19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | CRC_checksum                  | 20-23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |page_segments  | segment_table | 24-27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...                                                           | 28-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The LSb (least significant bit) comes first in the Bytes. 🔢 Fields with more than one byte length are encoded LSB (least significant byte) first. 💖

The fields in the page header mean the following:

  1. capture_pattern: a 4 Byte field that signifies the beginning of a page. It contains the magic numbers:
0x4f 'O'
0x67 'g'
0x67 'g'
0x53 'S'

It helps a decoder find the page boundaries and regain synchronisation after parsing a corrupted stream. 🔍 Once the capture pattern is found, the decoder verifies page sync and integrity by computing and comparing the checksum. ✅

  1. stream_structure_version: 1 Byte signifying the version number of the Ogg file format used in this stream (this document specifies version 0). 🌈
  2. header_type_flag: the bits in this 1 Byte field identify the specific type of this page. 🍓
    • bit 0x01
      • set: page contains data of a packet continued from the previous page
      • unset: page contains a fresh packet
    • bit 0x02
      • set: this is the first page of a logical bitstream (bos)
      • unset: this page is not a first page
    • bit 0x04
      • set: this is the last page of a logical bitstream (eos)
      • unset: this page is not a last page
  3. granule_position: an 8 Byte field containing position information. For example, for an audio stream, it MAY contain the total number of PCM samples encoded after including all frames finished on this page. For a video stream it MAY contain the total number of video frames encoded after this page. This is a hint for the decoder and gives it some timing and position information. 🧚 Its meaning depends on the codec for that logical bitstream and is specified in a specific media mapping. A special value of -1 (in two's complement) indicates that no packets finish on this page. 🙈
  4. bitstream_serial_number: a 4 Byte field containing the unique serial number by which the logical bitstream is identified. 🆔
  5. page_sequence_number: a 4 Byte field containing the sequence number of the page so the decoder can identify page loss. 📉 This sequence number is increasing on each logical bitstream separately.
  6. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of the page (including header with zero CRC field and page content). The generator polynomial is 0x04c11db7. 🧮
  7. number_page_segments: 1 Byte giving the number of segment entries encoded in the segment table. 🔢
  8. segment_table: number_page_segments Bytes containing the lacing values of all segments in this page. Each Byte contains one lacing value. 🎶

The total header size in bytes is given by:

header_size = number_page_segments + 27 [Byte]

The total page size in Bytes is given by:

page_size = header_size + sum(lacing_values: 1..number_page_segments)
[Byte]

7. Security Considerations 🔐

Okay bestie, this part is serious, so read it carefully 💀

The Ogg encapsulation format is a container format and only encapsulates content (such as Vorbis-encoded audio). It does not provide any generic encryption or signing of itself or its contained content bitstreams. However, it encapsulates any kind of content bitstream as long as there is a codec for it, so it is able to contain encrypted and signed content data. It is also possible to add an external security mechanism that encrypts or signs an Ogg physical bitstream, which gives you content confidentiality and authenticity. 🫶

As Ogg encapsulates binary data, it is possible to include executable content in an Ogg bitstream. 😬 This can be an issue with applications implemented using the Ogg format, especially when Ogg is used for streaming or file transfer in a networking scenario. So Ogg itself does not pose a threat there. ✨ However, an application decoding Ogg and its encapsulated content bitstreams has to ensure correct handling of manipulated bitstreams, of buffer overflows and the like. Don't sleep on this one, it's the whole vibe 🚨

8. References 📚

[1] Walleij, L., "The application/ogg Media Type", RFC 3534, May 2003.

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

Appendix A. Glossary of terms and abbreviations 🧠

  • bos page: The initial page (beginning of stream) of a logical bitstream, which contains information to identify the codec type and other decoding-relevant information.
  • chaining (or sequential multiplexing): Concatenation of two or more complete physical Ogg bitstreams.
  • eos page: The final page (end of stream) of a logical bitstream.
  • granule position: An increasing position number for a specific logical bitstream stored in the page header. Its meaning depends on the codec for that logical bitstream and is specified in a specific media mapping.
  • grouping (or concurrent multiplexing): Interleaving of pages of several logical bitstreams into one complete physical Ogg bitstream under the restriction that all bos pages of all grouped logical bitstreams MUST appear before any data pages.
  • lacing value: An entry in the segment table of a page header representing the size of the related segment.
  • logical bitstream: A sequence of bits being the result of an encoded media stream.
  • media mapping: A specific use of the Ogg encapsulation format together with a specific (set of) codec(s).
  • (Ogg) packet: A subpart of a logical bitstream that is created by the encoder for that bitstream and represents a meaningful entity for the encoder, but only a sequence of bits to the Ogg encapsulation.
  • (Ogg) page: A physical bitstream consists of a sequence of Ogg pages containing data of one logical bitstream only. It usually contains a group of contiguous segments of one packet only, but sometimes packets are too large and need to be split over several pages.
  • physical (Ogg) bitstream: The sequence of bits resulting from an Ogg encapsulation of one or several logical bitstreams. It consists of a sequence of pages from the logical bitstreams with the restriction that the pages of one logical bitstream MUST come in their correct temporal order.
  • (Ogg) segment: The Ogg encapsulation process splits each packet into chunks of 255 bytes plus a last fractional chunk of less than 255 bytes. These chunks are called segments.

Appendix B. Acknowledgements 💜

The author gratefully acknowledges the work that Christopher Montgomery and the Xiph.Org foundation have done in defining the Ogg multimedia project and, as part of it, the open file format described in this document. 🌷 The author hopes that providing this document to the Internet community will help promote the Ogg multimedia project at http://www.xiph.org/. Many thanks also for the many technical and typo corrections that C. Montgomery and the Ogg community provided as feedback to this RFC. 🫶🎀

Author's Address 🦋

Silvia Pfeiffer
CSIRO, Australia
Locked Bag 17
North Ryde, NSW  2113
Australia

Phone: +61 2 9325 3141
EMail: Silvia.Pfeiffer@csiro.au
URI:   http://www.cmis.csiro.au/Silvia.Pfeiffer/

Okay bestie, let's do the legal stuff real quick 💅

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it can be copied and shared with others. People can also make derivative works that comment on or explain it, or help with implementing it, and publish and distribute those too, in whole or in part, with no restriction of any kind. The one condition is that the above copyright notice and this paragraph must be included on all such copies and derivative works 🎀

However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. There are two exceptions: changes needed for developing Internet standards, where the procedures for copyrights defined in the Internet Standards process must be followed, and translation into languages other than English 🌸

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, no take-backs ✨

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, 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. 🙈

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to them for keeping the lights on 🧚

📦 where this page comes from