RFC 2250

RTP Payload Format for MPEG1/MPEG2 Video

📅 published January 1998, from ietf

RFC 2250 💖

RTP Payload Format for MPEG1/MPEG2 Video 🎀

Okay bestie, first the header stuff 📋 This is from the Network Working Group, published January 1998, and it's Request for Comments 2250. It's a Standards Track doc, which means it's an actual proposed Internet standard 💅 The authors are D. Hoffman and G. Fernando (Sun Microsystems, Inc.), V. Goyal (Precept Software, Inc.), and M. Civanlar (AT&T Labs - Research) 🫶 It obsoletes RFC 2038 🍓 The header doesn't list any Updates.

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

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

Abstract 🦋

Okay so this memo describes a packetization scheme for MPEG video and audio streams 🎬 The scheme can be used to move a video or audio flow over the transport protocols that RTP supports. There are two approaches. The first one is built for maximum interoperability with MPEG System environments. The second one is built for maximum compatibility with other RTP-encapsulated media streams and future conference control work at the IETF 👑

This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms in Section 3.4 got extended to include extra picture header information that MPEG2 needs 🔥 There's also a brand-new section on security considerations for this payload type 🙈

1. Introduction 💜

ISO/IEC JTC1/SC29 WG11, which is also called the MPEG committee, defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard (ISO/IEC 13818)[2] 🧚 This memo describes a packetization scheme that moves MPEG video and audio streams over RTP (Real-time Transport Protocol), version 2 [3, 4] ✨

The MPEG1 spec has three parts: System, Video and Audio 🌈 It was designed mainly for CD-ROM apps and it's tuned for about 1.5 Mbits/sec combined data rates. The video and audio parts describe the basic format of the video or audio stream. These formats define the Elementary Streams (ES) 💅 The MPEG1 System spec wraps up the ES in a way that carries Presentation Time Stamps (PTS), Decoding Time Stamps and System Clock references. It also multiplexes MPEG1 compressed video and audio ES's with user data, which is so clever 🤩

MPEG2 is structured in a similar way, but it hasn't been limited to CD-ROM apps, so it's got more range 🌟 The MPEG2 System spec defines two system stream formats: the MPEG2 Transport Stream (MTS) and the MPEG2 Program Stream (MPS). The MTS is built for communicating or storing one or more programs of MPEG2 compressed data, plus other data, in relatively error-prone environments 🌧️ The MPS is built for relatively error-free environments ☀️

We want interoperability among 4 types of end-systems. The 4 types are:

  1. Transmitting Interworking Unit (TIU)

Receives MPEG information from a native MTS system for distribution over packet networks using a native RTP-based system layer (such as an IP-based internetwork). Examples: real-time encoder, MTS satellite link to Internet, video server with MTS-encoded source material.

  1. Receiving Interworking Unit (RIU)

Receives MPEG information in real time from an RTP-based network for forwarding to a native MTS environment. Examples: Internet-based video server to MTS-based cable distribution plant.

  1. Transmitting Internet End-System (TAES)

Transmits MPEG information generated or stored within the internet end-system itself, or received from internet-based computer networks. Example: video server.

  1. Receiving Internet End-System (RAES)

Receives MPEG information over an RTP-based internet for consumption at the internet end-system or forwarding to traditional computer network. Example: desktop PC or workstation viewing training video.

Each of the 2 types of transmitters must work with each of the 2 types of receivers 🫶 Because it's probable that the TAES, and certain that the RAES, will be based on existing and planned internet-connected computers, it's highly desirable for the interoperable protocol to be based on RTP 💖

Because there's a whole range of apps that might use MPEG streams, we propose to define two payload formats ✨

Much of the MPEG community cares about using one of the MPEG System encodings, so in Section 2 we propose encapsulations of MPEG1 System streams and MPEG2 Transport and Program Streams with RTP 🎀 This profile supports the full semantics of MPEG System and gives basic interoperability among all four end-system types 👑

When it's only internet-based end-systems (TAES and RAES) talking, a payload format that's more compatible with the Internet architecture is wanted 🦋 It defers some of the system issues to other protocols the Internet community is defining, such as the MMUSIC WG. In Section 3 we propose an encapsulation of compressed video and audio data (called "Elementary Streams" (ES) in MPEG docs) that complies with either MPEG1 or MPEG2 🌸 Neither of the MPEG1 or MPEG2 System standards gets used here. The ES's get encapsulated directly with RTP 🧚

