"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Mon Dec 21 08:33:12 CET 2009
Hello Paul, others,
On 2009/12/21 1:41, Paul Hoffman wrote:
> If we re-open -mappings, it should only be to weaken any implied recommendation of its universality,
There is no implied or explicit universality (in the sense of "use this,
and nothing else, everywhere) in the mappings document that I read. If
you see that, please tell me where it is.
Even if "universality" is taken in a much weaker sense ("if and when you
map, use this, and nothing else"), that's in no way what the document is
> not to fine-tune the barely-proposed transform.
If "barely proposed" means that it's not yet around for very long, that
wouldn't be true. I advocated essentially the same transform in the
design team for IDN 2003. I still think it's what would make most sense.
If "barely proposed" means that it's not well specified, then please
tell me what is unclear, so that we can fix that.
> Michel is correct that the fact that it exists will cause some people to think that it is recommended by the IETF, regardless of its IETF status. However, history has shown that there is *nothing* we can do to change that perception for many readers.
> One change that the WG might consider making to -mappings is to replace section 2 with "do it like in TR46".
In at least one way, that would be a big step forward (assuming that
TR46 gets fixed to not map ß and friends).
While I don't think we need mapping everywhere, and I don't think we
need exactly the same mapping everywhere, I strongly think that when it
comes to mapping there should essentially be three choices:
a) Do not map. This applies to registration as well as to 'low-level'
b) Map, using a *single*, well-defined mapping. The two candidates we
have currently are something along TR 46, and something along the
mapping draft. Both of these candidates are reasonable solutions. This
applies to user input into a field that's known to be an IDN or label,
and probably to cases where we know that there was no chance to fix user
input, e.g. because the user typed into a text editor.
c) Map, with slight deviation from b) adapted to local needs. This
should be very few and very far between, and only after really, really
serious consideration of the consequences. The Turkish upper-case 'I' is
about the only use case that I can reasonably come up with.
> I don't think this is necessary because that's what TR46 already says. Another change would be to say "map just like in IDNA 2003, but with more recent tables"; that option didn't go over so well earlier in this WG. :-)
> The main purpose of -mappings is to emphasize the lack of requirements for mapping, not which one might be good. If there is some more wordsmithing to section 1 to make that even clearer, we could do that, but changing the document to say "this document has no real requirements, but you might want to consider doing mappings that are that document over there that has many requirements" would cause more confusion about what the IETF meant, not less.
I think we do interoperability a serious disservice if the compromise
between those people who think we need a single mapping everywhere and
those people who think that we want to discourage mapping is that we
half-heartedly propose a mapping with many caveats (as done currently
with the mapping draft). What we need for interoperability is one clear
mapping that's only used when really necessary (because we agree we
don't want mapping everywhere), and can be slightly modified when really
necessary (because there might be cases where a variation is
appropriate, although they are few and far between).
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the Idna-update