[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] SUMMARY: reordering strawpoll
-----BEGIN PGP SIGNED MESSAGE-----
Bruce Thomson wrote:
> It is even possible to consider the compromise solution of
> having reordering only apply to scripts from those three
> countries only,
That doesn't solve anything; the people arguing against reordering
were arguing on grounds that would still hold if it were only applied
to Han ideographs and Hangul.
> except that presumably there is no way
> to do that without having it apply to Japanese as well. The
> Japanese will not like this, I think.
That's not an issue: the disadvantages apply if reordering is used at
all, not to specific languages.
Eric Brunner-Williams wrote:
> Can the editors of the affected documents accommodate both reordering and
> no-reordering in the same documents from this point forward? I think this
> is the better question, rather than trying to finesse "the right answer"
> by proxy.
>
> If yes, then the working docs delta with consequences (e.g., [30] comes back).
> If no, then the working docs branch into disjoint and seperate trees with
> consequences (e.g., "this assumes lsb" and "this assumes no lsb"), and each
> proceeds to WG-LC, IESG review, and IETF-wide-LC, and whatever status, and
> deployment future lies ahead, for each, both, or neither.
This idea is totally without merit. None of the proposed IDN protocols
work if there are two ways to do ACE encoding, and not specifying which
will be used would be disastrous for interoperability.
Since the current specification for the concensus ACE algorithm
(draft-ietf-idn-amc-ace-z-01.txt) does not include reordering, and there is
no concensus on adding it, that document should remain as it is. (If AMC-Z
is used, that is the only document that depends on a decision about
reordering.)
- --
David Hopwood <david.hopwood@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPAgC3zkCAxeYt5gVAQGkGAf9EE9aHeRlEPqwkVSwtu2K8PdOiRPLRphk
8SjmvUsmUy4AV4EkCVw0BepUif+yRCKaMlJIZ8hiZ16lDWG71haAKLuPYUiR/pv+
XmAyW8OqtxMDkpVtamWYAjZ7Y55ddZVKBuMMhD0fbwDx3lzFiCT2sdNQakFHdxLZ
e6jnaRGWx9glsQ2wDvhWJvl3YhmH0Hfq/Jhx1BPepPojFRamE/aHRGyF+S55ZFRS
C73hiFoor2Bl1dMRuYuOeri4UKo6ScPy8UFQM0GJuUCCk4bGYSpBjAU30OdiFJS6
HfmNIDDngq3LvOL87D602Sjx8f3MGBj6iJrszkNs0baOe3CcenfyPA==
=br60
-----END PGP SIGNATURE-----