Making progress on the mapping question

[James Seng]

I am concern with the 2-lookup steps because it means it is not
deterministic and could be potentially subjected for abuse.

What we need is not change IDNA2008 but rather then leaving the "local
mapping" undefined with a 100 possible variation of that, we make one
defined mapping as a common denominator. If we have a common
denominator mapping, I haven't figure out if we still need a local
mapping above that...

I am also hesitate to call it IDNA2003 mapping because it implies only
IDNA2003-related mapping is done, when I can see we may need
flexibility of additional mappings if and when Unicode extend further.
John has concerns about this and I also agree so my position is also
not firm here.

-James Seng

On Mon, Mar 30, 2009 at 7:41 PM, Vint Cerf <vint at google.com> wrote:
> There has not been any significant objection to the proposals made
> during the IETF 74 meeting to apply some form of mapping during
> lookup. The two questions outstanding are:
>
> 1. what mapping function should be used?
> 2. how should it be used
>
> As Harald and others have observed, if it is applied before an
> IDNA2008-style lookup, we will not find new characters permitted under
> IDNA2008 if they happen to be mapped under IDNA2003. This seems to
> argue for:
>
> 1. first look up under IDNA2008 rules
> 2. If a domain name is found, return the corresponding results
> 3. If a domain name is not fund, apply IDNA2003 mapping
> 4. If a domain name is found, return the results
> 5. If a domain name is not found, report that no such domain name exists
>
> One final point. It seems to me that we should put the IDNA2003
> mapping function into stasis, making no future changes to it, and use
> the IDNA2008 framework to accommodate any new additions into Unicode
> versions as they are released. Assuming we have ample warning of a new
> version, we can even prepare tables suited to the new release ahead of
> time so as to have them available at the point where a new version of
> Unicode is adopted.
>
> Could the WG please analyze this proposition, point out flaws and
> suggested corrections for them?
>
> thanks
>
> vint
>
>
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>