On 12/23/15 8:09 AM, Sam Whited wrote:
Hi all,

After submitting this yesterday I had a discussion with Christian
Schudt about it and he pointed out that you probably want to be able
to display the text output by the enforce operation, and therefore
this was most likely a deliberate change. With that in mind, I'd like
to ammend my suggestions somewhat:

The directionality rule should still be removed from the list of rules
in section 2.3 as well as the list in section 2.4 (there is no
directionality rule, so having it in the order of operations is just
confusing), and section 2 item 3 should be updated to clarify that
Unicode default case folding only needs to be applied during the
comparison step (right now it states that it "MUST be applied" which
is ambiguous since it doesn't list what step (or steps) need to apply
it and makes it seem like it should be part of the enforcement step).

Agreed. I plan to add the following text:

Section 2.1

OLD

   3.  Case Mapping Rule: Apply Unicode Default Case Folding, as defined
       in the Unicode Standard [Unicode] (at the time of this writing,
       the algorithm is specified in Chapter 3 of [Unicode7.0]).  In
       applications that prohibit conflicting nicknames, this rule helps
       to reduce the possibility of confusion by ensuring that nicknames
       differing only by case (e.g., "stpeter" vs. "StPeter") would not
       be presented to a human user at the same time.

NEW

   3.  Case Mapping Rule: Apply Unicode Default Case Folding, as defined
       in the Unicode Standard [Unicode] (at the time of this writing,
       the algorithm is specified in Chapter 3 of [Unicode7.0]).  In
       applications that prohibit conflicting nicknames, this rule helps
       to reduce the possibility of confusion by ensuring that nicknames
       differing only by case (e.g., "stpeter" vs. "StPeter") would not
       be presented to a human user at the same time.  (As explained
       below, this is typically appropriate only for comparison, not for
       enforcement.)

Section 2.3

OLD

   1.  Additional Mapping Rule
   2.  Normalization Rule
   3.  Normalization Rule

NEW

   1.  Additional Mapping Rule
   2.  Normalization Rule

   Note: An entity SHOULD NOT apply the Case Mapping Rule during
   enforcement, because typically it is appropriate only during
   comparison.

Peter


Best,
Sam


On Tue, Dec 22, 2015 at 10:58 PM, RFC Errata System
<[email protected]> wrote:
The following errata report has been submitted for RFC7700,
"Preparation, Enforcement, and Comparison of Internationalized Strings Representing 
Nicknames".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7700&eid=4570

--------------------------------------
Type: Technical
Reported by: Sam Whited <[email protected]>

Section: 2.3

Original Text
-------------
An entity that performs enforcement according to this profile MUST
   prepare a string as described in Section 2.2 and MUST also apply the
   following rules specified in Section 2.1 in the order shown:

   1.  Additional Mapping Rule
   2.  Normalization Rule
   3.  Directionality Rule

   After all of the foregoing rules have been enforced, the entity MUST
   ensure that the nickname is not zero bytes in length (this is done
   after enforcing the rules to prevent applications from mistakenly
   omitting a nickname entirely, because when internationalized
   characters are accepted, a non-empty sequence of characters can
   result in a zero-length nickname after canonicalization).


Corrected Text
--------------
An entity that performs enforcement according to this profile MUST
   prepare a string as described in Section 2.2 and MUST also apply the
   following rules specified in Section 2.1 in the order shown:

   1.  Additional Mapping Rule
   2.  Case Mapping Rule
   3.  Normalization Rule

   After all of the foregoing rules have been enforced, the entity MUST
   ensure that the nickname is not zero bytes in length (this is done
   after enforcing the rules to prevent applications from mistakenly
   omitting a nickname entirely, because when internationalized
   characters are accepted, a non-empty sequence of characters can
   result in a zero-length nickname after canonicalization).


Notes
-----
There is no directionality rule to be applied during enforcement as the 
directionality rule is part of NFKC, the case mapping rule (as mentioned in 
section 2.1).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7700 (draft-ietf-precis-nickname-19)
--------------------------------------
Title               : Preparation, Enforcement, and Comparison of 
Internationalized Strings Representing Nicknames
Publication Date    : December 2015
Author(s)           : P. Saint-Andre
Category            : PROPOSED STANDARD
Source              : Preparation and Comparison of Internationalized Strings
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG





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

Reply via email to