--On Friday, August 29, 2014 17:01 +0000 "Joe Hildebrand (jhildebr)" <[email protected]> wrote:
>... > I agree we want one set over time. But I thought that we had > agreed in Toronto that we were going to try to get Precis > right, then look at removing the tables from IDNA201x, > including Precis by reference in those documents. Joe, I did not come away from Toronto very sure about what had been agreed. The Etherpad minutes (http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-precis?useMonospaceFont=true to be sure I am looking at the right thing) don't help much and I'm far more interested in Peter's interpretation as it will show up in the next draft than I am in mine. None of that really interacts with the intent of my note, which was to stress the importance of moving swiftly to a single set of rules and tables. That is an important distinction relative to what you said above: at least in the context of what I understood of the Toronto discussions, it didn't make much difference whether the single set of rules and tables was the IDNA ones, the PRECIS ones, or a new synthesis that both referenced. What is important is that we have a fairly firm commitment make the combination, not a "probably over time" or "look at it in the future" situation. If we don't have a clear plan and a sufficient commitment of resources that Pete (at least) is convinced that the plan will be executed, then my pre-Toronto concerns are unchanged and the compromises reached there are meaningless. That wasn't what caused my note. Again, I've been waiting for Peter because I don't think it is worth commenting on what I think might be in a draft that has not been posted. What did prompt me to write it is that, in addition to the small bugs Takahiro found, three things have happened (or gotten more on my radar) since Toronto. I was planning to raise them, if still relevant, only after Peter got the Framework spec posted, but here goes: (1) WHATEWG and W3C are charging ahead with an "Encoding" specification that will apparently be normatively referenced from HTML5. With luck, an update to/ replacement for the very important "Charmod" spec will be right behind it. The recommendations of those two documents are different from the proposed PRECIS ones. One way of looking at those specs in the PRECIS context is that they represent yet another profile and that, if two or three (or more if IDNA is counted) are acceptable, than one more doesn't make much difference. At the other extreme, some people have taken the position about the W3C Charmod and Encoding specs that the web, web browsers, web applications, and web access to other protocols so dominates the Internet that any conflicting specifications are irrelevant (or various worse words). If the latter view is correct than the PRECIS effort is, to a considerable degree, a waste of time and, worse, a source of more confusion, at least for any protocol that might be accessed via a URI or from a web page. My own view is that reality lies somewhere between those positions, but my ability to predict the near-term future is notoriously bad. (2) There has been a heated discussion on the IDNA list. It involves both rather small issues (the treatment of a single code point that is now to Unicode 7.0 and perhaps a few code points that are perceived as "like" it) and a very large one. The latter involves two questions that might ultimately be the same one: (1) Whether some of the fundamental assumptions that were made in designing the rule structure for IDNA, assumptions about code point assignment and Unicode evolution, were incorrect and, if so, whether IDNA2008 itself is workable. (2) Whether some fundamental assumptions made in IDNA about the nature and implications about normalization, especially normalization prior to comparison, are correct and, whether they are correct or not, whether normalization as it actually works is appropriate for contexts that involve short strings and no language information or requirements to conform to the rules of a single language. Those assumptions are fundamental enough to the IDNA design and the parts of the PRECIS design that are derived from the IDNA rule structure that, if there is a problem with IDNA, there is probably (almost certainly) a problem with PRECIS too. (3) Independent of anything going on in the IETF, I've gotten another reminder about something I mentioned briefly during the meeting in Toronto. There is a sufficient cluster of inter-organizational and political issues surrounding IDNA that any attempt to open it and change its definitional method, even if we assured people that the changes had no actual effect on anything other than the definitional method, could cause some very unpleasant reactions, some of which might be harmful to the IETF. I'm just not sure that "eventually conform IDNA to PRECIS" is really practical, especially since one of the arguments that would certainly be made would compare the in-depth review in multiple communities that IDNA2008 received and its present deployment compared to those for PRECIS documents. john But _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
