From: David Barr (barr@visi.com)
Date: Thu Feb 20 2003 - 14:37:21 CST
> I hope you'll agree, as Ned Freed indicated in his note, that
> with a 9 to 8 vote (which was taken before the recent
> feedback on IESG thinking)
Alright, I've had enough of this bullshit. I don't know why this 9 to 8
myth keeps coming back up.
The consensus of the vote was option #1 (UTF-8 in headers allowed, encoding
required for entry into email).
The result for #1 was 10 to 4, with 4 votes stuck on the fence.
http://www.landfield.com/usefor/2002/Dec/0004.html
Or to put it another way, only 4 out the 18 who voted said no to #1.
That still seems to me to be a consensus, or at least a very strong
indication of the bounds of what the group is willing to accept.
> 1. Of all the alternatives proposed, the one that we said was the
consensus opinion got
> and with no WG chair, no one should be speaking for what the WG does or
does not support.
No WG chair? Huh? As I said after the vote, I gave my reasons why I didn't
vote, and the fact that I would have voted with the consensus opinion.
Adding my vote would make it 11 to 4 (or 4 out of 18 saying no).
> So, here is my iteration on Charles's requirements for i18n newsgroup
> names:
>
> 1. Be available to current user agents, even if not presented
> ideally. 2. Be available on current injector agents and
> servers. 3. Be available on current gateways for use by
> moderators. 4. Support current wildmat usage of * globbing
> between components (e.g., alt.*.binaries). 5. Support current
> wildmat usage of * globbing within components (e.g.,
> alt.s*.binaries). 6. Support current wildmat usage of ? and
> [] globbing within components (e.g., alt.[abc]???.binaries).
> 7. Support a single canonical format, both on-disk and
> on-the-wire. 8. Have a canonical format that can travel
> safely by SMTP, POP3, IMAP4, etc.
>
> I believe raw UTF-8 only partially satisfies 1 (as some
> existing user agents don't enable input of 8-bit newsgroup
> names), fully satisfies 2, 4, 5, & 7, and fails 3, 6, and 8.
> I believe punycode fully satisfies 1, 2, 3, 4, 7, & 8, and
> fails 5 & 6.
If you say UTF-8 only partially satisifies 1, then Punycode certainly
doesn't satisfy it. Or do you expect people to input punycode by hand? Of
the things that you UTF-8 fails on, #3 and #8 is pointless because the
proposal is to encode anyway with respect to email and #6 is a wash because
punycode also fails it (and has been said before "?" and "[]" wildmat
globbing is not widely used). Personally I think of all the requirements,
#1 gets the most weight with me, and dealing with UTF-8 (both displaying and
entry) is far more widespread now than punycode. As an example, doesn't
RedHat ship with LANG=en_UTF8 ? I know Solaris support for UTF-8 has been
around for several major releases now.
--Dave