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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 04 May 2016 15:07 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1412D6E9 for <precis@ietfa.amsl.com>; Wed, 4 May 2016 08:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Rl6LKCduLOk8 for <precis@ietfa.amsl.com>; Wed, 4 May 2016 08:07:19 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2A12D6CD for <precis@ietf.org>; Wed, 4 May 2016 08:06:29 -0700 (PDT)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B79A640014; Wed, 4 May 2016 09:16:05 -0600 (MDT)
To: Sam Whited <sam@samwhited.com>, RFC Errata System <rfc-editor@rfc-editor.org>
References: <20151223045826.9CED018000D@rfc-editor.org> <CAHbk4RLjrAdz1PgZ=fNH9ZeRkfDb2QeQxt_Udcek198ndp1Qcg@mail.gmail.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <572A0FF3.8040707@stpeter.im>
Date: Wed, 04 May 2016 09:06:27 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAHbk4RLjrAdz1PgZ=fNH9ZeRkfDb2QeQxt_Udcek198ndp1Qcg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/x9tVZc9JTU7CgXr-XNyciXE2db0>
Cc: alissa@cooperw.in, precis@ietf.org, barryleiba@computer.org
Subject: Re: [precis] [Technical Errata Reported] RFC7700 (4570)
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.17
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, 04 May 2016 15:07:26 -0000

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),

Agreed.

> 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).

IMHO it would be best if the definitions of the rules do not contain 
normative keywords, e.g., "the mapping rule is to apply Unicode Default 
Case Folding" or "the normalization rule is to apply Unicode 
Normalization Form KC" or whatever.

This change will be reflected in the next version of 7700bis and 7613bis.

Peter

>
> Best,
> Sam
>
>
> On Tue, Dec 22, 2015 at 10:58 PM, RFC Errata System
> <rfc-editor@rfc-editor.org> 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 <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
>>
>
>
>