Charter, changes in prefixes, and documentation

Mark Davis mark.davis at icu-project.org
Wed Mar 26 02:24:22 CET 2008


That works for me. Item (iii) needs fleshing out a bit.

               (iii) A change to the basic approach taken in the design
               team documents.

It is clear when a change would violate (i) or (ii) would be, but not clear
what kind of change would violate (iii).

Mark

On Tue, Mar 25, 2008 at 5:18 PM, John C Klensin <klensin at jck.com> wrote:

> Hi.
>
> In the hope of moving forward --i.e., of bringing the charter
> discussion to a conclusion and getting on to the actual work, a
> few comments and then what I hope will be a generally-acceptable
> proposal.
>
> I think we have gotten confused about the difference between
> "things the WG cannot discuss or document without rechartering"
> and "things the WG can't agree to do without rechartering and
> getting more general IETF approval in the process".   At least I
> have.  In particular, I think the discussion about why we don't
> want to change prefixes, what the consequences of such changes
> might be, and what incompatibilities we are willing to introduce
> and live with without making such a change is important and
> should be captured in one of the documents (presumably
> "Rationale" if we don't change structure).  I think that should
> be done both for the information of people making the transition
> and to reduce the odds of some future discussion having to
> repeat this discussion.
>
> At the same time, it seems clear that the WG should not be
> making prefix changes without a much broader review, going in,
> of the implications of doing that.
>
> Suggestions:
>
> (1) As far as the charter is concerned, let's be explicit about
> this.  Rather than scattering language and restrictions
> throughout the charter, let's make an explicit subsection that
> says something like
>
>        The WG will stop, close, and recommend that a new
>        charter be generated if it concludes that any of the
>        following are necessary to meet its goals:
>
>                (i) A change to the "punycode" algorithm or the ACE
>                approach to encoding names in the DNS
>
>                (ii) A change to the ACE prefix from "xn--"
>
>                (iii) A change to the basic approach taken in the design
>                team documents.
>
> I think that is the entire list, but, if others have other
> items, let's get them on the list.
>
> (2) We will work together to improve the description of the
> prefix change issue in "Rationale".  I've now got a few ideas
> about how to improve that text, but will need more input on this.
>
> (3) I will work with Simon and others who are interested to be
> sure that every incompatible change is discussed carefully and
> that the discussion includes at least some recommendations as to
> what to do about each one.   That material can go into Rationale
> or, if the WG prefers, we can pull it out into another (fifth?)
> document.   I don't think we need to decide on that before
> chartering, but the charter text should probably indicate that
> we will be explicit about any incompatible changes.
>
> (4)  While I don't see the "alternatives" draft as a WG project,
> I will try to work with Shawn and anyone else who is interested
> to be sure that document contains a good description of the pros
> and cons of just putting UTF-8 into the DNS rather than using an
> ACE-style encoding.   Again, that is not a discussion we should
> need to have anew each time people start thinking about IDNs.
>
> Does that work for people?
>
>    john
>
> _______________________________________________
> 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/46cb2aa5/attachment-0001.html


More information about the Idna-update mailing list