Subject: No "identity" transfer coding -- for the errata?

From: "Larry Masinter" <[email-masked]>
Date: Mon, 5 Nov 2001 22:22:34 -0800

Greg Robson reported that there is a reference to a non-existent
section 3.6.2. Jeff Mogul points out that in

http://www1.ics.uci.edu/pub/ietf/http/hypermail/1998q3/0135.html
	[+ subsequent messages in the same thread]

that, although the working group had decided to eliminate
the "identity" transfer coding in issue CHUNKEDTRAILERS,
the edit to remove it was incomplete: Section 3.6.2 was removed, but
other references to the "identity" transfer-coding was not removed.

A simple edit in the errata would remove all mention of the
'identity' transfer-coding token value. Are there any
implementations that use it? 

I've written one possible way of handling this; another way would
be to add a section 3.6.2 that describes the "identity" token,
notes that it was half-left in by mistake in RFC 2616 and that
it MUST NOT be used.

--------------------------------------------
Section 3.6 (remove reference to non-existant section)
--------------------------------------------
OLD:
   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
                                                ^^^^^^^^^^^^^^^^^^^^
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
   ^^^^^^^^
   (section 3.5).

NEW:
   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "gzip" (section 3.5),
   "compress" (section 3.5), and "deflate" (section 3.5).

--------------------------------------
Section 4.4 (remove 'other than identity' for Transfer-Encoding case
since identity is not a valid value
---------------------------------------
OLD:

   2.If a Transfer-Encoding header field (section 14.41) is present and
                                                                   ^^^^
     has any value other than "identity", then the transfer-length is
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     defined by use of the "chunked" transfer-coding (section 3.6),
     unless the message is terminated by closing the connection.

NEW:
   2.If a Transfer-Encoding header field (section 14.41) is present,
     then the transfer-length is defined by use of the "chunked"
     transfer-coding (section 3.6), unless the message is terminated
     by closing the connection.

---------------------
OLD:
   Messages MUST NOT include both a Content-Length header field and a
   non-identity transfer-coding. If the message does include a non-
   ^^^^^^^^^^^^^
   identity transfer-coding, the Content-Length MUST be ignored.

NEW:
   Messages MUST NOT include both a Content-Length header field and a
   transfer-coding. If the message does include a transfer-coding,
   the Content-Length MUST be ignored.

---------------------
Section 19.4.5 -- remove 'identity' CTE?
---------------------
OLD:
   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
   2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
   remove any non-identity CTE ("quoted-printable" or "base64") encoding
              ^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   prior to delivering the response message to an HTTP client.
NEW:
   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
   2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
   remove any CTE encoding prior to delivering the response message to
   an HTTP client.