W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

revision of "content coding" and "advise to RFC Editor"

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
Message-Id: <96May31.221310pdt.2733@golden.parc.xerox.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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:01 EDT