Re: Proposed changes to Internet Media Type registration, consistency of use

On Wednesday, September 4, 2002, 5:35:23 PM, Ian wrote:

IBJ> Hello,

IBJ> I have edited the TAG finding "Internet Media Type
IBJ> registration, consistency of use" [1] to include
IBJ> proposals resulting from two action items:

IBJ> 1) Changes to registration requirements in light of
IBJ>     a better understanding of interactions between
IBJ>     W3C, IETF, and IANA processes. Joseph Reagle
IBJ>     has written a document entitled ""How to Register a
IBJ>     Media Type with IANA" [4]. This document recommends
IBJ>     a process whereby the registration information is part
IBJ>     of an Internet Draft (not part of a W3C specification)
IBJ>     and must be available for review along with the
IBJ>     specification. The finding text has been updated to
IBJ>     refer to that "best practice" document. The revised
IBJ>     language is:

IBJ>       "The IETF registration forms MUST be available for
IBJ>        review along with the specification no later than
IBJ>        Candidate Recommendation (or at last call if the
IBJ>        Working Group expects to advance directly to Proposed
IBJ>        Recommendation). The IETF registration forms SHOULD be
IBJ>        available for review no later than last call."

IBJ>     This may obviate Joseph's objection [3] to the previous
IBJ>     language.

Okay, and this accomplishes some of the same goals, but does mean that
the registration text (for example, the security section) is
non-normative and not paert of a Rec; this is undesirable. It also
means that last calls and CR and soon need to explicitely invite
review of this extra document.

IBJ>     Since the process described in [4] has not been heavily
IBJ>     tested, there is a cautionary note in the references
IBJ>     section, designed to address a concern raised by Paul
IBJ>     Cotton. The language is:


IBJ>      "How to Register a Media Type with IANA". This is an informal
IBJ>      document intended to capture best practice for requests that a
IBJ>      Mime Type defined by a W3C Recommendation be registered in the
IBJ>      IANA registry. This document may change as W3C learns from
IBJ>      experience or as processes in the various organizations evolve.

IBJ> 2) Incorporate comments from Chris Lilley about charset
IBJ>     headers [2]. I have modified section 3, and made some
IBJ>     editorial changes to Chris' text.

The modification is generally good; however the final paragraph of section
3 alludes to a question while leaving it unanswered:

  The use of the charset parameter, when the charset is reliably known
  and agrees with the encoding declaration, is RECOMMENDED, since this
  information can be used by non-XML processors to determine
  authoritatively the charset of the XML MIME entity.

When the charset is reliably known and disagrees with the encoding
declaration do what? (Or "don't do that"/"it is an error", which would
work for me).

When the charset is not known, do what (Omit the charset parameter)

When the charset parameter is omitted and the media type is a non-text
+xml type, the client shoud do what? Read the XML encoding declaration
(works for me). Do something counter-intuitive and stupid like assume
its US-ASCII thus breaking all UTF-16 and any non-English UTF-8 XML
content, in a mistaken attempt to propagate the mistakes of text/* on
the rest of the world (sorry, my preference may be detectable there).

IBJ> Your comments on both proposals welcome,

IBJ>   - Ian

IBJ> [1]
IBJ> [2]
IBJ> [3]
IBJ> [4]


Received on Thursday, 5 September 2002 09:33:22 UTC