Subject: [precis] Basic issues with framework-17 (was: Re: New Version Notification - draft-ietf-precis-framework-17.txt)

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jun 2014 16:44:16 -0400

(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-masked]> wrote:

> This version attempts to address IESG review as well as
> feedback from John Klensin.
> 
> Peter
> 
> On 5/27/14, 11:22 AM, [email-masked] 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