Changing the xn-- prefix
Erik van der Poel
erikv at google.com
Thu Mar 20 15:47:32 CET 2008
Also note that while another prefix may help somewhat with Eszett,
ZWNJ and Final Small Sigma, it would not help at all with the Tonos
In addition, these problems interact with the pre-processing spec.
They are not limited to the current 4 IDNA200X drafts.
On Thu, Mar 20, 2008 at 7:17 AM, Simon Josefsson <simon at josefsson.org> wrote:
> Vint Cerf <vint at google.com> writes:
> > 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.
> The -issues document contain a starting pointer, but it needs to be
> What is missing now is an analysis of why changing the prefix is still a
> bad idea if IDNABIS contains other backwards incompatible changes.
> I have not seen any discussion that weights the cost of changing the
> prefix with the cost of living with any security problems caused by
> IDNA2003 and IDNABIS incompatibilities. Partly that is because the
> discussions about _which_ backwards incompatible changes IDNABIS will
> make have not finished yet. Until those discussions reach a conclusion,
> we can't evaluate whether changing the prefix is too costly or not.
> If the backwards incompatible changes in IDNABIS will be limited to the
> PR-29 strings, I believe we can live with the costs off having the PR-29
> strings be filtered by IDNA200x implementations. If there will be other
> changes, such as permitting german-ezset, the answer could be different.
> Note that having to change the prefix can be an argument against
> permitting german-ezset in IDNABIS, so these to issues interact.
> > 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
More information about the Idna-update