Subject: RE: http-parameters registry vs RFC 2616

From: Larry Masinter <[email-masked]>
Date: Mon, 24 Oct 2005 15:19:44 -0700

>  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.
Transfer-coding (section 3.6) should contain
     chunked, identity, gzip, compress, deflate

Yes, some tokens (gzip, compress, identity) appear in both.

Larry
-- 
http://larry.masinter.net

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Mon, 24 Oct 2005 21:43:53 -0500

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

> 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

---

From: "IANA" <[email-masked]>
Date: Tue, 25 Oct 2005 16:00:07 +0000

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

Larry Masinter wrote:
> RFC 2616 calls for two IANA registries, content-coding tokens and 
> transfer-coding tokens.
> 

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.

Bill

---

From: Larry Masinter <[email-masked]>
Date: Wed, 26 Oct 2005 15:01:25 -0700

In http://www.iana.org/numbers.html, I suggest making them both
"FCFS with specification recommended", because it is not
explicitly required (says SHOULD).

Note that RFC 2817 HTTP status codes and HTTP upgrade tokens
are also HTTP parameters, so I wonder about combining these
two registries without combining all of the other ones associated
with HTTP. Also,
HTTP Status Codes 	RFC3293  	RFC and FCFS (section 10.2)
but this is really RFC 2817, isn't it?

In http://www.iana.org/assignments/http-parameters

I suggest you remove the text:

#   If you are looking for the HTTP data types, you should look in the
#   file "url-schemes". 
#   See:  http://www.iana.org/assignments/url-schemes

I think this text is confusing. HTTP relies on many IANA registered
values, including character sets, media types, and language tags, 
as well as the other above registries for status codes and upgrade
tokens, but doesn't directly rely on the URI scheme registry.

I think the specification for all of the transfer-coding and content-coding
values should be RFC 2616; do you want to give explicit section numbers?
For HTTP Transfer codings,  I would add "identity" and note that it
was withdrawn in the errata.

=======================================================================
HTTP Content-Coding Values
Name      Description                            Reference
------    ------------------------------------- ---------
compress UNIX "compress"  program method       [RFC2616] section 3.5
deflate  "zlib" format[RFC1950] with
          with "deflate" compression[RFC2616]  [RFC2616] section 3.5
gzip     Same as GNU zip[RFC1952]              [RFC2616] section 3.5

HTTP Transfer Coding Values

Name      Description                            Reference
------    ------------------------------------- ---------
chunked    Transfer in a series of chunks       [RFC2616] Section 3.6.1
compress   UNIX "compress"  program method      [RFC2616] section 3.6
deflate    "zlib" format[RFC1950] with
           with "deflate" compression[RFC2616]  [RFC2616] section 3.6
gzip       Same as GNU zip[RFC1952]             [RFC2616] section 3.6
identity   (withdrawn in errata to RFC 2616)    [RFC2616] section 3.6

---

From: "IANA" <[email-masked]>
Date: Thu, 27 Oct 2005 18:58:13 +0000

Larry,

We have made all of the below updates.

To respond to your suggetion about combining the registries, I'd like to
keep them separate for now.
After we get the IANA Matrix page (http://www.iana.org/numbers.html) in
better shape (there are still a lot of updates that have to be made for
registries where the procedures are unknown) we will then review the
registries to see if we can combine any or mark some as not used anymore.

Thank you for the suggestion.

I think these are in good shape now.
Thank you very much for your assistance.

Michelle Cotton
IANA

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]] 
Sent: Wednesday, October 26, 2005 3:01 PM
To: 'IANA'
Cc: [email-masked]; 'Scott Hollenbeck'; [email-masked];
[email-masked]; 'William A. Rowe, Jr.'
Subject: RE: http-parameters registry vs RFC 2616

In http://www.iana.org/numbers.html, I suggest making them both "FCFS with
specification recommended", because it is not explicitly required (says
SHOULD).

Note that RFC 2817 HTTP status codes and HTTP upgrade tokens are also HTTP
parameters, so I wonder about combining these two registries without
combining all of the other ones associated with HTTP. Also,
HTTP Status Codes 	RFC3293  	RFC and FCFS (section 10.2)
but this is really RFC 2817, isn't it?

I think this text is confusing. HTTP relies on many IANA registered values,
including character sets, media types, and language tags, as well as the
other above registries for status codes and upgrade tokens, but doesn't
directly rely on the URI scheme registry.

I think the specification for all of the transfer-coding and content-coding
values should be RFC 2616; do you want to give explicit section numbers?
For HTTP Transfer codings,  I would add "identity" and note that it was
withdrawn in the errata.