Throughout this spec we use a lot of MPEG terminology 📚 The reader should check the primary MPEG references for the official definitions of this terminology 💜

2. Encapsulation of MPEG System and Transport Streams 🌈

Each RTP packet will contain a timestamp derived from the sender's 90KHz clock reference 🕰️ This clock is synchronized to the system stream Program Clock Reference (PCR) or System Clock Reference (SCR), and it represents the target transmission time of the first byte of the packet payload. The RTP timestamp will not be passed to the MPEG decoder 🙅‍♀️ This use of the timestamp is kinda different from how RTP normally works, because it's not considered the media display or presentation timestamp. The main jobs of the RTP timestamp are to estimate and reduce any network-induced jitter and to sync up relative time drift between the transmitter and receiver 💅

For MPEG2 Transport Streams, the RTP payload will contain an integral number of MPEG transport packets 📦 To avoid end system inefficiencies, data from multiple small MTS packets (normally fixed in size at 188 bytes) get aggregated into a single RTP packet ✨ The number of transport packets contained is computed by dividing the RTP payload length by the length of an MTS packet (188) 🧮

For MPEG2 Program streams and MPEG1 system streams there are no packetization restrictions. These streams are treated as a packetized stream of bytes 🍓

2.1 RTP header usage 🎀

The RTP header fields get used like this:

  • Payload Type: Distinct payload types should be assigned for MPEG1 System Streams, MPEG2 Program Streams and MPEG2 Transport Streams. See [4] for payload type assignments. 💜
  • M bit: Set to 1 whenever the timestamp is discontinuous (such as might happen when a sender switches from one data source to another). This allows the receiver and any intervening RTP mixers or translators that are synchronizing to the flow to ignore the difference between this timestamp and any previous timestamp in their clock phase detectors. 🦋
  • timestamp: 32 bit 90K Hz timestamp representing the target transmission time for the first byte of the packet. ⭐

3. Encapsulation of MPEG Elementary Streams 🧚

The following ES types may be encapsulated directly in RTP:

  • (a) MPEG1 Video (ISO/IEC 11172-2)
  • (b) MPEG2 Video (ISO/IEC 13818-2)
  • (c) MPEG1 Audio (ISO/IEC 11172-3)
  • (d) MPEG2 Audio (ISO/IEC 13818-3)

A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and MPEG1/MPEG2 Audio, respectively 🌸 Further indication as to whether the data is MPEG1 or MPEG2 need not be provided in the RTP or MPEG-specific headers of this encapsulation, because that info is already in the ES headers 💅

Presentation Time Stamps (PTS) of 32 bits with an accuracy of 90 kHz shall be carried in the fixed RTP header. All packets that make up an audio or video frame shall have the same time stamp 🫶 It's giving consistency, and I'm obsessed 😭

3.1 MPEG Video elementary streams ✨

okay so MPEG1 Video and MPEG2 Video can be told apart at the video sequence header 👀. For MPEG2 Video, a sequence_header() is followed by sequence_extension(). The profile and level (like MAIN_Profile@MAIN_Level, HIGH_Profile@HIGH_Level, etc.) get determined by the profile_and_level_indicator field in the MPEG2 sequence_extension header 💅

ngl, the MPEG bitstream was designed for pretty error-free environments 🥺. There's a ton of dependency inside the stream (both temporal AND spatial), so losing some data can make other perfectly fine data useless 😭. This encapsulation uses application layer framing info plus extra info in the RTP stream-specific header, which allows certain recovery mechanisms 🛟. Appendix 1 suggests several recovery strategies based on the properties of this encapsulation 🧠.

MPEG pictures can be huge, so they'll normally get fragmented into packets smaller than a typical LAN/WAN MTU 📦. The fragmentation rules are:

  1. The MPEG Video_Sequence_Header, when present, will always be at the beginning of an RTP payload.
  2. An MPEG GOP_header, when present, will always be at the beginning of the RTP payload, or will follow a Video_Sequence_Header.
  3. An MPEG Picture_Header, when present, will always be at the beginning of a RTP payload, or will follow a GOP_header.

