> James Seng writes: > > Particularly, it will explain why display of non-ASCII glyphs isnt as > > simple as "just use UTF-8 and everything is okay". > > Here we go again: IDN WG co-chair James Seng responds to a discussion of > IDNA's flaws by attacking another proposal.
Nope. If you read my mail again, you realise that the display problem which you keep banging on occurs for both UTF-8 & punycode or whatever system you come up with. Display problem is problem at a higher level, one that can only be solved by implementation and deployment, not protocol standardisation. If you disagree, then explain how protocol can enforce what the display/render engine do? > Think about that for a moment. IDNA has received massive objections > because it's horribly destructive. Seng has sent it to the IESG anyway. > How does he defend himself? By claiming that other proposals are worse. Nope. The co-chairs believe we have rough consensus within the working group to move forward these documents. The merits of other proposal(s) are irrelevant to the status of the ones we move forward. If and when the other documents have rough consensus, the co-chairs will move them forward likewise. > Refusing to consider the status quo as an option is another way of > saying ``We have to _do something_.'' That's a recipe for the Internet > protocol suite to spiral down into a neverending nightmare. That's not > how the IETF works. Once again, neither Marc or myself have said "we have to _do something_". You hear it in your dream (or nightmare). Repeating it again and again does not make it true, even if you wish it is so. The IETF works by moving documents which have rough consensus. And that is what we are doing here. > More importantly, in the absence of consensus, the status quo wins. > Something is seriously wrong when an internationalization proposal draws > objections from hundreds of Chinese-speaking users, for example. In the absense of rough consensus, yes, status quo wins. But not in this case. The objections from the Taiwanese (non-wg members btw) are noted to the group. See http://www.imc.org/idn/mail-archive/msg05977.html None of them provide any useful technical information to the last call. Neither are the protest within the IETF process as described in RFC2026 Section 6.5. -James Seng