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

Sam Whited <sam@samwhited.com> Wed, 23 December 2015 15:10 UTC

Return-Path: <sam@samwhited.com>
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 B147E1A01C6 for <precis@ietfa.amsl.com>; Wed, 23 Dec 2015 07:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 UUJs-3g6mAvZ for <precis@ietfa.amsl.com>; Wed, 23 Dec 2015 07:10:32 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA021A01D5 for <precis@ietf.org>; Wed, 23 Dec 2015 07:10:32 -0800 (PST)
Received: by mail-qg0-x22a.google.com with SMTP id o11so78630638qge.2 for <precis@ietf.org>; Wed, 23 Dec 2015 07:10:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=d16xqHlBa6s6g0hsO9XuPPar6A8M6vGedZtcd5Qr7LM=; b=Yzpy4oPlnT/mv3egaXu4GZfwqolRD0UgcLZNImfXf1SuH1t0AuTgsQfOlXguKvCqkf XuVutPixlr8nwXy6hrOF5AL6Tq87ooc1YzAmv7wpqVwsO0JjPw3CJmze0/1gVDawrZDa x5ahdhHDYd1XC0mmQILsEwOjttIFZ9Q0k2TAs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=d16xqHlBa6s6g0hsO9XuPPar6A8M6vGedZtcd5Qr7LM=; b=QPyyM0G7yT3Spxsw2jzAuja2RiAGgmrWhKrtLOVc07lGeWrdmCLFPKifVrqpfnva+8 NdlFZoyKZy8VzM4lzuySB/cG/fKypQwnxtv+kFL2AcLjwl939LSSAs8sfeTE4tMmvazM fuz3jS1zubWBODczewKCkuHxdizbMB/hfkA4Siy4dnWHBCFbZeGZuunjHo8r3CdGVZBT tJHt6pI4fGntoIJKvhynTaP86YYAgskrJTj8sgaA+jFtpP9zU2+mQxjGL6YcYGTRBLtR eTfFQZrwNWZmngGzeZbGxowwyM63k6Ci6LBrrPxvk2hKAXdPPE0EQGe2flAgNneSbIbS 7gIQ==
X-Gm-Message-State: ALoCoQmnOPYLkesKJamywaYqce1Yp+Si+nHOAgDYpi6SydvFU7TutBIP+z+wB7f71WPBQFUd/n4fw+b+M7YKDEyAG+ZJKlIZNA==
X-Received: by 10.140.22.212 with SMTP id 78mr40442047qgn.17.1450883431388; Wed, 23 Dec 2015 07:10:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.10.133 with HTTP; Wed, 23 Dec 2015 07:09:51 -0800 (PST)
X-Originating-IP: [72.48.156.244]
In-Reply-To: <20151223045826.9CED018000D@rfc-editor.org>
References: <20151223045826.9CED018000D@rfc-editor.org>
From: Sam Whited <sam@samwhited.com>
Date: Wed, 23 Dec 2015 09:09:51 -0600
Message-ID: <CAHbk4RLjrAdz1PgZ=fNH9ZeRkfDb2QeQxt_Udcek198ndp1Qcg@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/51xyNpjQBICYcYPmjkhwHux-pzI>
Cc: alissa@cooperw.in, Peter Saint-Andre <peter@andyet.com>, precis@ietf.org, barryleiba@computer.org
Subject: Re: [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 15:10:33 -0000

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

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
>



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com