Each ES header must be completely contained within the packet. So a minimum RTP payload size of 261 bytes must be supported, so it can fit the largest single header defined in the ES (that's the extension_data() header containing the quant_matrix_extension()) 🎀. Otherwise, there are no restrictions on where headers may appear within packet payloads.

Heads up: that 261-byte minimum is the big one to remember when you size your payloads 💖

In MPEG, each picture is made up of one or more "slices," and a slice is meant to be the unit of recovery from data loss or corruption 🍰. An MPEG-compliant decoder will normally advance to the beginning of the next slice whenever it hits an error in the stream. MPEG slice begin and end bits are provided in the encapsulation header to make that easier 🙌.

The beginning of a slice must either be the first data in a packet (after any MPEG ES headers), or it must follow some integral number of slices in a packet. This requirement ensures that the beginning of the next slice after one with a missing packet can be found without the receiver having to scan the packet contents. Slices may be fragmented across packets as long as all the above rules are met 🧩.

An implementation based on this encapsulation assumes that the Video_Sequence_Header is repeated periodically in the MPEG bitstream. In practice (though it's not required by the MPEG standard), this is used to allow channel switching, and to receive and start decoding a continuously relayed MPEG bitstream at arbitrary points in the media stream 📺. It's suggested that when playing back an MPEG stream from a file format (where the Video_Sequence_Header may only be represented at the beginning of the stream), the first Video_Sequence_Header (preceded by an end-of-stream indicator) be saved by the packetizer for periodic injection into the network stream 💜.

3.2 MPEG Audio elementary streams 🎧

MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG ancillary_data() header. For either MPEG1 or MPEG2 Audio, distinct Presentation Time Stamps may be present for frames that correspond to either 384 samples for Layer-I, or 1152 samples for Layer-II or Layer-III. The actual number of bytes needed to represent that many samples will vary depending on the encoder parameters 🎶.

Multiple audio frames may be encapsulated within one RTP packet. In this case, an integral number of audio frames must be contained within the packet, and the fragmentation header defined in Section 3.5 shall be set to 0 🫶.

Also, if relatively short packets are used, one frame might be so large that it straddles multiple RTP packets 😳. For example, for Layer-II MPEG audio sampled at 44.1 KHz, each frame represents a time slot of 26.1 msec. At this sampling rate, if the compressed bit-rate is 384 kbits/sec (i.e. 48 kBytes/sec), then the average audio frame size is 1.25 KBytes. If packets were 500 Bytes long, each audio frame would straddle 3 RTP packets 🤯.

The audio fragmentation indicator header (See Section 3.5) shall be present for an MPEG1/2 Audio payload type to provide for this fragmentation 🌸.

3.3 RTP Fixed Header for MPEG ES encapsulation 🦋

The RTP header fields are used as follows:

  • Payload Type: Distinct payload types should be assigned for video elementary streams and audio elementary streams. See [4] for payload type assignments.
  • M bit: For video, set to 1 on the packet containing the MPEG frame end code, 0 otherwise. For audio, set to 1 on the first packet of a "talk-spurt," 0 otherwise.
  • PT: MPEG video or audio stream ID.
  • timestamp: 32-bit 90K Hz timestamp representing the presentation time of an MPEG picture or audio frame. It's the same for all packets that make up a picture or audio frame. It may not be monotonically increasing in a video stream if B pictures are present in the stream. For packets that contain only a video sequence and/or GOP header, the timestamp is that of the subsequent picture ⏰.

3.4 MPEG Video-specific header 🎀

This header shall be attached to each RTP packet after the RTP fixed header 💅. Here's how it's laid out:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    MBZ  |T|         TR        | |N|S|B|E|  P  | | BFC | | FFC |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   AN              FBV     FFV

Here's what each field means:

  • MBZ: Unused. MUST be set to zero in the current specification. This space is reserved for future use.
  • T: MPEG-2 (Two) specific header extension present (1 bit). Set to 1 when the MPEG-2 video-specific header extension (see Section 3.4.1) follows this header. This extension may be needed for improved error resilience; however, its inclusion in an RTP packet is optional. (See Appendix 1.)
  • TR: Temporal-Reference (10 bits). The temporal reference of the current picture within the current GOP. This value ranges from 0-1023 and is constant for all RTP packets of a given picture.
  • AN: Active N bit for error resilience (1 bit). Set to 1 when the following bit (N) is used to signal changes in the picture header information for MPEG-2 payloads. It must be set to 0 for MPEG-1 payloads or when the N bit is not used.
  • N: New picture header (1 bit). Used for MPEG-2 payloads when the previous bit (AN) is set to 1. Otherwise, it must be set to zero. Set to 1 when the information contained in the previously transmitted Picture Headers can't be used to reconstruct a header for the current picture. This happens when the current picture is encoded using a different set of parameters than the previous pictures of the same type. The N bit must be constant for all RTP packets that belong to the same picture, so that receipt of any packet from a picture allows detecting whether the information necessary for reconstruction was contained in that picture (N = 1) or in a previous one (N = 0) 🔍.
  • S: Sequence-header-present (1 bit). Normally 0, and set to 1 at the occurrence of each MPEG sequence header. Used to detect the presence of a sequence header in an RTP packet.
  • B: Beginning-of-slice (BS) (1 bit). Set when the start of the packet payload is a slice start code, or when a slice start code is preceded only by one or more of a Video_Sequence_Header, GOP_header and/or Picture_Header.
  • E: End-of-slice (ES) (1 bit). Set when the last byte of the payload is the end of an MPEG slice.
  • P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This value is constant for each RTP packet of a given picture. Value 000B is forbidden, and 101B - 111B are reserved to support future extensions to the MPEG ES specification 🌈.
  • FBV (full_pel_backward_vector), BFC (backward_f_code), FFV (full_pel_forward_vector), FFC (forward_f_code): Obtained from the most recent picture header, and constant for each RTP packet of a given picture. For I frames, none of these values are present in the picture header, and they must be set to zero in the RTP header. For P frames, only the last two values are present, and FBV and BFC must be set to zero in the RTP header. For B frames, all four values are present 👑.

3.4.1 MPEG-2 Video-specific header extension ✨

okay bestie, this is the MPEG-2 version of the header and it's giving full detail 💖 here's the layout:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each bit and field does 🎀

  • X: Unused (1 bit). MUST be set to zero in current specification. This space is reserved for future use.
  • E: Extensions present (1 bit). If set to 1, this header extension, including the composite display extension when D = 1, will be followed by one or more of the following extensions: quant matrix extension, picture display extension, picture temporal scalable extension, picture spatial scalable extension and copyright extension.
    • The first byte of these extensions data gives the length of the extensions in 32 bit words including the length field itself. Zero padding bytes are used at the end if required to align the extensions to 32 bit boundary.
    • Since they may not be vital in decoding of a picture, the inclusion of any one of these extensions in an RTP packet is optional even when the MPEG-2 video-specific header extension is included in the packet (T = 1). (See Appendix 1.) If present, they SHOULD be copied from the corresponding extensions following the most recent MPEG-2 picture coding extension and they remain constant for each RTP packet of a given picture.
    • The extension start code (32 bits) and the extension start code ID (4 bits) are included. Therefore the extensions are self identifying.
  • f_[0,0]: forward horizontal f_code (4 bits)
  • f_[0,1]: forward vertical f_code (4 bits)
  • f_[1,0]: backward horizontal f_code (4 bits)
  • f_[1,1]: backward vertical f_code (4 bits)
  • DC: intra_DC_precision (2 bits)
  • PS: picture_structure (2 bits)
  • T: top_field_first (1 bit)
  • P: frame_predicted_frame_dct (1 bit)
  • C: concealment_motion_vectors (1 bit)
  • Q: q_scale type (1 bit)
  • V: intra_vlc_format (1 bit)
  • A: alternate scan (1 bit)
  • R: repeat_first_field (1 bit)
  • H: chroma_420_type (1 bit)
  • G: progressive frame (1 bit)
  • D: composite_display_flag (1 bit). If set to 1, next 32 bits following this one contains 12 zeros followed by 20 bits of composite display information.

These values are copied from the most recent picture coding extension and are constant for each RTP packet of a given picture. Their meanings are as explained in the MPEG-2 standard 🌸

3.5 MPEG Audio-specific header

This header SHALL be attached to each RTP packet at the start of the payload and after any RTP headers for an MPEG1/2 Audio payload type. no skipping this one 🧚

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MBZ               |          Frag_offset          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Frag_offset: Byte offset into the audio frame for the data in this packet.

4. Security Considerations 🔐

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3], and any appropriate RTP profile (for example [4]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption MAY be performed after compression so there is no conflict between the two operations.

A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.

As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.

A security review of this payload format found no additional considerations beyond those in the RTP specification. ✅

Appendix 1. Error Recovery and Resynchronization Strategies 🧩

The following error recovery and resynchronization strategies are intended to be guidelines only. A compliant receiver is free to employ alternative (or no) strategies.

When initially decoding an RTP-encapsulated MPEG Elementary Stream, the receiver MAY discard all packets until the Sequence-header-present bit is set to 1. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder.

Loss of packets containing the GOP_header and/or Picture_Header are detected by an unexpected change in the Temporal-Reference and Picture-Type values. Consider the following example GOP sequence:

In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ...
In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...

Consider also two counters:

ref_pic_temp (Reference Picture (I,P) Temporal Reference)
dep_pic_temp (Dependent Picture (B) Temporal Reference)

At each GOP beginning, set these counters to the temporal reference value of the corresponding picture type. For our example GOP sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing BOTH counters by unity with each following picture. Ref_pic_temp SHOULD match the temporal references of the I and P frames, and dep_pic_temp SHOULD match the temporal references of the B frames.

    dep_pic_temp: -  0  1  2  3  4  5  6  7        8  9
In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
    ref_pic_temp: 2  3  4  5  6  7  8  9  10  ^    11
                  --------------------------  |    ^
                             Match            Drop |
                                                   Mismatch
                                                    in ref_pic_temp

The loss of a GOP header can be detected by matching the appropriate counter (based on picture type) to the temporal reference value. A mismatch indicates a lost GOP header. If desired, a GOP header can be re-constructed using a "null" time_code, repeating the closed_gop flag from previous GOP headers, and setting the broken_link flag to 1.

The loss of a Picture_Header can also be detected by a mismatch in the Temporal Reference contained in the RTP packet from the appropriate dep_pic_temp or ref_pic_temp counters at the receiver.

For MPEG-1 payloads, after scanning to the next Beginning-of-slice the Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV and FFC contained in that packet, and from stream-dependent default values.

For MPEG-2, additional information is needed for the reconstruction. This information is provided by the MPEG-2 video specific header extension contained in that packet if the T bit is set to 1, or the Picture Header for the current picture may be available from previous packets belonging to the same picture. The transmitter's strategy for inclusion of the MPEG-2 video specific header extension may depend upon a number of factors. This header may not be needed when:

  1. the information has been transmitted a sufficient number of times in previous packets to assure reception with the desired probability, or
  2. the information is transmitted over a separate reliable channel, or
  3. expected loss rates are low enough that missed frames are not a concern, or
  4. conserving bandwidth is more important than error resilience, etc.

If T=1 and E=0, there may be extensions present in the original video bitstream that are not included in the current packet. The transmitter MAY choose not to include extensions in a packet when they are not necessary for decoding or if one of the cases listed above for not including the MPEG-2 video specific header extension in a packet applies only to the extension data.

If N=0, then the Picture Header from a previous picture of the same type (I,P or B) MAY be used so long as at least one packet has been received for every intervening picture of the same type and that the N bit was 0 for each of those pictures. This may involve:

  1. Saving the relevant picture header information that can be obtained from the MPEG-2 video specific header extension or directly from the video bitstream for each picture type,
  2. Keeping validity indicators for this saved information based on the received N bits and lost packets, and,
  3. Updating the data whenever a packet with N=1 is received.

If the necessary information is not available from any of these sources, data deletion until a new picture start code is advised.

Any time an RTP packet is lost (as indicated by a gap in the RTP sequence number), the receiver MAY discard all packets until the Beginning-of-slice bit is set. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder starting at the next slice boundary (possibly after reconstruction of the GOP_header and/or Picture_Header as described above).

References 📚

  • [1] ISO/IEC International Standard 11172; "Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbits/s", November 1993.
  • [2] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated audio information", November 1994.
  • [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
  • [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
  • [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

Authors' Addresses 🫶

  • Gerard Fernando
    • Sun Microsystems, Inc.
    • Mail-stop UMPK14-305
    • 2550 Garcia Avenue
    • Mountain View, California 94043-1100
    • USA
    • Phone: +1 415-786-6373
    • EMail: gerard.fernando@eng.sun.com
  • Vivek Goyal
    • Precept Software, Inc.
    • 1072 Arastradero Rd,
    • Palo Alto, CA 94304
    • USA
    • Phone: +1 415-845-5200
    • EMail: goyal@precept.com
  • Don Hoffman
    • Sun Microsystems, Inc.
    • Mail-stop UMPK14-305
    • 2550 Garcia Avenue
    • Mountain View, California 94043-1100
    • USA
    • Phone: +1 503-297-1580
    • EMail: don.hoffman@eng.sun.com
  • M. Reha Civanlar
    • AT&T Labs - Research
    • 100 Schutlz Drive, 3-213
    • Red Bank, NJ 07701-7033
    • USA
    • Phone: +1 732-345-3305
    • EMail: civanlar@research.att.com

Okay bestie, time for the legal bit, and yes it matters 💅 Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀

This document and translations of it may be copied and furnished to others. Derivative works that comment on or explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The one catch 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. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it 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 ✨

This document and the information in it are 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 💀

📦 where this page comes from