Architecture or process?

Is it *really* appropriate for TAG to discussing/expounding W3C process issues?


At 03:33 PM 9/5/02 +0200, Chris Lilley wrote:

>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]
>  Chris                  

Graham Klyne

Received on Wednesday, 11 September 2002 07:44:18 UTC