Subject: Final (?) procedural question.

From: Jim Gettys <[email-masked]>
Date: Wed, 26 Nov 2003 13:55:55 -0500

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 <[email-masked]>
HP Labs, Cambridge Research Laboratory

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 28 Nov 2003 10:32:06 -0800

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,