idna-mapping update

["Martin J. Dürst"]

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 
about.

> 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' 
lookup.

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).

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp