Charset reviewer appointed

[Harald Tveit Alvestrand <Harald.Alvestrand@maxware.no>]

The Apps Area Directors have appointed Harald Alvestrand (me) to the
post of charset reviewer, as described in RFC 2278.

A special alias has been set up that will not be changed if the person
changes: charset-reviewer@apps.ietf.org

I just want to remind everyone of the actual language in RFC 2278:

4.2.  Charset Reviewer

   When the two week period has passed and the registration proposer is
   convinced that consensus has been achieved, the registration
   application should be submitted to IANA and the charset reviewer. The
   charset reviewer, who is appointed by the IETF Applications Area
   Director(s), either approves the request for registration or rejects
   it.  Rejection may occur because of significant objections raised on
   the list or objections raised externally.  If the charset reviewer
   considers the registration sufficiently important and controversial,
   a last call for comments may be issued to the full IETF. The charset
   reviewer may also recommend standards track processing (before or
   after registration) when that appears appropriate and the level of
   specification of the charset is adequate.

   Decisions made by the reviewer must be posted to the ietf-charsets
   mailing list within 14 days. Decisions made by the reviewer may be
   appealed to the IESG.

Note especially that:
- it is the responsibility of the *REGISTRATION PROPOSER*
  to forward the registration to me and IANA when he thinks that consensus is
  achieved. Nothing happens by magic.

- BOTH the registration proposer and the character set reviewer have to
  agree that there is consensus before registration can happen.

WRT outstanding registrations, my opinion at the moment is:

- UTF-7 is noncontroversial. It needs to include
  language that says it can be used as a MIME text/plain charset.

- UTF-16 is controversial because of the BOM and byte-order issues.
  I think consensus has not been achieved; the significant objections
  are:

  - While there is consensus that big-endian is preferred, there is
    not consensus if little-endian is acceptable.
  - While there is consensus that little-endian, if allowed, MUST
    include the BOM, there is no consensus on where, if ever, a BOM
    must be inserted in big-endian encoded text.
  - There is no consensus that it is possible to write sensible rules
    about using the BOM in protocols that carry multiple independent
    pieces of text.

  This registration will wait a bit yet.

Regards,

                 Harald T. Alvestrand


-- 
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no