Re: [apps-discuss] Last Call: <draft-faltstrom-5892bis-04.txt> (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard

[Mark Davis ☕ <[e-mail]>]

I also favor publication of the document with a minimum of further fuss.

[For a somewhat different reason. I do believe that
draft-faltstrom-5892bis-04.txt
makes an incorrect choice, breaking compatibility when that isn't at all
necessary. However, I don't think that any further discussion will change
the decision-maker's minds. Since further discussion appears to just be a
waste of everyone's time,  the document might as well just get issued.]

Mark

*— Il meglio è l’inimico del bene —*


On Wed, May 25, 2011 at 10:32, John C Klensin <[e-mail]> wrote:

> Just for the record,..
>
> I favor the publication of this document with a minimum of
> further fuss.
>
> I read and studied this document before the first I-D was
> published, participated in discussion of it on the IDNABIS WG
> list and again on the APPSAWG list.  In each case, essentially
> the same arguments were repeated and the same conclusion
> reached.  While the consensus is definitely rough, we are
> putting a tremendous amount of of review cycles and energy into
> a document whose essence is "we have agreed to do nothing".  We
> rarely publish documentation of a decision to do nothing in the
> RFC Series.  Instead, we simply do nothing and move on.
>
>   john
>
>
> _Background and Reprise (in case needed or wanted)_
>
> The argument for doing something --that this document makes and
> describes the wrong decision-- is rooted in a set of decisions
> the IDNABIS WG made (also with rough, rather than perfect,
> consensus) a rather long time ago.  One of the key differences
> between IDNA2003 and IDNA2008 was the decision to try to be
> independent of Unicode versions rather than tied to a specific
> one.  That decision, in turn, required that the IDNA properties
> of characters -- whether they are Protocol-VALID in IDNs,
> DISALLOWED, or valid only in particular contexts -- became a
> matter of rules that, in turn, utilize the values of selected
> Unicode properties.  If Unicode never changed the properties for
> a particular character once it was allocated (and avoided
> introducing new characters that required contextual evaluation),
> the rule-set would never need to be changed and we would never
> have to debate, and write, documents keyed to those property
> changes: new versions of Unicode would add new characters but
> not change the IDNA properties of previously-assigned ones.
>
> The world is not that perfect: Unicode does change properties of
> already-assigned characters.  It is rare (how rare depends a bit
> on perspective), but it does happen.  The reason is typically to
> correct errors made in earlier property assignments, but other
> reasons are possible (or one could have a
> philosophically-interesting, but otherwise useless, debate about
> how far the concept of "error" can extend).  IDNA2008 recognized
> that such changes might occur and might be disruptive, so
> provided for a special "exception" rule that could be used to
> list characters that needed special treatment because of changes
> in Unicode properties.
>
> The WG discussed the question of how to fill the table
> associated with that rule in, a discussion that included the
> realization that having the  having the table become large would
> simply create a new, and hard-to-explain, Unicode-version
> dependence.  One option was to populate it automatically: if
> Unicode made changes, the table would be filled in to preserve
> the behavior at the time the character was first allocated or
> that appeared in Unicode 5.2, whichever came later, whatever
> that was.  Another was to turn the decision-making over to the
> Unicode consortium, which might have resulted in either that
> same rule or a rule that treated changes from DISALLOWED to
> PVALID differently from changes from PVALID to DISALLOWED.  The
> WG rejected both of those ideas as well as the idea that some
> changes were inherently more attractive than others.
>
> Instead, the WG concluded that Unicode changes of character
> properties that affected IDNA needed to be evaluated in the IETF
> on a case-by-case basis as to whether they were important enough
> to justify an addition to that exceptions table or whether the
> balance fell on the side of keeping the table small (and IDNA
> reflecting as short and obvious an exception list as possible).
>
> In this particular instance, rough consensus has been reached in
> multiple groups that it is better to keep the rules (including
> that exception table stable and compact than to change the rules
> in the interest of preserving the character classification
> associated with Unicode 5.2.  Had the characters involved been
> less obscure, or more obviously used in domain names for other
> than demonstrations and equivalent purposes, perhaps the
> decision would have been different (or, if they were less
> obscure, perhaps Unicode either would not have made the mistake
> in the first place or would have decided to not correct it).
>
> But wanting to consider the tradeoffs and balance between those
> alternatives, probably with a slight bias toward not making
> changes in the rules,a is precisely why the WG decided that
> Unicode property changes needed to be considered by the IETF and
> on a case-by-case basis.
>
> There is no perfect answer to the tradeoff involved unless
> Unicode never makes an error and concludes that a correction is
> needed.  Because no perfect answer exists, it is possible to
> reopen the issue, bring up variations on the same old arguments,
> and debate them endlessly.  In that case, we've done that at
> least twice, and, depending on how one counts, probably several
> more times.  We've decided.  Let's get the document published
> rather than seeing how many words and person-hours we can devote
> to saying "we considered the issue and decided to do nothing".
>
>     john
>
> --On Monday, 23 May, 2011 15:19 -0700 The IESG
> <[e-mail]> wrote:
>
> >
> > The IESG has received a request from the Applications Area
> > Working Group WG (appsawg) to consider the following document:
> > - 'The Unicode code points and IDNA - Unicode 6.0'
> >   <draft-faltstrom-5892bis-04.txt> as a Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> > solicits final comments on this action. Please send
> > substantive comments to the [e-mail] mailing lists by
> > 2011-06-06.
>
>
>
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>