Re: [art] [I18ndir] Modern Network Unicode

John C Klensin <john-ietf@jck.com> Fri, 12 July 2019 02:36 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1FA12004D; Thu, 11 Jul 2019 19:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 LRQ2w0Au1CRY; Thu, 11 Jul 2019 19:36:37 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D0912001E; Thu, 11 Jul 2019 19:36:36 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hllQH-0000Yk-Pj; Thu, 11 Jul 2019 22:36:33 -0400
Date: Thu, 11 Jul 2019 22:36:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>, Ira McDonald <blueroofmusic@gmail.com>
cc: art@ietf.org, "Asmus Freytag (c)" <asmusf@ix.netcom.com>, i18ndir@ietf.org
Message-ID: <3A4F6E9D943A8ECC0108A468@PSB>
In-Reply-To: <0C841343-CD67-40A2-9C37-F5EB5B9DFF8C@tzi.org>
References: <0A5251342D480BA6437F7549@PSB> <B243365E-F7C5-4C53-A64F-2E3E87C4CD66@tzi.org> <248A8DD5DA0D3D34D6B6EFC9@PSB> <213ae024-b819-4f56-6e37-0cd53eb566c9@ix.netcom.com> <D921117F-BA9E-430B-8287-06D15248E1B7@tzi.org> <90f8f2b5-ff3d-f9f1-860c-ae4d43f92c81@ix.netcom.com> <7F1F41C25D0AC5960D95A67E@PSB> <C7BBF677-E752-4258-A357-AE56338F6326@tzi.org> <DFB116527FF004C961182B15@PSB> <CAN40gStf08EwxiZ0+JUa02MLykQPEaL52quK-t9qc-Q8ALxT5A@mail.gmail.com> <0C841343-CD67-40A2-9C37-F5EB5B9DFF8C@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/7Ob-GVVZUp0rDR9T8Ukrk15wINM>
Subject: Re: [art] [I18ndir] Modern Network Unicode
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 02:36:39 -0000


--On Friday, July 12, 2019 01:46 +0200 Carsten Bormann
<cabo@tzi.org> wrote:

> This is a great discussion.
> 
> To me, it seems to converge on the following.
> 
> (1) Sending sane data is the job of the data originator.  
> 
> (2) Do not include gratuitous normalization steps in your
> processing, once the data have been originated in a sane form.
> 
> (2a) If you broke it, you fix it (as far as possible): If your
> processing steps did involve gratuitous normalization, you
> have to renormalize to NFC before sending.
> 
> Here, "sane" is defined as:
> 
> (0) Data SHOULD be originated in NFC, unless that would be
> inappropriate for the specific script, in which case the
> community consensus rules for the script govern.
> 
> For Latin script, this happens to collapse to what 5198 says.
> 
> This set of rules places the onus on the place where the data
> is generated, which is usually the place that knows most about
> the specific script and about the intent of the originator.
> If you know that place isn't doing its job, add the rule:
> 
> (1a) If the data originator does not do (0), the software
> placing the data on the network may need to sanitize
> (normalize towards sane).
> 
> 1a is similar to 2a in that it doesn't create perfect
> results, so both SHOULD be avoided — there is no way to,
> after the fact, perfectly sanitize data that weren't
> originated sane or that were gratuitously normalized on the
> way.
> 
> With these definitions, MNU can direct towards: 
> (A) Senders: send sane data
> (B) Recipients: break as little as reasonable when data
> received isn't sane 
> (C) B is not a valid excuse not to do A,
> and specifically: recipients are not expected to clean up
> after senders (because there is no correct way to do that).
> 
> (Rule C is the often forgotten third rule of the Postel
> principle. It also means that an entity that is a recipient of
> MNU and then sends the data on as MNU has no need to
> gratuitously normalize, but it does not entirely get rid of
> rule 1a for recipients of data from places known not to be
> sane.)

I think this is exactly right.  And, fwiw, I agree with your
observation about the Postel principle.

   john