Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)
draft-ietf-precis-mappings-12

[Ballot comment]
opsdir review was performed by   

Mahesh Jethanandani

who notes a significant number of  nits in draft 11 so you'll want to look at it through the tool

[Ballot comment]
I don't have substantive comments, but I do have a fair number of editorial comments. There are a number of places where I found the sentence structure very hard to follow. I apologize for not suggesting text, but for the most part I was not sure of the intent. Details follow:

-2.3, first paragraph, note:
I'm having trouble parsing that sentence, starting with "Because".

-2.3, 3rd paragraph:
s/"... Case Folding in PRECIS framework..."/"... Case Folding in the PRECIS framework..."

"Local case mapping defined in this document corresponds to demands from applications which supports  users’ locale and/or context."
I don't follow the sentence.

-2.3, 2nd to last paragraph:
I suggest avoiding 2119 keywords when referring to requirements from other specs-- especially since _this_ draft doesn't have the 2119 boilerplate.

-2.3, last paragraph:
I can't parse the paragraph.

-- 6:
I don't understand the meaning of "need for the case folding about the mapping"

-- Appendix B:
I'm having a lot of trouble following the sentence structure for the whole section.

[Ballot comment]

- The write-up didn't tell me if this is likely to be
considered as neutral by the Unicode folks, or as
something non-neutral. I'm curious about that, but not
concerned much. I do think the IESG should be aware
though if this is something that might cause e.g.
liaison fun for the IAB later on.  (I'm not saying I
think it does/would btw, just that I'd like to know if
it might.)

- The secdir review [1] raised an issue and some
changes were proposed for a -12 version that hasn't
yet popped out (which is fine). This is just to note
that to decrease the probability we forget:-)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05900.html

[Ballot comment]
Just a small nit.

Section 2.3. (Local case mapping) includes the phrase "It is RECOMMENDED to use…”, which looks like an RFC2119 keyword, but that RFC is not referenced in the document.  The phrase is used to refer to what is specified in RFC7564..but it may confusing.  Maybe using quotation marks to make it clear that the text comes form somewhere else, and using a reference would help.

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

IANA has reviewed draft-ietf-precis-mappings-11, which is currently in Last Call, and has the following comments:

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

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment isn't accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Mapping characters for PRECIS classes) to Informational RFC


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'Mapping characters for PRECIS classes'
  as Informational RFC

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 2015-08-04. 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

  The framework for preparation, enforcement, and comparison of
  internationalized strings ("PRECIS") defines several classes of
  strings for use in application protocols.  Because many protocols
  perform case-sensitive or case-insensitive string comparison, it
  necessary to define methods for case mapping.  In addition, both the
  Internationalized Domain Names in Applications (IDNA) and the PRECIS
  problem statement describe mappings for internationalized strings
  that are not limited to case, but include width mapping and mapping
  of delimiters and other special characters that can be taken into
  consideration.  This document provides guidelines for designers of
  PRECIS profiles and describes several mappings that can be applied
  between receiving user input and passing permitted code points to
  internationalized protocols.  In particular, this document describes
  both locale-dependent and context-depending case mappings as well as
  additional mappings for delimiters and special characters.


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

IESG discussion, once it begins, can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ballot/

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

Shepherd writeup for draft-ietf-precis-mappings-11

1. Summary

The document shepherd is Peter Saint-Andre.

The responsible Area Director is Barry Leiba.

This document provides guidelines for supplemental and alternative
handling of some Unicode characters in the context of PRECIS (RFC 7564).
The supplemental handling covers mapping of protocol-specific delimiters
(e.g., "@") and special characters (e.g., mapping of non-ASCII space to
ASCII space). The alternative handling covers language-specific mapping
of uppercase characters to lowercase characters (e.g., Turkish dotless
i) as an alternative to Unicode Default Case Folding, along with one
instance of context-specific mapping (Greek final sigma).

The requested publication type is Informational because the document
provides non-normative guidance for protocol designers and application
developers.

2. Review and Consensus

Internationalization is full of messy complexity. The topic of case
mapping, although it might seem straightforward to English speakers,
can be far from clear-cut. Mapping of uppercase characters to lowercase
characters sometimes varies by language (e.g., certain characters are
handled differently in Turkish and Lithuanian than they are in other
languages that use the same characters) and by geographical location
(e.g., the French language as written in Canada as opposed to France).
PRECIS-based software implementations do not necessarily have access
to information about a user's language or locale. Furthermore, as a
generalized technology for internationalization, PRECIS does not include
a way to negotiate such parameters.

In the main it is safest to use Unicode Default Case Folding for case
mapping, as defined in the Unicode Standard and as recommended by the
PRECIS framework (RFC 7564). However, where information about a user's
language or locale (or the context in which a particular character is
used) is available, it can make sense for an application protocol or
implementation to adjust its handling of case mapping based on such
information.

Because of the complexities involved, the sense of the PRECIS WG was
that it could not provide normative recommendations for case mapping
beyond those defined in the Unicode Default Case Folding algorithm.
Nevertheless, the working group saw value in providing informational
guidance regarding language-, locale-, and context-dependent mappings.
This is similar to the relationship between the core Internationalized
Domain Names in Applications (IDNA) protocol and the informational
guidance provided in RFC 5895.

In contrast to the topic of case mapping, the guidelines regarding
delimiter mapping and special mapping were uncontroversial and elicited
no significant concern among working group participants.

3. Intellectual Property

Both authors have confirmed that they are not personally aware of any
IPR related to this specification.

4. Other Points

The document makes normative references to the Unicode Standard, but
that is not problematic because such references are common in IETF
documents (and this document is Informational anyway).

This document requests no actions by the IANA, does not require expert
review, and needs no other special handling.