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 <john-i...@jck.com> 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 > <iesg-secret...@ietf.org> 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 ietf@ietf.org mailing lists by > > 2011-06-06. > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
