- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Fri, 31 May 1996 22:13:05 PDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
content-coding = token All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding (section 14.12) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding. The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens: gzip An encoding format produced by the file compression program “gzip” (GNU zip) as described in RFC 1952[25]. This format is typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. compress The encoding format produced by the common Unix file compression program “compress”. This format is an adaptive Lempel-Ziv-Welch coding (LZW). Note: Use of program names for the identification of encoding formats is not desirable and should be discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of HTTP, applications should consider “x-gzip” and “x-compress” to be equivalent to “gzip” and “compress” respectively. deflate The “zlib” format defined in RFC 1950[ref] in combination with the “deflate” compression mechanism described in RFC 1951[ref]. New content-coding value tokens should be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new value should be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section. ================================================================ Here's a revised section 19.8: ================================================================ 19.8 Notes to RFC Editor and IANA This section of the document should be DELETED! It calls for IANA and the RFC editor to take some actions before the draft becomes a Proposed Standard. After those actions are taken, please delete this section of the specification. 19.8.1 charset registry The following names should be added to the IANA character set registry with the label “Preferred MIME name”: "US-ASCII" "ISO-8859-1" "ISO-8859-2" "ISO-8859-3" "ISO-8859-4" "ISO-8859-5" "ISO-8859-6" "ISO-8859-7" "ISO-8859-8" "ISO-8859-9" "ISO-2022-JP" "ISO-2022-JP-2" "ISO-2022-KR" "UNICODE-1-1" "UNICODE-1-1-UTF-7" "UNICODE-1-1-UTF-8" 19.8.2 content-coding values HTTP also defines a new class of registry for its content-coding values. The initial set of values defined in this document are deflate, gzip and compress. IANA should create a registry with those two entries. The registry should note that “x-gzip” and “x-compress” are used as content-codings in HTTP but that their use is deprecated. The registry should note that "specifications of the content coding algorithms needed to implement a new value should be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined RFC XXX." where RFC XXX is the number assigned to this document. 19.8.3 new media types registered This document defines two new media types which should be registerd. Specifically appendix 19.1 defines the Internet media type message/http and appendix 19.2 defines multipart/byteranges. 19.8.4 possible merge with Digest Authentication draft Note that the working group draft for Digest Authentication may be processed by the IESG at the same time as this document; we leave it to the RFC editor to decide whether to issue a single RFC containing both drafts (see section 11.2 for where it would be put); in any case, the reference in the reference list will need to be either deleted, or made to the appropriate RFC (and section 11.2 deleted).
Received on Friday, 31 May 1996 22:17:16 UTC