(IESG copied since this document is still listed in the tracker as "approved- announcement to be sent")
--On Tuesday, May 27, 2014 11:24 -0600 Peter Saint-Andre <[email protected]> wrote: > This version attempts to address IESG review as well as > feedback from John Klensin. > > Peter > > On 5/27/14, 11:22 AM, [email protected] wrote: >> >> A new version (-17) has been submitted for >> draft-ietf-precis-framework: >> http://www.ietf.org/internet-drafts/draft-ietf-precis-framewo >> rk-17.txt Peter, While I very much appreciate the changes/ corrections to details, my basic concerns about the interoperability consequences of the strategy taken in this document remain. After carefully reading the document again and to review, those major concerns fall into four categories: (1) "Almost like IDNA but..." is a guaranteed source of user confusion and violations of the Law of Least Astonishment unless we can provide an explanation of why the differences exist, an explanation that can be aligned with user intuition. The latter is much better done by a model of "same rules but the following historical exceptions..." than by two different sets of rules that are described as similar but not quite the same. Having some of Categories A-J identical to IDNA and others almost the same is a guarantee of confusion and a near-guarantee of improperly implemented libraries that try to share code and don't quite get it right. The new "BEGIN DEFINITION FROM RFC 5892" lines in Section 7 help make the relationship clear, but leave the question of what happens to this PRECIS work should IDNA change open. We would be, IMO, far better off making IDNA clearly normative for those rules with the copied material supplied only for convenience. That way, if we had to change IDNA, the default (if no action were taken) would be that PRECIS follows it. If that is not done, then it seems to me that PRECIS needs to add explicit language to the Framework document that describes what happens to Precis-Framework if IDNA is changed in the future and/or what happens with IDNA should Precis-Framework be changed. The new text in Section 7.7 is about right, but appears to apply only there. As I have suggested before, if some changes to what was Unicode 7.0.0 beta are not made, we may need this category in the immediate future, so the question is not just theoretical. (2) Profiles are inherently bad news. There are long histories of IETF protocols succeeding because profiles were avoided and even longer histories of ITU-T and CCITT protocols failing because profiles were encouraged. While I acknowledge that historical differences among what various protocols consider acceptable and/or how they handle particular characters are part of our reality, the difference between a standard treatment with some protocol-specific exceptions and a profile is more than just a difference in definitional methods. The latter leaves the user with a lot of protocol-specific rules to remember (or, more likely, to forget and be surprised about) while the former allows the user to believe that everything is the same except for some odd edge cases. Equally important, the "exception list" approach permits us to consider deprecating the exceptions and/or to adopt "not in new implementation" rules or analogies to the separate generate and accept syntax models of RFC 5322. FWIW, it is not clear whether IdentifierClass and FreeformClass (Section 3) are "profiles" or if "profiles" are something else... and, if something else, whether it is string classes that are profiled (as Section 4.1 seems to suggest) and hence whether a profile design that needs an additional string class must update this specification or whether profiles can be written in terms of Derived Properties or even changes to the underlying category definitions or addition of new categories. (See also (4) below.) (3) At least historically, profiles have been about selections among well-defined options. Quoting from Section 1.2, paragraph 5 of RFC 3454, "The intention of stringprep is to define the tables and have the profiles of stringprep select among those defined tables". I think the general understanding of Stringprep is consistent with that, i.e., that it was a menu for classical profiles, i.e., that a profile would choose which tables to apply (for mapping, normalization, prohibition, and bidi processing (see bulleted list in paragraph 6 of RFC 3454 Section 1.2)). Stringprep also allows for additional prohibited characters and for a profile to create and use tables that are different from the Stringprep ones, identifying the latter as "an exception". If the notion of departing from those tables were actually used to any extent -- using "profiles" to change the tables themselves-- then Stringprep wouldn't be a standard at all in the usual meaning of that term, just a starting point for building standards. It doesn't go that far and I believe the community's perception is that it wasn't used that way except, possibly, as a way to work around the Unicode 3.2 limitations. The present document is another matter. It appears to explicitly authorize and even encourage "profiles" that make up entirely new rules and concepts. Perhaps that is not what is intended, but it reads that way. For example, Section 3.1 says "a protocol needing a construct between the IdentiferClass and the FreeformClass could define a restricted profile of the FreeformClass if needed". If one can define profiles, not only in terms of mixtures of classes, but to subset classes, this basically authorizes chaos. That dancing around the actual contents of the rules and categories raises additional questions that the document should address and does not appear to do so. For example, Categories B through E (Sections 7.2 - 7.5) are "defined in [RFC5822] but not used in PRECIS". Could someone invent a "profile" that took advantage of some of the statements above to use the IDNA category definitions? Worse, there are potentially good reasons for not using LDH (Category E, Section 7.5) but using a subset of ASCII that avoids the national-use character code points of ISO 646, i.e., that matched not ASCII (graphics) as Category K does but ISO 646BV. Would the permissive language in Precise-Framework that seems to allow "profiling" to change the category rules allow either a superset of Category E or, more likely, a subset of Category K. And, if so, is the resulting Category K* (or K** or K*** for other variations) things that should be amended into Precis-Framework, put into a new registry of categories, or just documented with Precis profiles as if they were "normal". (4) Section 8 "Calculation of the Derived Property" contains too many categories to be really comprehensible, as the paragraph starting "Note: The value..." effectively points out. Part of the reason for this is that the Precis-Framework, having started out to provide a foundation for profiling (as Stringprep does), then entangles that foundation with two specific profiles for which some of these derived properties are then produced/ used. If the IETF still considers comprehensibility to be an important attribute of standards track protocol specs and also takes Sections 1-7 of this document seriously, it is likely that this section should at least contain intuitive explanations of what each of the property categories is about or, depending on the actual profile model (see (2) above), perhaps this section and much of either Section 3 and/or 4 should be removed, letting profile documents be defined in terms of whatever really counts. An examination of the profile-defining subsections of draft-ietf-precis-saslprepbis-07 sheds some light on these issues, but does not constitute a normative definition. Those definitions could clearly be written differently depending on resolution of the issues above. Observation: Most of the questions raised above are fundamental design issues with the direction of PRECIS and the protocol framework described in the relevant document. That the answers to most of them are unclear to someone with a reasonable claim to at least a modicum of understanding of i18n issues and general protocol design principles who has read the last few versions of the I-D very carefully is not encouraging. More important, it supports the key to my Last Call comments: these are both unresolved and unidentified-in-the-document known defects inconsistent with approval as a Proposed Standard in its current form and evidence of lack of careful and adequately competent review in both the WG and the IESG. I believe that most of those who approved this document (even by silence or IESG "no objection" votes) who do not immediately understand the questions above and their answers should withdraw those votes. There are also a collection of nit-level issues, including the introduction of new and bogus terminology, and rather subtle Unicode and i18n problems that reinforce the conclusion about inadequate review in the WG or by people with adequate expertise in the subject matter. For a variety of reasons (already discussed with the relevant AD), these comments come very late and that is unfortunate. However, unless the IETF is now changing its rules so that simple lack of well-documented objections to a proposal is interpreted as IETF Consensus, the primary issue with the approval of this document is insufficient and inadequate review: the problems identified above (and the additional more minor ones that I'll provide if anyone is interested) may be useful for fixing the draft but are simply examples of those "inadequate review" and, now, "known technical defects" issues. john _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
