IETF Logo Mail Archive

[precis] [Technical Errata Reported] RFC7700 (4570)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 23 December 2015 04:58 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98D41AC3F5 for <precis@ietfa.amsl.com>; Tue, 22 Dec 2015 20:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.912
X-Spam-Level:
X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odSyUKnA_2hk for <precis@ietfa.amsl.com>; Tue, 22 Dec 2015 20:58:38 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 475D31AC3F2 for <precis@ietf.org>; Tue, 22 Dec 2015 20:58:38 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 9CED018000D; Tue, 22 Dec 2015 20:58:26 -0800 (PST)
To: peter@andyet.com, ben@nostrum.com, alissa@cooperw.in, barryleiba@computer.org, Marc.Blanchet@viagenie.ca, alexey.melnikov@isode.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20151223045826.9CED018000D@rfc-editor.org>
Date: Tue, 22 Dec 2015 20:58:26 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/3XGFNy-2wrq17ElE8L7knhraAIA>
Cc: precis@ietf.org, rfc-editor@rfc-editor.org
Subject: [precis] [Technical Errata Reported] RFC7700 (4570)
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2015 04:58:39 -0000

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 <sam@samwhited.com>

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

v2.23.0 | Report a Bug | By Email