W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2005

RE: http-parameters registry vs RFC 2616

From: IANA <iana@iana.org>
Date: Tue, 25 Oct 2005 16:00:07 +0000
Message-Id: <200510251559.j9PFxiQ11011@santee.icann.org>
To: "'William A. Rowe, Jr.'" <wrowe@rowe-clan.net>, "'Larry Masinter'" <LMM@acm.org>
Cc: <hardie@qualcomm.com>, "'Scott Hollenbeck'" <sah@428cobrajet.net>, <bjoern@hoehrmann.de>, <ietf-http-wg@w3.org>, "'Bjoern Hoehrmann'" <derhoermi@gmx.net>

Thank you for the quick feedback.  

I have updated the registry.  Please see:

I now have some more questions...

Should the descriptions be the same in the Transfer-Coding Values as they
are in the Content-Coding Values?

Any idea what the description should be for the chunked value?

Shouldn't the references for all of these values be RFC2616?


In RFC 2616 it says the following:
   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.

   New transfer-coding value tokens SHOULD be registered in the same way
   as new content-coding value tokens (section 3.5).

Yet at the following http://www.iana.org/numbers.html it says:

Content-Coding Values   RFC2616   IANA Assignment 
Transfer-Coding Values  RFC2616   FCFS (section 3.6) 

Should both of these be "Specification Required"?

Thanks in advance.  After we are done here this registry will be nicely

Michelle Cotton

-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net] 
Sent: Monday, October 24, 2005 7:44 PM
To: Larry Masinter
Cc: 'IANA'; hardie@qualcomm.com; 'Scott Hollenbeck'; bjoern@hoehrmann.de;
Subject: Re: http-parameters registry vs RFC 2616

Larry Masinter wrote:
>> http://www.iana.org/assignments/http-parameters is out of sync with 
>>2616 which established the registry. Under "HTTP Transfer Coding Values"
>>only "chunked" is listed, while RFC 2616 section 3.6 notes
> RFC 2616 calls for two IANA registries, content-coding tokens and 
> transfer-coding tokens.
> Content-coding (section 3.5) should contain
>      gzip, compress, deflate, identity.

Actually, IIUC the 'identity' encoding from RFC2616 was scratched (it was a
dangling holdover from mime body expressions), and just not quite fully
deleted before 2616 went through the final cut.  The errata further dropped
it out of existance.

> Transfer-coding (section 3.6) should contain
>      chunked, identity, gzip, compress, deflate
> Yes, some tokens (gzip, compress, identity) appear in both.

...and mean somewhat different things in the two contexts ;-)

Most client/server pairs only support 'content encoding', while the
'transfer encoding' is omitted (e.g., Content-Length instead), or is
'chunked'.  Examples to the contrary are appreciated.

Received on Tuesday, 25 October 2005 16:12:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC