RE: http-parameters registry vs RFC 2616

Thank you for the quick feedback.  

I have updated the registry.  Please see:
http://www.iana.org/assignments/http-parameters 

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?

Also....

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
cleaned-up.

Michelle Cotton
IANA


-----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;
ietf-http-wg@w3.org
Subject: Re: http-parameters registry vs RFC 2616

Larry Masinter wrote:
> 
>> http://www.iana.org/assignments/http-parameters is out of sync with 
>>RFC
>>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.

Bill

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