- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 28 Nov 2003 10:32:06 -0800
- To: Jim Gettys <Jim.Gettys@hp.com>
- Cc: HTTP working group <ietf-http-wg@w3.org>
I think this is a reasonable approach. I do have concerns about the IESG's ability to keep up with registrations in general, but it's not likely that there will be a flood of new content-codings and transfer-codings (I hope). It may be helpful to review the "purpose of content coding defined in this section" to make sure that it gives complete and accurate guidance to the IESG. In particular, I've seen some interest in the definition of format-specific content- and transfer-codings (for example, one that allows more efficient transfer of XML, based on the structure of the body). There isn't any text in 3.5 that disallows non-generic codings; can this be taken to mean that the IESG shouldn't have any problem with registering such a coding? Regards, On Nov 26, 2003, at 10:55 AM, Jim Gettys wrote: > As I think I mentioned before, the IETF revised policies on us > in RFC 2434, in the time between when we submitted the draft > standard and its approval. No one noticed this change at the time. > > In sections 3.5 and 3.6 of we define content and transfer coding > values that require registration. > > RFC 2435 requires us to specify whether new values need to > be reviewed, for what purpose and/or if they need approval. > We are silent on the approval process. > >> From looking at section 2 of 2435, I believe we are > > In 3.5 we now say: > > "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." > > Unless there are complaints, I plan to revise this to say: > > > "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 > registrations are reviewed and approved by the IESG according to these > criteria." > > Since other standards bodies may define documents that might be very > appropriate for content and transfer codings, it seems to me that just > leaving it to the IESG to evaluate is the correct approach. > - > > > -- > Jim Gettys <Jim.Gettys@hp.com> > HP Labs, Cambridge Research Laboratory
Received on Friday, 28 November 2003 13:32:08 UTC