Changing the xn-- prefix

[Erik van der Poel]

I also support option 1 for the charter itself.

I would prefer not to add a new prefix to the mix, but I believe that
adding Eszett, ZWNJ and Final Small Sigma under the current prefix
would not be easy either.

The "opposite" problem of Tonos (where IDNA2003 does not do enough
mapping, according to a Greek representative) may be quite difficult
too.

Note that IDNA2003 maps Eszett, ZWNJ and Final Small Sigma away, but
does not map Tonos away. And the Greek representative seemed to think
that the Tonos problem was bigger.

Erik

On Thu, Mar 20, 2008 at 6:55 AM, Vint Cerf <vint at google.com> wrote:
> i would support option 1 as formulated below although I sincerely
>  hope that the documents as they stand support a conclusion that the
>  prefix need not be altered.
>
>
>
>  On Mar 20, 2008, at 9:17 AM, Simon Josefsson wrote:
>
>  > Paul Hoffman <phoffman at imc.org> writes:
>  >
>  >> Given that this is a charter issue, not a post-charter issue, it
>  >> would
>  >> be good to get some closure here. Is anyone supporting changing the
>  >> xn-- prefix other than Simon?
>  >
>  > I never said that I support changing the xn-- prefix.  I believe it
>  > would be quite unfortunate if we change the prefix.
>  >
>  > However, I believe that ruling out changing the prefix in the WG
>  > charter
>  > is premature.  How high the costs of changing the prefix will be
>  > depends
>  > on the costs of changing other things in IDNA in backwards
>  > incompatible
>  > ways, such as the encoding of ß.
>  >
>  > Since the WG is empowered to make backwards incompatible changes, I
>  > believe the WG should be equally empowered to consider whether
>  > changing
>  > the prefix yield lower overall deployment costs.
>  >
>  > I believe that the WG charter should say that the WG is:
>  >
>  >   1) able to consider any backwards incompatible change, including
>  > the ß
>  >   character and changing the prefix.
>  >
>  >   2) not able to consider backwards incompatible changes at all, i.e.,
>  >   that every string valid under IDNA2003 should remain valid and
>  > encode
>  >   to the same value.
>  >
>  > Considering that we are still discussing which changes is a good
>  > idea or
>  > not, I think option 1) gives the WG better instruments to produce a
>  > technically optimal solution given all constraints.
>  >
>  > /Simon
>  > _______________________________________________
>  > Idna-update mailing list
>  > Idna-update at alvestrand.no
>  > http://www.alvestrand.no/mailman/listinfo/idna-update
>
>  _______________________________________________
>  Idna-update mailing list
>  Idna-update at alvestrand.no
>  http://www.alvestrand.no/mailman/listinfo/idna-update
>