RE: http-parameters registry vs RFC 2616

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 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. [] 
Sent: Monday, October 24, 2005 7:44 PM
To: Larry Masinter
Cc: 'IANA';; 'Scott Hollenbeck';;
Subject: Re: http-parameters registry vs RFC 2616

Larry Masinter wrote:
>> 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