RE: http-parameters registry vs RFC 2616

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:LMM@acm.org] 
Sent: Wednesday, October 26, 2005 3:01 PM
To: 'IANA'
Cc: hardie@qualcomm.com; 'Scott Hollenbeck'; bjoern@hoehrmann.de;
ietf-http-wg@w3.org; '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?

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

Received on Thursday, 27 October 2005 19:04:22 UTC