Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
draft-ietf-precis-7700bis-10

[Ballot comment]
I like the clear explanation of some of the design choices in here (e.g., the rationale for using NFKC).

There are two places that I think a slight bit of additional text might be useful:

1. When talking about processing "each string" in section 2.4, it's probably worth noting that implementations should be careful not to assume that any information received from a wire protocol has necessarily had any of the rules in this document applied to it (as this might allow intentionally noncompliant clients to slip certain kinds of shenanigans past their checks); and

2. Where the final paragraph of section 4 indicates that the operations in this document are not necessarily idempotent, it is probably worth being more explicit that they should be applied repeatedly until the output string is stable; or, if the string does not stabilize after a reasonable number of iterations (is this possible?), that it should be rejected as invalid.

[Ballot comment]
This is wildly outside my area of expertise -- about the only thing I know about PRECIS, Unicode, internationalization and similar is that it is tricky and subtle.
I'm balloting No Objection with the belief that the author and AD understand this stuff :-)

I would like to point out the OpsDir review from Nevil: https://datatracker.ietf.org/doc/review-ietf-precis-7700bis-07-opsdir-lc-brownlee-2017-06-19/ (which, I see, you have already responded to).

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

The IANA Services Operator has completed its review of draft-ietf-precis-7700bis-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 7700 when approved.

In the PRECIS Profiles registry on the Preparation and Comparison of Internationalized Strings (PRECIS) Parameters registry page there is an existing entry for Nickname that was created by RFC7700.

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

IANA Question -> should the reference for Nickname in PRECIS Profiles be updated to point to [ RFC-to-be ] instead of RFC7700?

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: draft-ietf-precis-7700bis@ietf.org, Marc Blanchet , precis@ietf.org, Marc.Blanchet@viagenie.ca, precis-chairs@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames) to Proposed Standard


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following
document:
- 'Preparation, Enforcement, and Comparison of Internationalized Strings
  Representing Nicknames'
  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


  This document describes methods for handling Unicode strings
  representing memorable, human-friendly names (called "nicknames",
  "display names", or "petnames") for people, devices, accounts,
  websites, and other entities.  This document obsoletes RFC 7700.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/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 Precis profile for nickname, essentially clarifies the original specification and make it synchronized with the revised base spec, specially regarding case mapping.

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 original profile specification, there was no real contention on the document. A discussion happened on a desirable property of being idempotent, but the discussion went that this is a desirable property, not an absolute requirment.

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

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 Precis profile for nickname, essentially clarifies the original specification and make it synchronized with the revised base spec, specially regarding case mapping.

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 original profile specification, there was no real contention on the document. A discussion happened on a desirable property of being idempotent, but the discussion went that this is a desirable property, not an absolute requirment.

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