PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
draft-ietf-precis-7564bis-10

[Ballot discuss]
Section 12.5 contains the following normative statement:

>  Furthermore, because most languages are typically
>  represented by a single script or a small set of scripts, and
>  because most scripts are typically contained in one or more
>  blocks of code points, the software SHOULD warn the user when
>  presenting a string that mixes code points from more than one
>  script or block, or that uses code points outside the normal
>  range of the user's preferred language(s).

This guidance seems broadly unimplementable for any users whose native language uses a non-Latin script. Due in large part to the Internet's ASCII heritage, and combined with the somewhat ubiquitous use of Latin characters for other worldwide purposes (e.g., a quick perusal of Russian- and Chinese-language web sites shows numerous examples of Latin representations for things like stock ticker symbols and metric abbreviations), it seems that the normative requirement to warn when "presenting a string that... uses code points outside the normal range of the user's preferred language(s)" will *either* warn non-Latin-character users almost constantly (if Latin is considered outside the range), or be broadly useless in preventing spoofing (if it is).

I'm not clever enough to come up with a generalized solution for users of all alphabets, so don't have a generic proposal here; but I think that the guidance does at least need to be properly scoped so that it bears only on warning Latin alphabet users of the presence of non-Latin characters, while acknowledging that it is probably rather useless when used in the opposite direction. I imagine that it still makes sense to warn non-Latin users of non-Latin characters outside the codepoints used by their language (e.g., warning Greek speakers of the presence of Cyrillic characters).

[Ballot comment]
Thanks Benoit, the diff was helpful.

It seems a bit odd to be doing a -bis for a document ~2 years old, and the draft started <1 year after publication - are we likely to see a -bis of this newly published doc as soon?

[Ballot comment]
Marc Blanchet is the document shepherd. He is also listed as co-editor, but he didn't edit this update to the document. Peter Saint-Andre did all the work.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-precis-7564bis-07.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that this document obsoletes RFC 7564 when approved.

The IANA Services Operator manages the following registries:

- PRECIS Derived Property Value
- PRECIS Base Classes
- PRECIS Profiles

We understand that there is no change to the registries as part of the IANA Considerations of this document.

IANA Question -> should the three registries have their references updated to point to [ RFC-to-be ] instead of RFC7564?

We understand that this document doesn't require any other registry actions.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: Marc Blanchet , precis@ietf.org, Marc.Blanchet@viagenie.ca, draft-ietf-precis-7564bis@ietf.org, precis-chairs@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following
document:
- 'PRECIS Framework: Preparation, Enforcement, and Comparison of
  Internationalized Strings in Application Protocols'
  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
ietf@ietf.org mailing lists by 2017-06-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Application protocols using Unicode code points in protocol strings
  need to properly handle such strings in order to enforce
  internationalization rules for strings placed in various protocol
  slots (such as addresses and identifiers) and 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, enforcement, and
  comparison of internationalized strings ("PRECIS") in a way that
  depends on the properties of Unicode code points and thus is more
  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 7564.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ballot/


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

1. Summary

The document shepherd is Marc Blanchet. The responsible Area Director is Alexey Melnikov.

This document is part of a set of revised RFCs (7564, 7613, 7700), based on implementation experience. 7564 is the base Precis protocol, 7613 and 7700 are profiles for specific use (username/passwords and nicknames respectively).  This revised document, the base Precis protocol, essentially clarifies the original specification, on topics such as case folding, normalization, code points, and rules. The only real modification of the specification is the change from Unicode toCaseFold() operation to toLowerCase().

2. Review and Consensus

Multiple versions of the revised spec was discussed over more than a year in the working group mailing list. As a clarification of the base specification, there was no real contention on the document.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

No change to IANA Precis registries and related policies