Changing the xn-- prefix

[Mark Davis]

I think the changing of the prefix would have such negative impact that
requiring a recharter for that case would be appropriate. After all, a
prefix change would still be possible -- it just makes a higher bar.
(Although I think if we are forced into a prefix change, it would not lead
to successful deployment of IDNA2008.)

So if the working group determined that it couldn't meet its objectives
without such a change (which I really doubt), rechartering would still be
possible.

Mark

On Tue, Mar 25, 2008 at 5:04 AM, Vint Cerf <vint at google.com> wrote:

> James, et al,
>
> May I suggest that we neither rule out nor explicitly suggest that
> there is need for a prefix change in the charter.
>
> If the working group comes to the conclusion that it cannot endorse
> the basic IDNA200X proposal and thinks that a new prefix is needed it
> will report that back to the IETF.
>
> To be honest, I hope that it will not come to that or, if it does, I
> hope that we can implement IDNA200X as an improvement over IDNA2003
> and that a prefix change proposal morphs into a serious "above the
> DNS" exploration that has been set aside in the past for good reasons
> but which might need to be resurrected as a serious piece of research.
>
> vint
>
>
> On Mar 25, 2008, at 7:52 AM, James Seng wrote:
>
> > I remember xn-- was selected after exhaustive data mining on .COM zone
> > file back then and in the process, we found a few others that could be
> > use. "xn" basically was then pick "randomly".
> >
> > I agree that there are complexity to change xn at this moment.
> > However, I am not totally against changing the prefix if the following
> > conditions are fulfill
> >
> > a) there is a STRONG technical reason that a new prefix is needed
> >
> > b) there must be backward compatibility with all existing IDN labels
> > with xn prefix.
> >
> > For example, and I am not making any proposal, this is really just
> > merely an example, that I would consider a change of prefix if it we
> > agreed the best way to identify IDNA vs IDNA200X labels is via the
> > prefix (and I do not necessary agree at this moment) and that no
> > IDNA200X labels with a new prefix can be de-constructed to an xn--
> > IDNA label, ie the round-trip conversion between IDN and ACE labels
> > must always be consistent.
> >
> > Much of the above are already captured somehow in Section 9.3 of the
> > issue document.
> >
> > Perhaps lets not to mention the prefix change is allowed or disallowed
> > in the charter and let the working group sort it out.
> >
> > -James Seng
> >
> > On Tue, Mar 25, 2008 at 2:29 PM, YAO Jiankang <yaojk at cnnic.cn> wrote:
> >>
> >>  ----- Original Message -----
> >>  From: "Patrik Fältström" <patrik at frobbit.se>
> >>  To: "Shawn Steele" <Shawn.Steele at microsoft.com>
> >>  Cc: <idna-update at alvestrand.no>; "John C Klensin"
> >> <klensin at jck.com>; "Mark Davis" <mark.davis at icu-project.org>
> >>  Sent: Tuesday, March 25, 2008 10:23 AM
> >>  Subject: Re: Changing the xn-- prefix
> >>
> >>
> >>
> >>> On 25 mar 2008, at 00.13, Shawn Steele wrote:
> >>>
> >>
> >>>> I reread your original mail, and in particular I don't want to get
> >>>> bogged down in the debate of details while trying to set the
> >>>> guidelines, but I'd like to try for "A prefix change MUST be
> >>>> avoided" (removing the condition).  If that's going to cause too
> >>>> much randomization, then I'd back down, but the repercussions of
> >>>> changing the prefix are huge.
> >>>
> >>
> >>> I am personally in favor of text in the charter that say "The prefix
> >>> xn-- MUST NOT be changed." where MUST NOT is defined according to
> >>> the
> >>> IETF definition in RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt).
> >>
> >>  +1
> >>
> >>
> >>
> >>> This put a constrain on the changes the wg is allowed to do to
> >>> IDNA200X (not large so that the prefix has to change) -- at least
> >>> not
> >>> without rechartering.
> >>>
> >>>    Patrik
> >>>
> >>> _______________________________________________
> >>
> >>
> >>> 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
> >>
> >>
> > _______________________________________________
> > Idna-update mailing list
> > Idna-update at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/idna-update
>
>


-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080325/79ddc7cd/attachment.html