- From: Harald Tveit Alvestrand <Harald.Alvestrand@maxware.no>
- Date: Sun, 21 Jun 1998 07:07:12 +0200
- To: ietf-charsets@iana.org
- Cc: iana@iana.org
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 --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Sunday, 21 June 1998 23:21:18 UTC