Subject: [precis] Last Call: <draft-ietf-precis-framework-15.txt> (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 09 Apr 2014 12:07:44 -0700

The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'PRECIS Framework: Preparation and Comparison of Internationalized
   Strings in Application Protocols'
  <draft-ietf-precis-framework-15.txt> as 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
[email-masked] mailing lists by 2014-04-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Application protocols using Unicode characters in protocol strings
   need to properly prepare such strings in order to perform valid
   comparison operations (e.g., for purposes of authentication or
   authorization).  This document defines a framework enabling
   application protocols to perform the preparation and comparison of
   internationalized strings ("PRECIS") in a way that depends on the
   properties of Unicode characters and thus is agile with respect to
   versions of Unicode.  As a result, this framework provides a more
   sustainable approach to the handling of internationalized strings
   than the previous framework, known as Stringprep (RFC 3454).  This
   document obsoletes RFC 3454.

This document makes a normative reference to RFC 20, which
predates document statuses and therefore may be a downward
reference.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Apr 2014 00:17:52 -0400

--On Wednesday, April 09, 2014 12:07 -0700 The IESG
<[email-masked]> wrote:

> The IESG has received a request from the Preparation and
> Comparison of Internationalized Strings WG (precis) to
> consider the following document: - 'PRECIS Framework:
> Preparation and Comparison of Internationalized    Strings in
> Application Protocols'
> 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 [email-masked] mailing lists by
> 2014-04-23.

IESG,

I have deliberately waited until the end of the Last Call period
as posted [1], hoping that you would get (or generate) more
focused comments on the draft in the interim.  The issues
discussed in this note were raised while what became the PRECIS
WG (originally known by names like "Stringprep-bis") was being
discussed and chartered and again on several occasions during
the meetings of the WG.   At least in my opinion, they were
never discussed seriously: the WG made one important improvement
(shifting to a rule-based inclusion approach) but has
essentially ignored the fundamental problem.  Because the
predecessors of this note have not been actively considered in
the WG or while its charter was being created, I don't actually
expect it to accomplish anything other than to get some issues
on the record.  But I think the circumstances require one last
try.

This note consists of a high-level summary with details in
footnotes on its various points.  It is as short as I cam make
it without leaving out issues and explanations that I believe
are important.

Summary:

I see fundamental problems with approval of this specification
and some issues with the decisions it includes.  The first of
these is temporary; the second more fundamental.  

(1) After the PRECIS WG task list settled down into its charter
[2], the goal became, in essence, to replace Stringprep with
something more explicitly rule-based and to update (or advise
on) the various uses of Stringprep profiles.  As described in
the PRECIS charter, that approach noted the relationships among
the various parts of the PRECIS work and called for handling the
"framework, profile replacements, and guidelines ... in parallel
as much as possible".  The interrelated nature of the pieces
makes it inappropriate for the IESG to approve the "framework"
document for publication on the standards track at this time
because doing so would foreclose some reasonable discussion of
issues with the other specs -- exactly the situation the charter
language was intended, at least in my recollection, to prevent.
The approval and publication of RFC 6885 over a year ago has
already been used that way.

Some of the decisions reflected in the current draft
illustration why more testing against specific profile examples
and guidelines is important [5].

Recommendation: Tentatively approve the document now if that
seems otherwise justified (I suggest below that it is not) but
do not issue a Protocol Action Notice or handoff to the RFC
Editor until after a sufficient number of of "profile
replacements" and "guidelines" have been completed and examined
through the IETF Last Call process to validate the "framework"
provisions.  The analogy of such a request to "running code"
requirements should be obvious.

(2) The longer-term problem is the one that PRECIS simply
refused to address.  When designing systems with direct effects
on and interactions with users, predictability based on prior
user experience and expectations is vital.  That predictability
is often expressed as the Law of Least Astonishment.  In the
case of use of non-ASCII characters in Internet applications,
"least astonishment" implies, first, that rules should be
intuitive and easily understood to the extent possible.  Second
and more important, if a user understands the rules of one
application, she should be able to accurately extrapolate from
that application to others.  If there is a reason why that
extrapolation does not work, the reasons should be clearly
expressed and sufficiently comprehensible to be easily
incorporated into the user's cognitive framework... and there
should be few such cases.

With the addition of "IdentifierClass" and "FreeformClass" to
what, in its language, might be called "IDNA2008Class", we
already have between one and two "Classes" too many for good
user predictability.  The language that indicates that
additional classes might be defined in future specifications is
not nearly strong enough in discouraging additional classes and
explaining the reasons why.

The PRECIS framework appears to fail those tests.  It can be
read as actively encouraging multiple profiles [3].  This is
true even though the third bullet under "It is expected that
this framework will yield..." explicitly acknowledges "more
accurate expectations about the characters that are acceptable
in various contexts" as an explicit objective.

Recommendation: Hold this document until the various categories
are exercised by at least a sampling of applicable profiles.
Make the problems with excessive profiles explicit; impose
requirements on additional profiles that include an explanation
of why they are needed given the user-level interoperability and
astonishment problems that can result from even three of them
and require a higher level of review and consensus for creating
new ones than "expert review".  Modify the Security
Considerations section to identify user astonishment and
consequent confusion about what rules are being applied in a
given PRECIS-User protocol as a risk and possible attack vector.

thanks,
    john

  -----------------------------

[1] Despite the apparently-automatic announcement dated April
23, 2014 00:07 -0700 and indicating that the last call period
had ended and the document state changed, the announcement,
quoted above, says "by 2014-04-23".  To the best of my
knowledge, there has never been an announcement to the
community, much less one backed by community discussion and
consensus, that "by <date>" now means "00:07 California time on
that date".  If anything, we have tended to interpret "by
<date>" as COB on that date or the last minute of that date
anywhere in the world.

[2] http://datatracker.ietf.org/wg/precis/charter/

[3] Not only should multiple profiles be discouraged for this
type of case by the Law of Least Astonishment, but general IETF
experience indicates that profiles are a bad idea and that
protocols that depend on them (and use a significant variety)
tend to be less successful than those that do not.  

[4] Sections 3.2.2 and 3.3.2 of -15.

[5] There are issues with the two classes that are defined in
this document that have not, I believe, been carefully addressed
in the WG.  At a minimum, they need to be considered more
carefully in context with specific examples without preempting
the choices to be made for those examples.  The following are
examples, not an exclusive list:

(i) The "Contextual Rule" categories of IDNA2008 have proven to
be extremely problematic, confusing, and controversial enough to
be one of the key issues in the UTR 46 battles that have impeded
IDNA2008 adoption in some important communities.  While I still
believe that the IDNA2008 decision was the right one, inclusion
of those characters as Valid for both classes [4] should, given
those bad experiences, require significantly more explanation
and/or justification than this draft appears to provide.  If the
intent of incorporating this list in PRECIS is to provide for
compatibility with IDNA2008, the list should be incorporated by
reference (either to RFC 5892 and its successors or to a
separate documents that updates and replaces the list in RFC
5892 as well as being used for PRECIS),  not be provided as a
list of code points that could cause the two definitions to
diverge if changes are made to one or the other.  The issue may
apply more generally to the other characters listed in Section
7.6 and to other IDNA-derived elements of Section 7.

(ii) Characters with compatibility equivalents are problematic,
in large measure because of a Unicode issue that has been
extensively discussed in the past.  Basically the compatibility
equivalency category mixes several unrelated and incompatible
(sic) groups of things under a single label.  One extreme is
occupied by characters used with East Asian scripts that are
distinguished only by their widths.  If the Unicode design
principles of "characters, not glyphs" and "plain text" had been
followed, these different-width variations would never have been
assigned different code points.  As a contrasting example, the
relevance of, and distinctions among, special mathematical code
points distinguished by mathematical use and specific type
styles is less clear: treating them as separate characters may
be justified under some circumstances.  A more extreme example
occurs with some Chinese characters that Unicode treats as
compatibility equivalents for other characters.  That treatment
is usually (and perhaps always) appropriate when the "meaning"
of the characters is intended.  But some of those characters
are, or historically have been, used in personal names.  To the
extent to which those names are used as identifiers, e.g., for a
person thus named, treating them as invalid is inappropriate and
applying a compatibility mapping to them only slightly less bad.

(iii) Experience with IDNA strongly suggests that
"DefaultIgnorable" is a bad idea.  Forbidding some (or perhaps
all) of these characters may be reasonable; treating them as if
they were not present impedes possibly-reasonable future
extensions and provides an attack vector for phishing and other
types of unpleasant behavior that do not appear to be called out
in Security Considerations.  It is also worth noting that one
difference between IDNA2008 and this specification is that the
former is not profiled (except by registries providing their own
subsetting rules) while the latter is intended as a base for
profiling.  While the order in which categorization rules is
applied in Section 8 provides some protection (perhaps
sufficient protection if the spec is never updated or used as
the basis for a different profile), it is worth noting that some
code points appear in more than one category (e.g., the
notorious ZWJ and ZWNJ in both JoinControl (Section 7.8) and
PrecisIgnorableProperties (Section 7.13)) and that this should
at least be called out explicitly.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Apr 2014 09:46:27 -0600

On 4/23/14, 10:17 PM, John C Klensin wrote:
> focused comments on the draft in the interim.

John, that seems like an exceedingly unrealistic hope. You know better 
than anyone that internationalization expertise is spread very thinly in 
the IETF (and elsewhere). Folks from the IETF community who care about 
i18n are already likely to have provided feedback on the PRECIS 
documents. We just don't have very many such people.

> The issues

Ignored might be a bit strong. Perhaps those active in the WG did not 
see a way to achieve the high goal you have set here. Throwing up our 
hands and doing nothing (and thus remaining stuck on Stringprep and 
Unicode 3.2) seems like it would have been a worse outcome.

> and guidelines is important [5].

We have 5 profiles in a quite advanced state, specified in 3 I-Ds 
(draft-ietf-precis-saslprepbis, draft-ietf-

> requirements should be obvious.

IMHO we are close to having that running code, but we haven't pushed all 
the documents forward at exactly the same time.

> refused to address.

It's a hard problem. Refused might be a bit strong.

> When designing systems with direct effects

That sounds ideal, but unfortunately we are dealing with a quite messy 
reality in which we have many different kinds of identifiers - domain 
names, email addresses, file names, chatrooms, IM handles, nicknames, 
etc. Reducing them all to one thing seems unrealistic to me. I would 
love to achieve that, but I don't see it happening anytime soon.

> read as actively encouraging multiple profiles [3].

Because we have a world with multiple identifiers.

> This is

See above. We have 5 profiles very close to done.

Also: hold in what sense?

These documents are going forward to Proposed Standard. IMHO we need 
further experience with them, in the field, and possible revision in the 
future. But we have a stronger basis for that now (with PRECIS) than we 
ever would have had with Stringprep.

I think the WG realizes that PRECIS is not perfect as it is. I doubt 
that perfection can be achieved in the messy domain of i18n, though.

> given PRECIS-User protocol as a risk and possible attack vector.

Those do seem like good things.

I am out of time right now to reply to the topics from your footnotes.

Peter

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 24 Apr 2014 12:40:44 -0500

John,

Peter has had a start on answering these meat of the issues, and unless 
there are objections (by you, or anyone else), I'd ask that the 
remainder of the technical discussion be taken to the precis mailing 
list alone. That said, a couple process points that I think are 
appropriate to discuss here:

> focused comments on the draft in the interim.

Please don't do that in the future. In this particular case (and mea 
culpa for this), I completely missed this note before the IESG telechat 
started, and wish we could have had this discussion going before the 
IESG got the document. In the end, the outcome is as per your first 
recommendation anyway:

> provisions.

The IESG tentatively approved the document today, but it's announcement 
is contingent on a final review by me and a writeup. (In the 
datatracker, you'll see this recorded as "Approved::Point Raised".) I 
was going to do that anyway to deal with other comments that came up 
during AD Evaluation and Last Call, but I'll take your comments into 
account as well. If we end up in a place where I think we need to bring 
it back to the IESG, I can always do that.

> on the record.  But I think the circumstances require one last

As much as we've failed in many ways to keep the spirit of our 
procedures alive, they do still exist. The IETF is *not* supposed to be 
another of the "formal review" SDOs where nothing happens until formal 
last calls and final reviews. We are supposed to be running a process 
where consensus is *built* during document creation, and importantly 
where failures are identified early and throughout the process, not 
late. Part of the way the IETF operates is that we *don't* wait until 
it's a big formal deal to address problems. Part of the social contract 
is that participants take responsibility for that and make their 
concerns known while consensus building is still going on. We talk a lot 
in the IESG about how to push things back earlier in the process, to not 
have late surprises and to not rely on things like formal DISCUSSes of 
the IESG for getting good work out of the IETF. Participants have to be 
part of that as well and use the tools we have to make sure that our 
process operates effectively.

RFC 2026, Section 6.5.1, defines what to do if a participant's views 
have not been adequately considered by the Working Group or that the 
Working Group has made an incorrect technical choice. In particular, the 
first step is to approach the chairs directly, at which point the chairs 
are supposed to figure out how to resolve the matter, bringing in other 
members of the WG (or the WG as a whole) when needed. If that doesn't 
work, *then* you bring that concern to the AD to attempt to resolve. 
(And of course, after that you can appeal to the IESG.)

The PRECIS WG has been discussing this document for round about three 
years. The WG made the decision to send this document to the IESG two 
months ago. I do not know whether you discussed this matter directly 
with the chairs, but I know that you have not discussed it directly with 
me. If you hadn't come to the conclusion that things had gone off the 
rails until recently, there's not much that you could have done 
differently, but my sense from your message is that you have had this 
concern for quite some time and that the WG has been missing it. 
(Indeed, I have been following PRECIS better than some of my WGs, and I 
know I've been in the room at f2f sessions, and *I* missed that you had 
this concern.)

This concern should have been escalated long ago. You should have 
followed 2026/6.5.1 and brought this to the chairs, and then to me as 
the AD if you weren't getting heard. The IETF only works when all 
participants take the responsibility to raise concerns during the 
process. If the senior members of the community aren't going to take 
that responsibility, why are we surprised when people are discouraged 
about how our processes work?

As I said, I'll review these concerns, and I'll take the document back 
to the IESG (or even the WG) if that is warranted. But this isn't the 
way the process is supposed to work.

Disappointedly,

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478