- Home
- RFCs by Subject
- data formats
- compression
compression
Lossless data compression formats
Within this page
compression RFCs (40)
RFC 9924: Advanced Professional Video
Informational- Y. Lim
- M. Park
- M. Budagavi
- R. Joshi
- K. Choi
- February 2026
- Independent Stream publication
Abstract
This document describes the bitstream format of Advanced Professional Video (APV) and its decoding process. APV is a professional video codec providing visually lossless compression mainly for recording and post production.
Abstract
This document describes the bitstream format of Advanced Professional Video (APV) and its decoding process. APV is a professional video codec providing visually lossless compression mainly for recording and post production.
RFC 9800: Compressed SRv6 Segment List Encoding
Proposed Standard- W. Cheng
- C. Filsfils
- Z. Li
- B. Decraene
- F. Clad
- June 2025
- IETF publication
- Routing Area
Abstract
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.
This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document.
Abstract
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.
This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document.
RFC 9639: Free Lossless Audio Codec (FLAC)
Proposed Standard- M.Q.C. van Beurden
- A. Weaver
- December 2024
- IETF publication
- Applications and Real-Time Area
Abstract
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals. It does this losslessly, i.e., it does so without losing information. FLAC is free in the sense that its specification is open and its reference implementation is open source. Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources. Decoding of FLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic.
Abstract
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals. It does this losslessly, i.e., it does so without losing information. FLAC is free in the sense that its specification is open and its reference implementation is open source. Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources. Decoding of FLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic.
RFC 9204: QPACK: Field Compression for HTTP/3
Proposed Standard- C. Krasic
- M. Bishop
- A. Frindell
- June 2022
- IETF publication
- Web and Internet Transport
Abstract
This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking.
Abstract
This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking.
RFC 9043: FFV1 Video Coding Format Versions 0, 1, and 3
Informational- M. Niedermayer
- D. Rice
- J. Martinez
- August 2021
- IETF publication
- Applications and Real-Time Area
Abstract
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.
Abstract
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.
RFC 8761: Video Codec Requirements and Evaluation Methodology
Informational- A. Filippov
- A. Norkin
- J.R. Alvarez
- April 2020
- IETF publication
- Applications and Real-Time Area
Abstract
This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.
Abstract
This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.
RFC 8486: Ambisonics in an Ogg Opus Container
Proposed Standard- J. Skoglund
- M. Graczyk
- October 2018
- IETF publication
- Applications and Real-Time Area
Abstract
This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.
Abstract
This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.
RFC 8308: Extension Negotiation in the Secure Shell (SSH) Protocol
Proposed Standard- D. Bider
- March 2018
- IETF publication
- Security Area
Abstract
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.
Abstract
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.
RFC 7655: RTP Payload Format for G.711.0
Proposed Standard- M. Ramalho
- P. Jones
- N. Harada
- M. Perumal
- L. Miao
- November 2015
- IETF publication
- Applications and Real-Time Area
Abstract
This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.
Abstract
This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.
RFC 6716: Definition of the Opus Audio Codec
Proposed Standard- JM. Valin
- K. Vos
- T. Terriberry
- September 2012
- IETF publication
- Applications and Real-Time Area
Abstract
This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]
Abstract
This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]
RFC 6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
Proposed Standard- J. Hui
- P. Thubert
- September 2011
- IETF publication
- Internet Area
Abstract
This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]
Abstract
This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]
RFC 5172: Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol
Proposed Standard- S. Varada
- March 2008
- IETF publication
- Internet Area
Abstract
The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.
This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]
Abstract
The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.
This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]
RFC 5216: The EAP-TLS Authentication Protocol
Proposed Standard- D. Simon
- B. Aboba
- R. Hurst
- March 2008
- IETF publication
- Security Area
Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.
This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]
Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.
This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]
RFC 5112: The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)
Proposed Standard- M. Garcia-Martin
- January 2008
- IETF publication
Abstract
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. [STANDARDS-TRACK]
Abstract
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. [STANDARDS-TRACK]
RFC 5049: Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
Proposed Standard- C. Bormann
- Z. Liu
- R. Price
- G. Camarillo
- December 2007
- IETF publication
- Transport Area
Abstract
This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]
Abstract
This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]
RFC 4896: Signaling Compression (SigComp) Corrections and Clarifications
Proposed Standard- A. Surtees
- M. West
- A.B. Roach
- June 2007
- IETF publication
- Transport Area
Abstract
This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]
Abstract
This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]
RFC 4465: Signaling Compression (SigComp) Torture Tests
Informational- A. Surtees
- M. West
- June 2006
- IETF publication
- Transport Area
Abstract
This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. This memo provides information for the Internet community.
Abstract
This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. This memo provides information for the Internet community.
RFC 4464: Signaling Compression (SigComp) Users' Guide
Informational- A. Surtees
- M. West
- May 2006
- IETF publication
- Transport Area
Abstract
This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community.
Abstract
This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community.
RFC 4184: RTP Payload Format for AC-3 Audio
Proposed Standard- B. Link
- T. Hager
- J. Flaks
- October 2005
- IETF publication
- Real-time Applications and Infrastructure Area
Abstract
This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]
Abstract
This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]
RFC 4077: A Negative Acknowledgement Mechanism for Signaling Compression
Proposed Standard- A.B. Roach
- May 2005
- IETF publication
- Transport Area
Abstract
This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]
Abstract
This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]
RFC 3749: Transport Layer Security Protocol Compression Methods
Proposed Standard- S. Hollenbeck
- May 2004
- IETF publication
- Security Area
Abstract
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]
Abstract
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]
RFC 3597: Handling of Unknown DNS Resource Record (RR) Types
Proposed Standard- A. Gustafsson
- September 2003
- IETF publication
- Internet Area
Abstract
Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]
Abstract
Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]
RFC 3485: The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
Proposed Standard- M. Garcia-Martin
- C. Bormann
- J. Ott
- R. Price
- A. B. Roach
- March 2003
- IETF publication
- Real-time Applications and Infrastructure Area
Abstract
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]
Abstract
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]
RFC 3320: Signaling Compression (SigComp)
Proposed Standard- R. Price
- C. Bormann
- J. Christoffersson
- H. Hannu
- Z. Liu
- J. Rosenberg
- January 2003
- IETF publication
- Transport Area
Abstract
This document defines SigComp, a solution for compressing messages
generated by application protocols such as SIP [RFC-2543] and RTSP
[RFC-2326]. The architecture and pre-requisites of SigComp are
outlined, along with the format of the SigComp message.
Decompression functionality for SigComp is provided by a 'Universal
Decompressor Virtual Machine' optimized for the task of running
decompression algorithms. The UDVM can be configured to understand
the output of many well-known compressors such as DEFLATE [RFC-1951].
Abstract
This document defines SigComp, a solution for compressing messages
generated by application protocols such as SIP [RFC-2543] and RTSP
[RFC-2326]. The architecture and pre-requisites of SigComp are
outlined, along with the format of the SigComp message.
Decompression functionality for SigComp is provided by a 'Universal
Decompressor Virtual Machine' optimized for the task of running
decompression algorithms. The UDVM can be configured to understand
the output of many well-known compressors such as DEFLATE [RFC-1951].
RFC 3321: Signaling Compression (SigComp) - Extended Operations
Proposed Standard- H. Hannu
- J. Christoffersson
- S. Forsgren
- K.-C. Leung
- Z. Liu
- R. Price
- January 2003
- IETF publication
- Transport Area
Abstract
This document describes how to implement certain mechanisms in
SigComp (Signaling Compression), RFC XXX, which can significantly
improve the compression efficiency compared to using simple per-
message compression.
SigComp uses a UDVM (Universal Decompressor Virtual Machine) for
decompression, and the mechanisms described in this document are
possible to implement using the UDVM instructions defined in RFC XXX.
Abstract
This document describes how to implement certain mechanisms in
SigComp (Signaling Compression), RFC XXX, which can significantly
improve the compression efficiency compared to using simple per-
message compression.
SigComp uses a UDVM (Universal Decompressor Virtual Machine) for
decompression, and the mechanisms described in this document are
possible to implement using the UDVM instructions defined in RFC XXX.
RFC 3322: Signaling Compression (SigComp) Requirements & Assumptions
Informational- H. Hannu
- January 2003
- IETF publication
- Transport Area
Abstract
In wireless environments and especially in cellular systems, e.g. GSM
(Global System for Mobile communications) and UMTS (Universal Mobile
Telecommunications System), there is a need to maximize the transport
efficiency for data over the radio interface. With the introduction
of SIP/SDP (Session Initiation Protocol/Session Description Protocol)
to cellular devices, compression of the signaling messages should be
considered in order to improve both service availability and quality,
mainly by reducing the user idle time, e.g. at call setup. The
purpose of this document is to outline requirements and motivations
for development of a scheme for compression and decompression of
messages from signaling protocols.
Abstract
In wireless environments and especially in cellular systems, e.g. GSM
(Global System for Mobile communications) and UMTS (Universal Mobile
Telecommunications System), there is a need to maximize the transport
efficiency for data over the radio interface. With the introduction
of SIP/SDP (Session Initiation Protocol/Session Description Protocol)
to cellular devices, compression of the signaling messages should be
considered in order to improve both service availability and quality,
mainly by reducing the user idle time, e.g. at call setup. The
purpose of this document is to outline requirements and motivations
for development of a scheme for compression and decompression of
messages from signaling protocols.
RFC 3284: The VCDIFF Generic Differencing and Compression Data Format
Proposed Standard- D. Korn
- J. MacDonald
- J. Mogul
- K. Vo
- July 2002
- IETF publication
- General Area
Abstract
This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]
Abstract
This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]
RFC 3150: BCP 48: End-to-end Performance Implications of Slow Links
Best Current Practice- S. Dawkins
- G. Montenegro
- M. Kojo
- V. Magret
- July 2001
- IETF publication
- Transport Area
Abstract
This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Abstract
This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC 2716: PPP EAP TLS Authentication Protocol
Experimental- B. Aboba
- D. Simon
- October 1999
- IETF publication
- Internet Area
Abstract
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.
Obsoleted by RFC 5216
Abstract
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.
RFC 2364: PPP Over AAL5
Proposed Standard- G. Gross
- M. Kaycee
- A. Li
- A. Malis
- J. Stephens
- July 1998
- IETF publication
- Internet Area
Abstract
This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]
Abstract
This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]
RFC 2118: Microsoft Point-To-Point Compression (MPPC) Protocol
Informational- G. Pall
- March 1997
- IETF publication
- Internet Area
Abstract
This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1975: PPP Magnalink Variable Resource Compression
Informational- D. Schremp
- J. Black
- J. Weiss
- August 1996
- IETF publication
- Internet Area
Abstract
The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1976: PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)
Informational- K. Schneider
- S. Venters
- August 1996
- IETF publication
- Internet Area
Abstract
This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1977: PPP BSD Compression Protocol
Informational- V. Schryver
- August 1996
- IETF publication
- Internet Area
Abstract
This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1978: PPP Predictor Compression Protocol
Informational- D. Rand
- August 1996
- IETF publication
- Internet Area
Abstract
This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1993: PPP Gandalf FZA Compression Protocol
Informational- A. Barbir
- D. Carr
- W. Simpson
- August 1996
- IETF publication
- Internet Area
Abstract
This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.
Abstract
This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.
RFC 1962: The PPP Compression Control Protocol (CCP)
Proposed Standard- D. Rand
- June 1996
- IETF publication
- Internet Area
Abstract
This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]
Abstract
This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]
RFC 1915: BCP 3: Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol
Best Current Practice- F. Kastenholz
- February 1996
- Legacy publication
Abstract
The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Abstract
The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC 804: CCITT draft recommendation T.4
Unknown- International Telegraph and Telephone Consultative Committee of the International Telecommunication Union
- January 1981
- Legacy publication
Abstract
This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.
Abstract
This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.
RFC 468: FTP data compression
Unknown- R.T. Braden
- March 1973
- Legacy publication
Subscribe to compression
Get notified when:
- RFC changes to status, obsoleted by, updates, updated by, or subseries.
- New RFC added to this subject or below
- The subject was merged into another.