Content/Transfer-Codings organization/IANA considerations (issue 143, 188, 189)

[Julian Reschke]

Hi,

I just spent some time looking at issue 143, which is about updating
both IANA registration procedures and the registry contents.

While doing that, I noticed that there are more changes we should do:

1) find an RFC 5226 defined IANA policy for the registration

Note that <http://www.iana.org/assignments/http-parameters> currently says:

"First Come First Served with specification recommended"

while RFC 2616 did state:

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

(so no mention of first come first serve)

(new issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188>)

2) After splitting the spec we define gzip/compress/deflate in Part 3,
although they can also act as Transfer-Codings (Part 1). Moving them
into Part 1 would thus put them all into a single place.

(new issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/189>)

[Bjoern Hoehrmann]

* Julian Reschke wrote:
>I just spent some time looking at issue 143, which is about updating
>both IANA registration procedures and the registry contents.

Note that some changes to the registries had been made in response to
http://lists.w3.org/Archives/Public/www-archive/2005Oct/0015.html and
the follow-ups to that on this list.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Julian Reschke]

Julian Reschke wrote:

> Hi,
>
> I just spent some time looking at issue 143, which is about updating
> both IANA registration procedures and the registry contents.
>
> While doing that, I noticed that there are more changes we should do:
>
> 1) find an RFC 5226 defined IANA policy for the registration
>
> Note that <http://www.iana.org/assignments/http-parameters> currently says:
>
> "First Come First Served with specification recommended"
>
> while RFC 2616 did state:
>
> "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."
>
> (so no mention of first come first serve)
>
> (new issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188>)
> ...

We discussed this in Stockholm, and consensus in the room was that we
want to require a specification plus expert review (see RFC 5226,
Section 4.1).

I have rephrased the sections in Part 1 (Transfer Codings) and Part 3
(Content Codings) accordingly; see
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/670>.

BR, Julian

[Julian Reschke]

Julian Reschke wrote:
> ...
> 2) After splitting the spec we define gzip/compress/deflate in Part 3,
> although they can also act as Transfer-Codings (Part 1). Moving them
> into Part 1 would thus put them all into a single place.
>
> (new issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/189>)
> ...

Done with revision
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/673>.

There was One More Thing related to Transfer and Content Codings we
discussed in Stockholm: the individual codings are really independent of
the context they are used in, as RFC 2616 already stated:

"Although the value describes the content-coding, what is more important
is that it indicates what decoding mechanism will be required to remove
the encoding." --
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.5.p.3>

So they really should be defined separately from Transfer-Coding and
Content-Coding, and be collected in the same registry (surprise: IANA
already has both in "http-parameters").

Feedback appreciated...

BR, Julian

[mnot]

Closing issue.


On 08/08/2009, at 12:27 AM, Julian Reschke wrote:

> Julian Reschke wrote:
>> Hi,
>> I just spent some time looking at issue 143, which is about  
>> updating both IANA registration procedures and the registry contents.
>> While doing that, I noticed that there are more changes we should do:
>> 1) find an RFC 5226 defined IANA policy for the registration
>> Note that <http://www.iana.org/assignments/http-parameters>  
>> currently says:
>> "First Come First Served with specification recommended"
>> while RFC 2616 did state:
>> "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."
>> (so no mention of first come first serve)
>> (new issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188>)
>> ...
>
> We discussed this in Stockholm, and consensus in the room was that  
> we want to require a specification plus expert review (see RFC 5226,  
> Section 4.1).
>
> I have rephrased the sections in Part 1 (Transfer Codings) and Part  
> 3 (Content Codings) accordingly; see <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/670 
> >.
>
> BR, Julian
>

--
Mark Nottingham     http://www.mnot.net/