From nobody Tue Dec  2 18:45:00 2014
Return-Path: <peter@andyet.net>
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 A26F31A8997 for <precis@ietfa.amsl.com>; Tue,  2 Dec 2014 18:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 7yQ7PszBYsjb for <precis@ietfa.amsl.com>; Tue,  2 Dec 2014 18:44:57 -0800 (PST)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685261A8993 for <precis@ietf.org>; Tue,  2 Dec 2014 18:44:57 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hn15so16147810igb.1 for <precis@ietf.org>; Tue, 02 Dec 2014 18:44:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EZzXksAcecttHyOCnUro2Aq55kspNfqRlWl4BA2o7ac=; b=EX4qmlpSHn2LG3+LumwxQOuPV4ve3RGitFBzLFo8cz7M2G4+UL5VeR806n/1GEomB6 GF0ZguNIYeP+5Lf4MUBuQOQk0wZ+Wz3ojfTeHTc/BbCgHEfwVzUcroKrvzHgsE4AsmL5 WU7yVvxtn1/6K2bLX/9w6wB3Gi2GoVdUz3KgCa7Tdahu0CClKPVxkSHz5EeopTgoG8+i 9RfsUNbu9K/Sy+PQERCbP7F0677Y3ysS1bLxWTjDiemDwBs1vfunO54q9GcFyVkGduqK uBAUWWbFQaTquNRME1scO5OYDCqqAEK7WNvnB3hZDM7vGjPHTUldl8zvav4hyQEFKpft R8Bg==
X-Gm-Message-State: ALoCoQnm9coDgqo3sYP4WtUrY9fEOpMytEzZ+W/mfwK2ktWt085Xb0slqXqP+aLPjm45I4r5PZiR
X-Received: by 10.107.17.79 with SMTP id z76mr2491010ioi.27.1417574696894; Tue, 02 Dec 2014 18:44:56 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o72sm10720641ioo.14.2014.12.02.18.44.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 18:44:56 -0800 (PST)
Message-ID: <547E7927.7030203@andyet.net>
Date: Tue, 02 Dec 2014 19:44:55 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "precis@ietf.org" <precis@ietf.org>,  XMPP Working Group <xmpp@ietf.org>
References: <547BDAA7.2030601@andyet.net>
In-Reply-To: <547BDAA7.2030601@andyet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/qXL4hfw9SLcEBPxtMfa_SEAobI8
Subject: Re: [precis] consolidating FreeformClass profiles?
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 02:44:58 -0000

Seeing no objections, I'm going to make this change.

On 11/30/14, 8:04 PM, Peter Saint-Andre - &yet wrote:
> I think we've done a pretty good job of consolidating some of the
> IdentiferClass profiles, thanks to prodding from John Klensin.
>
> Now I'm wondering if we can prune the list of FreeformClass profiles.
> Currently we have:
>
> Password (draft-ietf-precis-saslprepbis)
> Resourcepart (draft-ietf-xmpp-6122bis)
> Nickname (draft-ietf-precis-nickname)
>
> The Password and Resourcepart profiles are similar: the main differences
> are use of the Bidi Rule and removal of leading and trailing whitespace
> in Resourcepart (the latter is more of a UI consideration and probably
> doesn't belong in the Resourcepart profile in the first place). I think
> we *might* be able to point to the Password profile from 6122bis and
> remove the Resourcepart profile (I'll need to post to the XMPP WG list
> about that). The "Password" name feels a bit strange in this context (I
> might prefer a more generic name like "OpaqueString"), but that's a nit.
>
> The Nickname profile is different enough in purpose and function that I
> think we'll need to keep it.
>
> Peter
>


From nobody Tue Dec  2 19:04:54 2014
Return-Path: <peter@andyet.net>
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 4541A1A88C4 for <precis@ietfa.amsl.com>; Tue,  2 Dec 2014 19:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 TzFd9wWHuljA for <precis@ietfa.amsl.com>; Tue,  2 Dec 2014 19:04:50 -0800 (PST)
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CF81A0032 for <precis@ietf.org>; Tue,  2 Dec 2014 19:04:50 -0800 (PST)
Received: by mail-ig0-f180.google.com with SMTP id h15so12069960igd.7 for <precis@ietf.org>; Tue, 02 Dec 2014 19:04:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1m3XkSyWGcxKxSZ9I+nMOCOYyUuucpItpvhlPKM6dgs=; b=NM4DwYC+fLOsWSQYsUswoo3RM1pIu4FZMysbSiaFT7Lbjf+clzxD5tZykM4jQyxMoS zEDuimFoI1oRYQAHTKgGWYAXJuLVHpDQDa8kuJqCj+Jgse0YBw2rXE61f30qWbKLQhOW ngQs9h9yEKLBvwFA14VcEkpePbQpyAkfGtRV42+/SfbE9kmBTLt1vPTvUrnmV37DFMSs +llzhw9K8Glb3v+wlHcUafZ91V6agv8ii5L9yzhfgfUpW0xhZPek9EOgGH2lvMxyl/Lm l5MlIzEmkWtNH/S+UA75UtFn2cDyeuapTD6XV/RnK31B2K3sF93q7MwQkLAJW05mBcGf lyQQ==
X-Gm-Message-State: ALoCoQksd4lnbpCW6mIBFClzQ7QTxIl7SqiAespnoM2uC47Dk/2EytD1c6aFi72szbxmb+s4Y0Ke
X-Received: by 10.107.170.162 with SMTP id g34mr2802062ioj.2.1417575889953; Tue, 02 Dec 2014 19:04:49 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w8sm12870183igb.7.2014.12.02.19.04.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 19:04:49 -0800 (PST)
Message-ID: <547E7DD0.1090306@andyet.net>
Date: Tue, 02 Dec 2014 20:04:48 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <547695F3.3030106@andyet.net> <47327B22-0591-43C9-A4E5-89F6222F7E82@frobbit.se>
In-Reply-To: <47327B22-0591-43C9-A4E5-89F6222F7E82@frobbit.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Ebd1VzYmE4hvQKWmcHiPWNq7EO8
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 03:04:52 -0000

Hi Patrik,

On 11/26/14, 11:28 PM, Patrik Fältström wrote:
> I intend reading the mapping document today, sorry for the delay but
> $dayjob has been kind of ultra-busy...
>
> Note that most issues I have have to do with clarifications, and that
> it is not clear what the intent is.

Yes, I will reply to your big message next.

> Maybe a few where I urge caution. And they are definitely mapping
> related.

Clarifying question: are you talking about mapping in general (which 
might include width mapping, mapping non-ASCII space characters to ASCII 
space, case mapping, or in some nomenclatures even Unicode 
normalization), or only the kind of locale and context dependent mapping 
that is discussed in draft-ietf-precis-mappings?

> Let me phrase it this way:
>
> One of the problems with IDNA2003 was that it included mapping. It
> was unclear to people whether the client or server did the mapping.
> In reality the only place where mapping could exist for a stable
> protocol/implementation was between application/User Interface and
> where the protocol was really "doing things". So mapping was ripped
> out of IDNA when IDNA2008 was created.

In the PRECIS WG we've had quite a bit of discussion about the dividing 
line between application and protocol, or more precisely between between 
the user interface (which can more easily handle issues of culture, 
context, intent, locale, device limitations, etc.) and the actual use of 
conformant strings in protocol slots.

(Unfortunately, much of our most productive discussion has happened in 
sessions at IETF meetings, not on the list, so it's hard to find pointers.)

> Precis has decided mapping is still part of the protocol definition,

Well, draft-ietf-precis-mappings is only an informative reference from 
draft-ietf-precis-framework and with good reason: we reached the 
conclusion a few IETF meetings ago that we simply couldn't provide 
normative recommendations here.

> and I must understand where more exactly you expect mapping to
> happen, what happens if that mapping is not done, how to expect to do
> matching (comparison) between strings in the over all environment
> where it is possibly unknown whether mapping has been done or not,
> and specifically how it might impact the architecture in the cases
> where the mapping is destructive to the string itself (non-reversible
> mapping).
>
> I do not think it is clear in the framework WHERE mapping is to
> happen.

When you say "WHERE", do you mean (1) when in the process of handling an 
internationalized string or (2) by which entity in a protocol interaction?

I think we have been clear about (1), or at least we've tried to be 
clear - see for example Section 6 of draft-ietf-precis-framework.

I also think that the various profile documents and using protocols have 
been clear about (2) - see for instance Section 4 of 
draft-ietf-xmpp-6122bis.

> Maybe just some ascii art would make things easier to understand?

ASCII art always helps. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Tue Dec  2 19:41:10 2014
Return-Path: <internet-drafts@ietf.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 340561A0070; Tue,  2 Dec 2014 19:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Trmftdc9WFjY; Tue,  2 Dec 2014 19:41:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDAF1A0056; Tue,  2 Dec 2014 19:40:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141203034058.23689.56081.idtracker@ietfa.amsl.com>
Date: Tue, 02 Dec 2014 19:40:58 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/YTBfeEEjF-2NtuBnHWnOqM7Q_cY
Cc: precis@ietf.org
Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-12.txt
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 03:41:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF.

        Title           : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
        Authors         : Peter Saint-Andre
                          Alexey Melnikov
	Filename        : draft-ietf-precis-saslprepbis-12.txt
	Pages           : 21
	Date            : 2014-12-02

Abstract:
   This document describes methods for handling Unicode strings
   representing usernames and passwords.  This document obsoletes RFC
   4013.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Dec  2 21:25:03 2014
Return-Path: <paf@frobbit.se>
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 F21641A008D for <precis@ietfa.amsl.com>; Tue,  2 Dec 2014 21:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level: 
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9ZObLmIOdU69 for <precis@ietfa.amsl.com>; Tue,  2 Dec 2014 21:25:00 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C611A0070 for <precis@ietf.org>; Tue,  2 Dec 2014 21:25:00 -0800 (PST)
Received: from dyn-fg122.sth.netnod.se (dyn-fg122.sth.netnod.se [77.72.226.122]) by mail.frobbit.se (Postfix) with ESMTPSA id 7A67B21955; Wed,  3 Dec 2014 06:24:58 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9D9CB3A1-9FD5-4E9E-B5E2-08E46386FA09"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b3
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <547E7DD0.1090306@andyet.net>
Date: Wed, 3 Dec 2014 06:24:57 +0100
Message-Id: <636EC582-BA21-44B5-B202-DDB4E51FD138@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <547695F3.3030106@andyet.net> <47327B22-0591-43C9-A4E5-89F6222F7E82@frobbit.se> <547E7DD0.1090306@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/awDZLFeMExjq3nBC16EPB9EuqEM
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 05:25:02 -0000

--Apple-Mail=_9D9CB3A1-9FD5-4E9E-B5E2-08E46386FA09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 3 dec 2014, at 04:04, Peter Saint-Andre - &yet <peter@andyet.net> =
wrote:
>=20
> Hi Patrik,
>=20
> On 11/26/14, 11:28 PM, Patrik F=E4ltstr=F6m wrote:
>> I intend reading the mapping document today, sorry for the delay but
>> $dayjob has been kind of ultra-busy...
>>=20
>> Note that most issues I have have to do with clarifications, and that
>> it is not clear what the intent is.
>=20
> Yes, I will reply to your big message next.
>=20
>> Maybe a few where I urge caution. And they are definitely mapping
>> related.
>=20
> Clarifying question: are you talking about mapping in general (which =
might include width mapping, mapping non-ASCII space characters to ASCII =
space, case mapping, or in some nomenclatures even Unicode =
normalization), or only the kind of locale and context dependent mapping =
that is discussed in draft-ietf-precis-mappings?

I talk about any kind of transformation of a string.

>> Let me phrase it this way:
>>=20
>> One of the problems with IDNA2003 was that it included mapping. It
>> was unclear to people whether the client or server did the mapping.
>> In reality the only place where mapping could exist for a stable
>> protocol/implementation was between application/User Interface and
>> where the protocol was really "doing things". So mapping was ripped
>> out of IDNA when IDNA2008 was created.
>=20
> In the PRECIS WG we've had quite a bit of discussion about the =
dividing line between application and protocol, or more precisely =
between between the user interface (which can more easily handle issues =
of culture, context, intent, locale, device limitations, etc.) and the =
actual use of conformant strings in protocol slots.

Not surprising (and yes, I have seen some of this without claiming I did =
follow it).

> (Unfortunately, much of our most productive discussion has happened in =
sessions at IETF meetings, not on the list, so it's hard to find =
pointers.)
>=20
>> Precis has decided mapping is still part of the protocol definition,
>=20
> Well, draft-ietf-precis-mappings is only an informative reference from =
draft-ietf-precis-framework and with good reason: we reached the =
conclusion a few IETF meetings ago that we simply couldn't provide =
normative recommendations here.

Ok. Which I think is fair and good.

>> and I must understand where more exactly you expect mapping to
>> happen, what happens if that mapping is not done, how to expect to do
>> matching (comparison) between strings in the over all environment
>> where it is possibly unknown whether mapping has been done or not,
>> and specifically how it might impact the architecture in the cases
>> where the mapping is destructive to the string itself (non-reversible
>> mapping).
>>=20
>> I do not think it is clear in the framework WHERE mapping is to
>> happen.
>=20
> When you say "WHERE", do you mean (1) when in the process of handling =
an internationalized string or (2) by which entity in a protocol =
interaction?

Mainly (1) but that implies (2), right.

> I think we have been clear about (1), or at least we've tried to be =
clear - see for example Section 6 of draft-ietf-precis-framework.

That only specifies in what order the operations take place. It does not =
say when it happens.

Example:

A send a string X to B. B store the string, which can be a username or =
password.

Later C send a string Y to B. B is to look up that string among stored =
strings, to see whether in this case X =3D=3D Y or not.

Where in the flow A -> B(store) - B(lookup) <- C are the steps in =
section 6 taking place?

You have some string flowing between A and B(store), some string stored, =
some string flowing between C and B(lookup) and then some string is =
looked up. Which ones of these strings passed around have to live up to =
what requirements?

> I also think that the various profile documents and using protocols =
have been clear about (2) - see for instance Section 4 of =
draft-ietf-xmpp-6122bis.
>=20
>> Maybe just some ascii art would make things easier to understand?
>=20
> ASCII art always helps. :-)

:-D

   Patrik


--Apple-Mail=_9D9CB3A1-9FD5-4E9E-B5E2-08E46386FA09
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUfp6qrMabGguI180RApmqAJ9I8Mb9Dk1CN2dFAAXs3uvUNZXNiwCggB+8
eMZ5p+ae0VsqOyzh3E2P/LQ=
=0hLu
-----END PGP SIGNATURE-----

--Apple-Mail=_9D9CB3A1-9FD5-4E9E-B5E2-08E46386FA09--


From nobody Wed Dec  3 11:38:48 2014
Return-Path: <peter@andyet.net>
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 B166D1A8AE8 for <precis@ietfa.amsl.com>; Wed,  3 Dec 2014 11:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 8ulJ9qgweqCf for <precis@ietfa.amsl.com>; Wed,  3 Dec 2014 11:38:44 -0800 (PST)
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91D11A90E7 for <precis@ietf.org>; Wed,  3 Dec 2014 11:38:34 -0800 (PST)
Received: by mail-ig0-f179.google.com with SMTP id r2so13367995igi.12 for <precis@ietf.org>; Wed, 03 Dec 2014 11:38:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WiOla1ZSoF/X/HmGOO1SdvrUW7razGNUF13FPtwIPXg=; b=Fk1aFrJq8RckCTsvE5bSxqZMgwqqsa3I5q7+sfyml7yBFd2dAYaJWOfD8qqQ4bDbbh 5vl4CNHrrQf9MQA6wFx377dE/90TCuM7PojMa7mZR968yc76K1WbjI1Z1KZI1Fwp0yw3 T/zJI4yvjJC/JOqq6VWqtQPqDyAxXjHKQFG24CchoqQPyV2yElydzEfq8oiiTc2oOwxE VZSFK/u5RooD5m8D9rNTID4L80uxSsCB4fJYnIyz2D4CzuLvEAZv0o3TSh0VvpnvlZ73 9NlGUqqFQJqfXId77+jK3OA8ZmfLKIgm8CxDVHSitHu6IY1SAWUHyjkeXDHjvcuU3xHh /TqQ==
X-Gm-Message-State: ALoCoQnq9fI6maWINKrjTgw+02lYOA16uQNBUhMi28mvEocf33Zu6W4UAnUn9nbuBVBLH1VRXtTL
X-Received: by 10.107.128.87 with SMTP id b84mr6340779iod.42.1417635514148; Wed, 03 Dec 2014 11:38:34 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id fk8sm19096716igb.9.2014.12.03.11.38.33 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:38:33 -0800 (PST)
Message-ID: <547F66B8.10001@andyet.net>
Date: Wed, 03 Dec 2014 12:38:32 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <547BDAA7.2030601@andyet.net>	<547E7927.7030203@andyet.net> <CAKHUCzw8EDDbOds+z6gj=csXn0BJsZF2NwfVqr3xUJRkZGi0YA@mail.gmail.com>
In-Reply-To: <CAKHUCzw8EDDbOds+z6gj=csXn0BJsZF2NwfVqr3xUJRkZGi0YA@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/iEKaqm3YGFKfEvMHMswQoiFZbos
Cc: "precis@ietf.org" <precis@ietf.org>, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [precis] [xmpp] consolidating FreeformClass profiles?
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 19:38:45 -0000

On 12/3/14, 6:07 AM, Dave Cridland wrote:
> On 3 December 2014 at 02:44, Peter Saint-Andre - &yet <peter@andyet.net
> <mailto:peter@andyet.net>> wrote:
>
>     Seeing no objections, I'm going to make this change.
>
>
> I'm not wholly sure I fully understand the change you're proposing,
> which is why I've not commented.

The change is to not define a separate profile but instead point to the 
OpaqueString profile from draft-ietf-precis-saslprepbis. We are working 
hard to reduce the number of profiles, since multiplication of profiles 
beyond necessity will increase the possibility of user confusion.

http://tools.ietf.org/html/draft-ietf-precis-framework-20#section-5.1

> I suspect I need to spend some time getting to grips with Precis, and
> what the distinction is between Precis and Stringprep. Help here - such
> as a discussion at the XMPP Summit at the end of January - would be very
> welcome.

Unfortunately, now is the time to understand it, because we are pushing 
hard to finish this work in both PRECIS WG and XMPP WG.

This overview might be useful:

https://stpeter.im/files/i18n-tutorial.pdf

I might even have time to make a few updates to that soon so that it 
addresses your questions.

The following readings might prove useful:

http://tools.ietf.org/html/draft-ietf-precis-framework-20#section-1
http://tools.ietf.org/html/rfc4690
http://tools.ietf.org/html/rfc6885

> The only thing I feel qualified to comment on is that resources in XMPP
> shouldn't have spaces stripped; I think that'd be a surprising change in
> a handful of cases.

I'm proposing that we use this profile for resourceparts:

http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-12#section-4.2

There is no space-stripping there, but there is conversion of non-ASCII 
spaces to ASCII space.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Wed Dec  3 17:47:43 2014
Return-Path: <dave@cridland.net>
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 A96651A1AB2 for <precis@ietfa.amsl.com>; Wed,  3 Dec 2014 05:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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, HTML_MESSAGE=0.001, 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 hheYf9Ps_03V for <precis@ietfa.amsl.com>; Wed,  3 Dec 2014 05:07:23 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED281A1AAA for <precis@ietf.org>; Wed,  3 Dec 2014 05:07:23 -0800 (PST)
Received: by mail-oi0-f51.google.com with SMTP id e131so10789295oig.24 for <precis@ietf.org>; Wed, 03 Dec 2014 05:07:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+GTYK8TUjSdPnI4sIxvgoEamO/afBo50goc1tZhpG8o=; b=OZI9UIH0HWtFK+2xBlASNsxUNWT1f/bNyuJJ5M5SJXZkfUCR3PBMBle2pKwnHX3KHZ jsodNtdAyVtrFyuSwrrmx29UZ1t+a9BgjS1wvCbmjeGktnhWHuriejSEAh3fpp+xg/F1 63Hw5hFQXYX77GyNIpHpj/VmPCwT5BHhHO/kA=
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:date :message-id:subject:from:to:cc:content-type; bh=+GTYK8TUjSdPnI4sIxvgoEamO/afBo50goc1tZhpG8o=; b=FIQG5llrsrlB0W5z4gtyegcUrD2lBccjm9g53gmJ9OefJoHF78beMfq34ldae8WGll AqqtmPjEzp8M9jxhczUnRworcIUS6URtQQdKSaIohafEQMy6zSYyrhvOfB8VLfRW9Jwt tH3HuS7QApnfNCdzt+4j3ECo/fUvinZ3ScQ/ykT1H77TWCxWmEHpjEVDxcBwKteBPSvE 5TCevm+qzeyXIpvx96qW4TMOpQ8AOhAUKd+LpKVpVszOuv9xGmdkhlr2NPaFryqHYPS6 VdFiCJXAp9naC61JdDSfNKe47RPrnXw8ImU2yRH5l7APdUrQcZoxChzuFIZGW36XEMee vPmA==
X-Gm-Message-State: ALoCoQn78EGQi2fGVYuIoGZhY6PI17QWQBTEUPndY6k/dpBprC4OZaxmzfyf8VEjhqijKnkGA/sn
MIME-Version: 1.0
X-Received: by 10.202.220.87 with SMTP id t84mr2890150oig.86.1417612042542; Wed, 03 Dec 2014 05:07:22 -0800 (PST)
Received: by 10.60.227.199 with HTTP; Wed, 3 Dec 2014 05:07:22 -0800 (PST)
In-Reply-To: <547E7927.7030203@andyet.net>
References: <547BDAA7.2030601@andyet.net> <547E7927.7030203@andyet.net>
Date: Wed, 3 Dec 2014 13:07:22 +0000
Message-ID: <CAKHUCzw8EDDbOds+z6gj=csXn0BJsZF2NwfVqr3xUJRkZGi0YA@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Peter Saint-Andre - &yet" <peter@andyet.net>
Content-Type: multipart/alternative; boundary=001a113d30b239bcb105094f8620
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/jCXwvTEo8PBgS_zS0c_ySVS-9fY
X-Mailman-Approved-At: Wed, 03 Dec 2014 17:46:42 -0800
Cc: "precis@ietf.org" <precis@ietf.org>, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [precis] [xmpp] consolidating FreeformClass profiles?
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 13:07:33 -0000

--001a113d30b239bcb105094f8620
Content-Type: text/plain; charset=UTF-8

On 3 December 2014 at 02:44, Peter Saint-Andre - &yet <peter@andyet.net>
wrote:

> Seeing no objections, I'm going to make this change.


I'm not wholly sure I fully understand the change you're proposing, which
is why I've not commented.

I suspect I need to spend some time getting to grips with Precis, and what
the distinction is between Precis and Stringprep. Help here - such as a
discussion at the XMPP Summit at the end of January - would be very welcome.

The only thing I feel qualified to comment on is that resources in XMPP
shouldn't have spaces stripped; I think that'd be a surprising change in a
handful of cases.

--001a113d30b239bcb105094f8620
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3=
 December 2014 at 02:44, Peter Saint-Andre - &amp;yet <span dir=3D"ltr">&lt=
;<a href=3D"mailto:peter@andyet.net" target=3D"_blank">peter@andyet.net</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Seeing no objections, =
I&#39;m going to make this change.</blockquote><div><br></div><div>I&#39;m =
not wholly sure I fully understand the change you&#39;re proposing, which i=
s why I&#39;ve not commented.</div><div><br></div><div>I suspect I need to =
spend some time getting to grips with Precis, and what the distinction is b=
etween Precis and Stringprep. Help here - such as a discussion at the XMPP =
Summit at the end of January - would be very welcome.</div><div><br></div><=
div>The only thing I feel qualified to comment on is that resources in XMPP=
 shouldn&#39;t have spaces stripped; I think that&#39;d be a surprising cha=
nge in a handful of cases.</div></div></div></div>

--001a113d30b239bcb105094f8620--


From nobody Wed Dec  3 19:10:59 2014
Return-Path: <peter@andyet.net>
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 B006B1A88B2 for <precis@ietfa.amsl.com>; Wed,  3 Dec 2014 19:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 CtZoprhNx2Lp for <precis@ietfa.amsl.com>; Wed,  3 Dec 2014 19:06:31 -0800 (PST)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DAC1A88C5 for <precis@ietf.org>; Wed,  3 Dec 2014 19:06:17 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id hl2so17949986igb.17 for <precis@ietf.org>; Wed, 03 Dec 2014 19:06:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V8QhoiNV/TwV85jO0eYqgw/EYK8595l3Npwafimhdmw=; b=CXFdzX4L5dSs2W9W/ftqzOgRz9Q4hdl724lqz16euwEmpkYZaw+G4MfAKwTvUmQPGP qDWYmSgd1QVOJ2KqpN6CK60Nz2Qb8w90DHXCxv4esSv+zBfWWjg7KbA1gdcY4ZMDTc9C neUWhbI6wWm4/Ok+FNjo61e4XdRNv8oA6BVOtSaE6qrywJEzXt6+OCJ5WzaRJKKERU4B JUS5dwcipns+/2pxsxg/4m/D/JVvF/dnGB5garLDPRW8tNyxFXUq/6IA1TeaVs9Jv043 4/8UNMP9JxAv+6TN6gXJF0NcuHnRRJtPKI9k4dofbFkbHPDlIkP7ZIR1YwaLC4mEwdN0 tBQw==
X-Gm-Message-State: ALoCoQm9dxJ21ppnJrhfpCX4bhn+CjYkJa4pfguvBlLzGPUpormZ1Wxw1t5QTffihdKwhdSEz1uZ
X-Received: by 10.50.21.99 with SMTP id u3mr34320987ige.43.1417662376266; Wed, 03 Dec 2014 19:06:16 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id b3sm4006522igl.2.2014.12.03.19.06.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 19:06:15 -0800 (PST)
Message-ID: <547FCFA6.7000908@andyet.net>
Date: Wed, 03 Dec 2014 20:06:14 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <547695F3.3030106@andyet.net> <47327B22-0591-43C9-A4E5-89F6222F7E82@frobbit.se> <547E7DD0.1090306@andyet.net> <636EC582-BA21-44B5-B202-DDB4E51FD138@frobbit.se>
In-Reply-To: <636EC582-BA21-44B5-B202-DDB4E51FD138@frobbit.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/V163-YFnxOYjk4Z08yyk0w1a6So
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Thu, 04 Dec 2014 03:06:37 -0000
X-List-Received-Date: Thu, 04 Dec 2014 03:06:37 -0000

On 12/2/14, 10:24 PM, Patrik Fältström wrote:
> On 3 dec 2014, at 04:04, Peter Saint-Andre - &yet <peter@andyet.net> wrote:
>>
>> Hi Patrik,
>>
>> On 11/26/14, 11:28 PM, Patrik Fältström wrote:
>>> I intend reading the mapping document today, sorry for the delay but
>>> $dayjob has been kind of ultra-busy...
>>>
>>> Note that most issues I have have to do with clarifications, and that
>>> it is not clear what the intent is.
>>
>> Yes, I will reply to your big message next.
>>
>>> Maybe a few where I urge caution. And they are definitely mapping
>>> related.
>>
>> Clarifying question: are you talking about mapping in general (which might include width mapping, mapping non-ASCII space characters to ASCII space, case mapping, or in some nomenclatures even Unicode normalization), or only the kind of locale and context dependent mapping that is discussed in draft-ietf-precis-mappings?
>
> I talk about any kind of transformation of a string.
>
>>> Let me phrase it this way:
>>>
>>> One of the problems with IDNA2003 was that it included mapping. It
>>> was unclear to people whether the client or server did the mapping.
>>> In reality the only place where mapping could exist for a stable
>>> protocol/implementation was between application/User Interface and
>>> where the protocol was really "doing things". So mapping was ripped
>>> out of IDNA when IDNA2008 was created.
>>
>> In the PRECIS WG we've had quite a bit of discussion about the dividing line between application and protocol, or more precisely between between the user interface (which can more easily handle issues of culture, context, intent, locale, device limitations, etc.) and the actual use of conformant strings in protocol slots.
>
> Not surprising (and yes, I have seen some of this without claiming I did follow it).
>
>> (Unfortunately, much of our most productive discussion has happened in sessions at IETF meetings, not on the list, so it's hard to find pointers.)
>>
>>> Precis has decided mapping is still part of the protocol definition,
>>
>> Well, draft-ietf-precis-mappings is only an informative reference from draft-ietf-precis-framework and with good reason: we reached the conclusion a few IETF meetings ago that we simply couldn't provide normative recommendations here.
>
> Ok. Which I think is fair and good.
>
>>> and I must understand where more exactly you expect mapping to
>>> happen, what happens if that mapping is not done, how to expect to do
>>> matching (comparison) between strings in the over all environment
>>> where it is possibly unknown whether mapping has been done or not,
>>> and specifically how it might impact the architecture in the cases
>>> where the mapping is destructive to the string itself (non-reversible
>>> mapping).
>>>
>>> I do not think it is clear in the framework WHERE mapping is to
>>> happen.
>>
>> When you say "WHERE", do you mean (1) when in the process of handling an internationalized string or (2) by which entity in a protocol interaction?
>
> Mainly (1) but that implies (2), right.
>
>> I think we have been clear about (1), or at least we've tried to be clear - see for example Section 6 of draft-ietf-precis-framework.
>
> That only specifies in what order the operations take place. It does not say when it happens.
>
> Example:
>
> A send a string X to B. B store the string, which can be a username or password.
>
> Later C send a string Y to B. B is to look up that string among stored strings, to see whether in this case X == Y or not.
>
> Where in the flow A -> B(store) - B(lookup) <- C are the steps in section 6 taking place?
>
> You have some string flowing between A and B(store), some string stored, some string flowing between C and B(lookup) and then some string is looked up. Which ones of these strings passed around have to live up to what requirements?

Yes, that is very important, and we have tried to make that clear in 
application specs that are using PRECIS. For instance, 6122bis says:

    Enforcement entails applying all of the rules specified in this
    document.  Enforcement of the XMPP address format rules is the
    responsibility of XMPP servers.  Although XMPP clients SHOULD prepare
    complete JIDs and parts of JIDs in accordance with this document
    before including them in protocol slots within XML streams, XMPP
    servers MUST enforce the rules wherever possible and reject stanzas
    and other XML elements that violate the rules (for stanzas, by
    returning a <jid-malformed/> error to the sender as described in
    Section 8.3.3.8 of [RFC6120]).

    Entities that enforce the rules specified in this document are
    encouraged to be liberal in what they accept by following this
    procedure:

    1.  Where possible, map characters (e.g, through width mapping,
        additional mapping, special mapping, case mapping, or
        normalization) and accept the mapped string.

    2.  If mapping is not possible (e.g., because a character is
        disallowed in the FreeformClass), reject the string and return a
        <jid-malformed/> error.

    Enforcement applies to complete JIDs and to parts of JIDs.  To
    facilitate implementation, this document defines the concepts of "JID
    slot", "localpart slot", and "resourcepart slot" (similar to the
    concept of a "domain name slot" for IDNA2008 defined in
    Section 2.3.2.6 of [RFC5890]):

    JID Slot:  An XML element or attribute explicitly designated in XMPP
       or in XMPP extensions for carrying a complete JID.

    Localpart Slot:  An XML element or attribute explicitly designated in
       XMPP or in XMPP extensions for carrying the localpart of a JID.

    Resourcepart Slot:  An XML element or attribute explicitly designated
       in XMPP or in XMPP extensions for carrying the resourcepart of a
       JID.

    A server is responsible for enforcing the address format rules when
    receiving protocol elements from clients where the server is expected
    to handle such elements directly or to use them for purposes of
    routing a stanza to another domain or delivering a stanza to a local
    entity; two examples from [RFC6120] are the 'to' attribute on XML
    stanzas (which is a JID slot used by XMPP servers for routing of
    outbound stanzas) and the <resource/> child of the <bind/> element
    (which is a resourcepart slot used by XMPP servers for binding of a
    resource to an account for routing of stanzas between the server and
    a particular client).  An example from [RFC6121] is the 'jid'
    attribute of the roster <item/> element.

    A server is not responsible for enforcing the rules when the protocol
    elements are intended for communication among other entities,
    typically within the payload of a stanza that the server is merely
    routing to another domain or delivering to a local entity.  Two
    examples are the 'initiator' attribute in the Jingle extension
    [XEP-0166] (which is a JID slot used for client-to-client
    coordination of multimedia sessions) and the 'nick' attribute in the
    Multi-User Chat extension [XEP-0045] (which is a resourcepart slot
    used for administrative purposes in the context of XMPP chatrooms).
    In such cases, clients SHOULD enforce the rules themselves and not
    depend on the server to do so, and client implementers need to
    understand that not enforcing the rules can lead to a degraded user
    experience or to security vulnerabilities.  However, when an add-on
    service (e.g., a multi-user chat service) handles a stanza directly,
    it ought to enforce the rules as well, as defined in the relevant
    specification for that type of service.

Is that kind of text specific enough for you?

I think we need to define this at the level of the application protocol 
because that's where the rubber meets the road and where we can 
legitimately talk about the various entities involved (at the level of 
the PRECIS framework we don't know what the entities are and what their 
responsibilities are).

As another example, see this recent discussion in the PCP WG:

http://www.ietf.org/mail-archive/web/pcp/current/msg03819.html

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Dec  4 00:00:28 2014
Return-Path: <paf@frobbit.se>
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 3AC261A8934 for <precis@ietfa.amsl.com>; Thu,  4 Dec 2014 00:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level: 
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8px-9TJoEEbI for <precis@ietfa.amsl.com>; Thu,  4 Dec 2014 00:00:25 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1AC1A8935 for <precis@ietf.org>; Thu,  4 Dec 2014 00:00:25 -0800 (PST)
Received: from vpn-client-208.netnod.se (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id F1CB023071; Thu,  4 Dec 2014 09:00:23 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_F1C95371-A6BD-4DE2-8586-BD258F0EB251"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b3
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <547FCFA6.7000908@andyet.net>
Date: Thu, 4 Dec 2014 09:00:23 +0100
Message-Id: <F49F03E5-FB1E-4B81-B13F-F14E3DF350D5@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <547695F3.3030106@andyet.net> <47327B22-0591-43C9-A4E5-89F6222F7E82@frobbit.se> <547E7DD0.1090306@andyet.net> <636EC582-BA21-44B5-B202-DDB4E51FD138@frobbit.se> <547FCFA6.7000908@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/2YdaAFmw7itSHAm__UQJsoEth7U
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Thu, 04 Dec 2014 08:00:27 -0000

--Apple-Mail=_F1C95371-A6BD-4DE2-8586-BD258F0EB251
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


> On 4 Dec 2014, at 04:06, Peter Saint-Andre - &yet <peter@andyet.net> =
wrote:
>=20
> Is that kind of text specific enough for you?

Yes.

> I think we need to define this at the level of the application =
protocol because that's where the rubber meets the road and where we can =
legitimately talk about the various entities involved (at the level of =
the PRECIS framework we don't know what the entities are and what their =
responsibilities are).

I would say "ok" to the precis document if there is text added that say =
explicitly that that kind of text MUST be in an application specific =
document that reference the precis doc.

I.e. without text like that, it is very dangerous what is specified.

   Patrik


--Apple-Mail=_F1C95371-A6BD-4DE2-8586-BD258F0EB251
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlSAFJcACgkQrMabGguI182rHQCeNEB9A/UlfIW4mHhZ3Tg84bvL
IPcAnRaN9rt6zdU6FrRW279ZDScR4xaT
=D/so
-----END PGP SIGNATURE-----

--Apple-Mail=_F1C95371-A6BD-4DE2-8586-BD258F0EB251--


From nobody Sun Dec  7 17:35:25 2014
Return-Path: <peter@andyet.net>
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 0E1041A1B3C for <precis@ietfa.amsl.com>; Sun,  7 Dec 2014 17:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 SbD1l5Q4t5i4 for <precis@ietfa.amsl.com>; Sun,  7 Dec 2014 17:35:20 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A262E1A1B3D for <precis@ietf.org>; Sun,  7 Dec 2014 17:35:20 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id x19so3621209ier.6 for <precis@ietf.org>; Sun, 07 Dec 2014 17:35:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dtg1rSZeVT4GCgEO8nNGkvzBMwzjlkFzBzCAnxZsz3o=; b=hMqwG2u1EftTQOvjlr7IgizjCC7w/CdeZ1jhk2YW1/7F2WhV+GZe14qLUpPE8mpdSu YvU0TFJHI3vPqToL3roJK43CaSWzVnaW6GzK5JmCluxNRrFjfF2ibjvXA1ch60ipGbvB +Ao2n5EhFIGa4D+hF6C5EnnS4gKCqFfMy59v/Rs42aFdsd/QEiGSz8WmZThP/+y5jnyN JDqqlmpXeZ1gS/kcSOZn476N6hM+gXR4nuphAI8VR3HO/TDDHsziePwxSIle46H/D9bQ dxh7lUCortvoj2JNKUbjWZPbPGNgaTReYm2vQ7I3GJK6fAs4nxTgP+Unff5VpdOQ3mZ9 6Q5A==
X-Gm-Message-State: ALoCoQlHkcXUx2nXFB+NJXUwkNaxWUWB3mWqXZnL/AvK6Z0PvdlCQdr1P3ocKIZKoFzX3p1gqe9n
X-Received: by 10.50.73.228 with SMTP id o4mr12356861igv.15.1418002520085; Sun, 07 Dec 2014 17:35:20 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ga11sm3121053igd.4.2014.12.07.17.35.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 17:35:19 -0800 (PST)
Message-ID: <54850056.6070203@andyet.net>
Date: Sun, 07 Dec 2014 18:35:18 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <547695F3.3030106@andyet.net> <47327B22-0591-43C9-A4E5-89F6222F7E82@frobbit.se> <547E7DD0.1090306@andyet.net> <636EC582-BA21-44B5-B202-DDB4E51FD138@frobbit.se> <547FCFA6.7000908@andyet.net> <F49F03E5-FB1E-4B81-B13F-F14E3DF350D5@frobbit.se>
In-Reply-To: <F49F03E5-FB1E-4B81-B13F-F14E3DF350D5@frobbit.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/kykJWyg3rXbrato58qjNEzdx_e8
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Dec 2014 01:35:24 -0000

On 12/4/14, 1:00 AM, Patrik Fältström wrote:
>
>> On 4 Dec 2014, at 04:06, Peter Saint-Andre - &yet <peter@andyet.net> wrote:
>>
>> Is that kind of text specific enough for you?
>
> Yes.
>
>> I think we need to define this at the level of the application protocol because that's where the rubber meets the road and where we can legitimately talk about the various entities involved (at the level of the PRECIS framework we don't know what the entities are and what their responsibilities are).
>
> I would say "ok" to the precis document if there is text added that say explicitly that that kind of text MUST be in an application specific document that reference the precis doc.
>
> I.e. without text like that, it is very dangerous what is specified.

Agreed. I'll add some text about that in the next version.

Peter



From nobody Sun Dec  7 19:49:11 2014
Return-Path: <peter@andyet.net>
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 79E2E1A1BB1 for <precis@ietfa.amsl.com>; Sun,  7 Dec 2014 19:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.591
X-Spam-Level: 
X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 LDmpyAZcu82W for <precis@ietfa.amsl.com>; Sun,  7 Dec 2014 19:49:04 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F2E1A1BB7 for <precis@ietf.org>; Sun,  7 Dec 2014 19:49:03 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id x19so3741596ier.6 for <precis@ietf.org>; Sun, 07 Dec 2014 19:49:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qlWjz+M/HF4QPGhdXpKb4ieB0GCQT2y1jxHe0t8Aygc=; b=Yhtvf7hHgp6vNs5ifBhJi9zQxzlBiHR9xojm7Iy3z2vPAaKf5/GCL/Y2OSLSfWtfhK M2ctNf0yZW/OiGIbvmkRN9o28dP2fettt5YFPnphWVBBHRcPHXFGEc0wB9RiJvQX/hR8 9iZsRmMrSDkRfg++NkjFwOqxW5WUfvbXqjaJCRVk+Td71RtbXAw7Sinx0XAiCWLvw2/j DCC9oDzrz5DZmWdYgm69QYQqTZoXejy7QuMWpiphQXh6Uh1q4puJyic5rgtBMTdcNAgl 4B+vCQ8ySRXZJX+W9fvHB0H9cTFjEStetseHiuuA3YTNlEJfdfTK1Xd1WSjtFhKpWyDY SWHw==
X-Gm-Message-State: ALoCoQnWcXMYHQx6Rwy9aH2nNcSCRqGq84gzZ6tCxYribVhOOJOCo7uW5OUJCvS9rGuro5MjPfCZ
X-Received: by 10.107.170.162 with SMTP id g34mr9092460ioj.2.1418010543339; Sun, 07 Dec 2014 19:49:03 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id bd5sm3271889igb.14.2014.12.07.19.49.02 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 19:49:02 -0800 (PST)
Message-ID: <54851FAD.4040009@andyet.net>
Date: Sun, 07 Dec 2014 20:49:01 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>,  precis@ietf.org
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se>
In-Reply-To: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/t8tzNW0CMVVsoFKF80kzA0hT0OU
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Dec 2014 03:49:09 -0000

On 11/23/14, 7:58 AM, Patrik Fältström wrote:
> I have on request from the chairs done a review of three Precis
> documents. Here is the review of draft-ietf-precis-framework-20.

Patrik, many thanks for the thorough review!

> The review has focused on the use of Unicode and the relationship
> with IDNA2008.
>
> You see my comments below.
>
> Best, Patrik Fältström
>
>> draft-ietf-precis-framework-20
>>
>> Abstract
>>
>> Application protocols using Unicode characters in protocol strings
>> need to properly handle such strings in order to enforce
>> internationalization rules for strings placed in various protocol
>> slots (such as addresses and identifiers) and to perform valid
>> comparison operations (e.g., for purposes of authentication or
>> authorization).  This document defines a framework enabling
>> application protocols to perform the preparation, enforcement, and
>> comparison of internationalized strings ("PRECIS") in a way that
>> depends on the properties of Unicode characters and thus is agile
>> with respect to versions of Unicode.  As a result, this framework
>> provides a more sustainable approach to the handling of
>> internationalized strings than the previous framework, known as
>> Stringprep ( RFC 3454).  This document obsoletes RFC 3454 .
>
> Explanation on what my review is concentrating on:
>
> When using a character set like Unicode where things like
> transformation, comparisons etc, the actual transformation can happen
> in multiple locations in the architecture, and what is needed is for
> applications to understand what format the strings are that are
> received and what format strings are expected to be in when being
> sent. Of course the principle of "be liberal in what you accept, and
> conservative in what you send" is very important.
>
> A simplified sketch of the architecture is as follows:
>
> 1. [A] sends a string to [B] for storage
>
> 2. [C] send a string to be for lookup, which implies matching
> algorithm is applied
>
> 3. If there is a match, data is sent back to [C]
>
> In this very simple way of looking at the issues the questions
> include:
>
> A. What Unicode code points should [A] accept as input
>
> B. What transformation is [A] expected to do?
>
> C. What transformation is [A] allowed to do?
>
> D. What Unicode code points is [A] allowed to send to [B]?
>
> E. What Unicode code points can [B] expect from [A]?
>
> F. What transformation is [B] expected to do on data sent from [A]
> before data is stored in the database?
>
> : :
>
> I.e. it must be as clear as possible for each one of the parties A, B
> and C what they are expected to do, what they must (and must not)
> do.

For the profiles and application usages that go along with the framework 
(draft-ietf-precis-saslprepbis, draft-ietf-precis-nickname, 
draft-ietf-xmpp-6122bis), we have tried to address the considerations 
you raise. However, I think that in several places we could do a better 
job, such as:

i. Explain not only what entities are expected to do, but also what they 
are allowed to do.

ii. Specify what various using applications need to do (e.g., I don't 
think we've made that fully clear in the saslprepbis and nickname 
documents, although I think it is very clear in 6122bis).

These are matters that we can focus on during WGLC for those specs, I think.

> And of course ultimately the issue/trouble is that the Unicode
> Character Set is created and designed in such a way that there are
> many equivalences that humans in various contexts do expect are to be
> treated as "the same". Of course different in different contexts.

Indeed.

> Now to the review...
>
>> 4.  Enable application protocols to define profiles of the PRECIS
>> string classes if necessary (addressing matters such as width
>> mapping, case mapping, Unicode normalization, and directionality)
>> but strongly discourage the multiplication of profiles beyond
>> necessity in order to avoid violations of the Principle of Least
>> User Astonishment.
>
> It must also be clear who has the responsibility to do whatever
> transformations needed.

Yes. See above and below in this message, other messages in this thread, 
and the forthcoming revised I-D.

>> It is expected that this framework will yield the following
>> benefits:
>>
>> o  Application protocols will be agile with regard to Unicode
>> versions.
>>
>> o  Implementers will be able to share code point tables and
>> software code across application protocols, most likely by means
>> of software libraries.
>>
>> o  End users will be able to acquire more accurate expectations
>> about the characters that are acceptable in various contexts.
>> Given this more uniform set of string classes, it is also expected
>> that copy/paste operations between software implementing different
>> application protocols will be more predictable and coherent.
>
> It must also to everyone involved be clear what is the normative
> authoritative source for what is allowed and not.
>
> For IDNA2008 (for example) it is the _algorithm_ that is normative.
> Not any tables that are derivatives from applying the algorithm on a
> specific version of the Unicode Character Set.

Agreed. That's why the introduction states:

    The character categories and calculation rules defined under
    Section 7 and Section 8 are normative and apply to all Unicode code
    points.  The code point table that results from applying the
    character categories and calculation rules to the latest version of
    Unicode can be found in an IANA registry.

>> When an application applies a profile of a PRECIS string class, it
>> can achieve the following objectives:
>>
>> a.  Determine if a given string conforms to the profile, thus
>> enabling enforcement of the rules (e.g., to determine if a string
>> is allowed for use in the relevant protocol slot specified by an
>> application protocol).
>>
>> b.  Determine if any two given strings are equivalent, thus
>> enabling comparision (e.g., to make an access decision for purposes
>> of authentication or authorization as further described in [
>> RFC6943 ]).
>
> And of course applying transformation on a string being received
> before it is passed on to the next step of whatever process the
> application is participating in. In this case, the string is in one
> form before the transformation and another form after the
> transformation. It must also be clear to everyone involved that
> transformations applied very seldom (if at all) are reversible.
> Specifically this is the case when doing case folding
> transformations.

Ack.

>> 3.  Preparation, Enforcement, and Comparison
>>
>>
>> This document distinguishes between three different actions that
>> an entity can take with regard to a string:
>>
>> o  Enforcement entails applying all of the rules specified for a
>> particular string class or profile thereof to an individual string,
>> for the purpose of determining if the string can be used in a given
>> protocol slot.
>>
>> o  Comparison entails applying all of the rules specified for a
>> particular string class or profile thereof to two separate strings,
>> for the purpose of determining if the two strings are equivalent.
>
> In fact I think the "comparison" entitles three steps:
>
> 1. Apply all transformation and enforcement on string A.
>
> 2. Apply all transformation and enforcement on string B.
>
> 3. Compare the strings A and B unicode character by character. Only
> if all characters are the same, a positive match is the result.

Agreed. I'll adjust the text along those lines.

>> o  Preparation entails only ensuring that the characters in an
>> individual string are allowed by the underlying PRECIS string
>> class.
>
> I think the idea with "preparation" is to apply certain
> transformation and to, after transformation, ensure all characters in
> the context they exist, are allowed, so that the final string after
> the preparation step is a valid precis string?

During discussion of draft-ietf-xmpp-6122bis in the XMPP WG, several 
commenters noted that they would prefer to assign more lightweight 
processing to entities that are not capable of full enforcement of all 
the rules for a profile (i.e., not heavy or advanced tasks like Unicode 
normalization). Out of that conversation emerged the concept of 
"preparation" as involving only limits on the character ranges.

Perhaps we could have chosen a less ambiguous term than "preparation"?

> I would recommend explicitly mentioning the fact (destructive)
> transformation might occur in this step.

Destructive transformation doesn't sound good. Do you have examples of 
what that means?

>> In most cases, authoritative entities such as servers are
>> responsible for enforcement, whereas subsidiary entities such as
>> clients are responsible only for preparation.  The rationale for
>> this distinction is that clients might not have the facilities (in
>> terms of device memory and processing power) to enforce all the
>> rules regarding internationalized strings (such as width mapping
>> and Unicode normalization), although they can more easily limit the
>> repertoire of characters they offer to an end user.  By contrast,
>> it is assumed that a server would have more capacity to enforce the
>> rules, and in any case acts as an authority regarding allowable
>> strings in protocol slots such as addresses and endpoint
>> identifiers.  In addition, a client cannot necessarily be trusted
>> to properly generate such strings, especially for
>> security-sensitive contexts such as authentication and
>> authorization.
>
> This paragraph is very vague. I think the protocol need a much
> stricter specification on who is expected to do what. This because
> the protocol itself (that is for example between client and server)
> must be robust enough to carry whatever code points the client is
> using.

Yes, and that's what each application usage or profile needs to specify 
very clearly. We can provide some guidelines for such text in the 
framework, but I don't think we can provide that text for all 
applications here.

>> Valid:  Defines which code points and character categories are
>> treated as valid input to the string.
>
> The term "input" is not clear to me, given transformation might
> occur.

Good point. Will fix.

>> Disallowed:  Defines which code points and character categories
>> need to be excluded from the string.
>
> It is a bit confusing to talk about both categories and code points
> at the same time. I would recommend in this point in time in the
> document talk about what code points are disallowed. Reason for this
> is that you might have a category that is disallowed while the code
> point that is of that category is allowed (based on other rules, like
> exceptions). To make it crystal clear what is disallowed, I recommend
> only use that term for code points.

Yes, we'll change that.

>> 4.2.1.  Valid
>>
>>
>> o  Code points traditionally used as letters and numbers in
>> writing systems, i.e., the LetterDigits ("A") category first
>> defined in [ RFC5892] and listed here under Section 8.1 .
>>
>> o  Code points in the range U+0021 through U+007E, i.e., the
>> (printable) ASCII7 ("K") rule defined under Section 8.11 .  These
>> code points are "grandfathered" into PRECIS and thus are valid even
>> if they would otherwise be disallowed according to the
>> property-based rules specified in the next section.
>>
>> Note: Although the PRECIS IdentifierClass re-uses the LetterDigits
>> category from IDNA2008, the range of characters allowed in the
>> IdentifierClass is wider than the range of characters allowed in
>> IDNA2008.  The main reason is that IDNA2008 applies the Unstable
>> category before the LetterDigits category, thus disallowing
>> uppercase characters, whereas the IdentifierClass does not apply
>> the Unstable category.
>
> You must remove the code points of class ("C") in RFC5892.

The only difference between class "C" (IDNA2008) and class "M" (PRECIS) 
is that in PRECIS we allow white space code points in the FreeformClass. 
Thus we use "C", not "M".

> Or to state things differently. If one look at the Unicode tables,
> the following combination of matches exists for code points that
> matches category "A" and at least one more category, for Unicode
> 7.0.0:
>
> AB ABC ABF AC ACI AD AE AF AI
>
> There are several of these combinations that is given this definition
> is valid which I would not say is recommended for use for
> identifiers.

OK, I will look at this more closely.

> Further, regarding not including stable. This implies it is allowed
> to use code points in Precis that are not stable regarding
> normalization and/or case folding. The normalization and/or case
> folding still must be made somewhere before matching is happening.
>
> Lets for example say that "A" and "a" are both valid (which they
> would be). The question is then whether there is case mapping before
> comparison or not, and if there is, it must be ensured that the two
> identities "A" and "a" are not both created in some name space.
>
> I know this is exactly what you have been talking about and
> discussing, but it must be absolutely crystal clear everyone
> understand what this implies. Specifically when case folding (lower
> case) is replaced with NFC or some normalization algorithm.

I think this is handled more directly by the UsernameCaseMapped and 
UsernameCasePreserved profiles of the IdentifierClass specified in 
draft-ietf-precis-saslprepbis.

> More about this later.

There is always more to be said about i18n. :-)

>> 4.2.3.  Disallowed
>
> See above.
>
>> Some application technologies need strings that can be used in a
>> free-form way, e.g., as a password in an authentication exchange
>> (see [ I-D.ietf-precis-saslprepbis ]) or a nickname in a chatroom
>> (see [ I-D.ietf-precis-nickname ]).  We group such things into a
>> class called "FreeformClass" having the following features.
>>
>> Security Warning: As mentioned, the FreeformClass prioritizes
>> expressiveness over safety; Section 11.3 describes some of the
>> security hazards involved with using or profiling the
>> FreeformClass.
>>
>> Security Warning: Consult Section 11.6 for relevant security
>> considerations when strings conforming to the FreeformClass, or a
>> profile thereof, are used as passwords.
>
> There are very dangerous issues here when using this class for any
> kind of comparison.  Specifically in the case of password and user
> names (or file names)

We actively discourage the use of the FreeformClass (or profiles 
thereof) for user names, file names, and the like.

See however draft-ietf-precis-nickname, where we use a profile of the 
FreeformClass for nicknames (e.g., in a chatroom).

> where it is unclear what kind of normalization
> might happen between "the keyboard" and "the application". I.e. the
> user might really really think they enter a certain code point, but
> in reality what the application see is either NFC(string) or
> NFD(string) and which one might vary on the operating system (or file
> system) in use. Specifically when leaving this undefined.
>
> I am all in favor of leaving this undefined for this class, but then
> it might not be the best to do any kind of matching (including
> searching). Unless some kind of transformation is made for the
> matching/searching.

We might need some more text about these matters in the profiles that 
use the FreeformClass: OpaqueString (in saslprepbis) and Nickname. 
Another topic to fix during WGLC.

> I would recommend the following general rules:
>
> - IdentifierClass are used wherever it is importan the namespace
> include only globally unique strings, like identifiers for user names
> etc

Agreed.

> - IdentifierClass are also used for passwords

That might not be consistent with the need for entropy in passwords. See 
draft-ietf-precis-saslprepbis on this point.

> and whenever a
> comparison is used,

Ideally, passwords are not stored in the clear, which case some kind of 
transformation will need to happen before any comparison is done. That's 
why draft-ietf-precis-saslprepbis states:

    In protocols that provide passwords as input to a cryptographic
    algorithm such as a hash function, the client will need to perform
    proper preparation of the password before applying the algorithm,
    since the password is not available to the server in plaintext form.

> but the transformation should not be
> destructive.

Here again I'm not sure exactly what that means.

> - FreeformClass is used for storage of various things
>
> - Protocols must be stable for FreeformClass in the transport

If you have time, could you expand upon those two points a bit?

>> 4.3.1.  Valid
>
> See comments above regarding combination of A with other categories.
>
>> 5.1.  Profiles Must Not Be Multiplied Beyond Necessity
>>
>>
>> The risk of profile proliferation is significant because having
>> too many profiles will result in different behavior across various
>> applications, thus violating what is known in user interface
>> design as the Principle of Least Astonishment.
>>
>> Indeed, we already have too many profiles.  Ideally we would have
>> at most two or three profiles.  Unfortunately, numerous
>> application protocols exist with their own quirks regarding
>> protocol strings.
>>
>> Domain names, email addresses, instant messaging addresses,
>> chatroom nicknames, filenames, authentication identifiers,
>> passwords, and other strings are already out there in the wild and
>> need to be supported in existing application protocols such as DNS,
>> SMTP, XMPP, IRC, NFS, iSCSI, EAP, and SASL among others.
>>
>> Nevertheless, profiles must not be multiplied beyond necessity.
>>
>> To help prevent profile proliferation, this document recommends
>> sensible defaults for the various options offered to profile
>> creators (such as width mapping and Unicode normalization).  In
>> addition, the guidelines for designated experts provided under
>> Section 9 are meant to encourage a high level of due diligence
>> regarding new profiles.
>
> What are the requirements to create a new Profile?

Rule #1: Don't create new profiles.

Rule #2: Don't ignore Rule #1.

Rule #3: If you push on through the first two rules, provide a strong 
justification for the new profile and answer all the questions under the 
IANA considerations in the framework. Even then, expect a lot of 
pushback from the designated experts.

> Either there are requirements or not. This text above does not add
> much help if there is a conflict in the future regarding request for
> registration of a new Profile. Are you really happy with what is
> above?

I'm happy with the totality of information and requirements in Sections 
5.1, 9, and 10.3 of framework-20.

> The WG must honestly say "yes" to this. If they do, I am happy! :-)

I can't speak for the WG. :-)

>> 5.2.1.  Width Mapping Rule
>>
>>
>> The width mapping rule of a profile specifies whether width
>> mapping is performed on fullwidth and halfwidth characters, and how
>> the mapping is done.  Typically such mapping consists of mapping
>> fullwidth and halfwidth characters, i.e., code points with a
>> Decomposition Type of Wide or Narrow, to their decomposition
>> mappings; as an example, FULLWIDTH DIGIT ZERO (U+FF10) would be
>> mapped to DIGIT ZERO (U+0030).
>>
>> The normalization form specified by a profile (see below) has an
>> impact on the need for width mapping.  Because width mapping is
>> performed as a part of compatibility decomposition, a profile
>> employing either normalization form KD (NFKD) or normalization
>> form KC (NFKC) does not need to specify width mapping.  However,
>> if Unicode normalization form C (NFC) is used (as is recommended)
>> then the profile needs to specify whether to apply width mapping;
>> in this case, width mapping is in general RECOMMENDED because
>> allowing fullwidth and halfwidth characters to remain unmapped to
>> their compatibility variants would violate the Principle of Least
>> Astonishment.  For more information about the concept of width in
>> East Asian scripts within Unicode, see Unicode Standard Annex #11
>> [ UAX11 ].
>
> Doing this mapping is not easy. I strongly recommend an algorithm is
> presented that either is in use or not by the profile.

We've been trying not to define new algorithms. Is there one we can can 
point to elsewhere?

>> 5.2.3.  Case Mapping Rule
>>
>>
>> The case mapping rule of a profile specifies whether case mapping
>> is performed (instead of case preservation) on uppercase and
>> titlecase characters, and how the mapping is done (e.g., mapping
>> uppercase and titlecase characters to their lowercase
>> equivalents).
>
> You either apply mapping or not, to _all_ code points. The above make
> it sort of look like if case mapping is sometimes not to be
> performed.

Would we ever apply case mapping to characters other than upperase and 
titlecase characters? Perhaps you mean only to point out that the rule 
is applied to all code points, but only uppercase and titlecase code 
points are transformed by the rule. If so, the text is easy to adjust.

>> If case mapping is desired (instead of case preservation), it is
>> RECOMMENDED to use Unicode Default Case Folding as defined in
>> Chapter 3 of the Unicode Standard [ Unicode7.0 ].
>>
>> Note: Unicode Default Case Folding is not designed to handle
>> various localization issues (such as so-called "dotless i" in
>> several Turkic languages).  The PRECIS mappings document [
>> I-D.ietf-precis-mappings ] describes these issues in greater detail
>> and defines a "local case mapping" method that handles some
>> locale-dependent and context-dependent mappings.
>>
>> In order to maximize entropy and minimize the potential for false
>> positives, it is NOT RECOMMENDED for application protocols to map
>> uppercase and titlecase code points to their lowercase equivalents
>> when strings conforming to the FreeformClass, or a profile
>> thereof, are used in passwords; instead, it is RECOMMENDED to
>> preserve the case of all code points contained in such strings and
>> then perform case-sensitive comparison.  See also the related
>> discussion in [ I-D.ietf-precis-saslprepbis ].
>
> The above is too complicated.

It is long-winded, but is it more complicated than your terse versino below?

> The only realistic way of handling casing is to:
>
> 1. Decide whether there is case insensitive matching to be done or
> not
>
> 2. If it is, case fold to lower case before the matching
>
> 3. If transformation of a string is made, case fold to lower case as
> part of the transformation

If I understand the difference between (2) and (3) correctly, (2) 
applies to case-insensitive matching (e.g., an application might 
preserve case on storing strings but compare two output strings in a 
case-insensitive way), whereas (3) applies to storage of strings in some 
canonical format.

> 4. Do not forget issues with normalization and case folding both be
> applied on the same string

Yes, I will give more thought to that and see if we can add some 
appropriate text.

>> 5.2.5.  Directionality Rule
>>
>>
>> The directionality rule of a profile specifies how to treat
>> strings containing left-to-right (LTR) and right-to-left (RTL)
>> characters (see Unicode Standard Annex #9 [ UAX9 ]).  A profile
>> usually specifies a directionality rule that restricts strings to
>> be entirely LTR
>> strings or entirely RTL strings and defines the allowable
>> sequences of characters in LTR and RTL strings.  Possible rules
>> include, but are not limited to, (a) considering any string that
>> contains a right- to-left code point to be a right-to-left string,
>> or (b) applying the "Bidi Rule" from [ RFC5893 ].
>
> One can not restrict to only LTR or RTL as some code points are
> neutral regarding directionality.
>
> See RFC5893. This was one of the mistakes in IDNA2003.

I think you're right that the foregoing text is not quite correct.

And in any case, as John Klensin reiterated at the mic in a recent 
PRECIS WG session, if we define something other than the Bidi Rule then 
we'll likely get it wrong. I think that text predates John's comments 
and hasn't been updated..

>> Mixed-direction strings are not directly supported by the PRECIS
>> framework itself, since there is currently no widely accepted and
>> implemented solution for the safe display of mixed-direction
>> strings.
>
> Define Mixed-Direction strings or else the text will be confusing.

Will do.

>> username   = userpart *(1*SP userpart) userpart   = 1*(idbyte) ; ;
>> an "idbyte" is a byte used to represent a ; UTF-8 encoded Unicode
>> code point that can be ; contained in a string that conforms to
>> the ; PRECIS "IdentifierClass" ;
>
> Do not talk about "byte" here but instead "character". So, in the
> grammar, talk about Unicode Code Points. How the Unicode string is
> then encoding (for example UTF-8) is a different issue.

Hmm. All of the new profiles or application usages specify UTF-8. This 
issue of bytes/octets vs. characters caused us problems in XMPP (in part 
because we specify length limits). I'll need to look at it more closely 
before making a change.

>> 6.  Order of Operations
>>
>>
>> To ensure proper comparison, the rules specified for a particular
>> string class or profile MUST be applied in the following order:
>
> It must, as I started with saying above, be clear when these
> operations take place. Is it a (destructive) transformation done
> somewhere (application, client side, server side) or just something
> part of a matching algorithm?

Yes, we've tried to address that in profile and application specs.

>> 8.3.  IgnorableProperties (C)
>>
>>
>> This category is defined in Secton 2.3 of [ RFC5892 ] but is not
>> used in PRECIS.
>>
>> Note: See the "PrecisIgnorableProperties (M)" category below for a
>> more inclusive category used in PRECIS identifiers.
>
> See comments above.
>
>> 8.7.  BackwardCompatible (G)
>>
>>
>> This category is defined in Secton 2.7 of [ RFC5892 ] and is
>> included by reference for use in PRECIS.
>>
>> Note: Because of how the PRECIS string classes are defined, only
>> changes that would result in code points being added to or removed
>> from the LetterDigits ("A") category would result in backward-
>> incompatible modifications to code point assignments.
>
> Are you sure? I am not.

I think we just leave that up to RFC 5892 and remove that note.

>> Therefore, management of this category is handled via the processes
>> specified in [ RFC5892 ].  At the time of this writing (and also at
>> the time that
>>
>> RFC 5892 was published), this category consisted of the empty set;
>> however, that is subject to change as described in RFC 5892 .
>
> This is true on the other hand.
>
>> 8.13.  PrecisIgnorableProperties (M)
>>
>>
>> This PRECIS-specific category is used to group code points that
>> are discouraged from use in PRECIS string classes.
>>
>> M: Default_Ignorable_Code_Point(cp) = True or
>> Noncharacter_Code_Point(cp) = True
>>
>> The definition for Default_Ignorable_Code_Point can be found in
>> the DerivedCoreProperties.txt [ 2 ] file, and at the time of
>> Unicode 7.0 is as follows:
>>
>> Other_Default_Ignorable_Code_Point + Cf (Format characters) +
>> Variation_Selector - White_Space - FFF9..FFFB (Annotation
>> Characters) - 0600..0604, 06DD, 070F, 110BD (exceptional Cf
>> characters that should be visible)
>
> I would be very nervous over having explicit code points in a generic
> rule like this. If the code points are to be listed explicitly, add
> them to an exception rule. Otherwise *this* rule have to be changed
> when future changes have to be made that would require otherwise
> exceptions to be added.

That simply repeats what Unicode 7.0 says, but we can remove it to 
prevent developer confusion.

>> 8.14.  Spaces (N)
>>
>>
>> This PRECIS-specific category is used to group code points that
>> are space characters.
>>
>> N: General_Category(cp) is in {Zs}
>
> I am still thinking of how "spaces" is handled here. Will check and
> think more when I look at the mapping documents. Specifically when
> you also look at Arabic and other similar scripts. Just do
> destructive transformation to U+0020 is not always working I think.

We have had a lot of discussion about space characters, not really 
captured all that well in the specs. But see Section 5.5:

5.5.  A Note about Spaces

    With regard to the IdentiferClass, the consensus of the PRECIS
    Working Group was that spaces are problematic for many reasons,
    including:

    o  Many Unicode characters are confusable with ASCII space.

    o  Even if non-ASCII space characters are mapped to ASCII space
       (U+0020), space characters are often not rendered in user
       interfaces, leading to the possibility that a human user might
       consider a string containing spaces to be equivalent to the same
       string without spaces.

    o  In some locales, some devices are known to generate a character
       other than ASCII space (such as ZERO WIDTH JOINER, U+200D) when a
       user performs an action like hitting the space bar on a keyboard.

    One consequence of disallowing space characters in the
    IdentifierClass might be to effectively discourage their use within
    identifiers created in newer application protocols; given the
    challenges involved with properly handling space characters
    (especially non-ASCII space characters) in identifiers and other
    protocol strings, the PRECIS Working Group considered this to be a
    feature, not a bug.

    However, the FreeformClass does allow spaces, which enables
    application protocols to define profiles of the FreeformClass that
    are more flexible than any profiles of the IdentifierClass.  In
    addition, as explained in the previous section, application protocols
    can also define application-layer constructs containing spaces.

>> 8.17.  HasCompat (Q)
>>
>>
>> This PRECIS-specific category is used to group code points that
>> have compatibility equivalents as explained in Chapter 2 and
>> Chapter 3 of the Unicode Standard [ Unicode7.0 ].
>>
>> Q: toNFKC(cp) != cp
>>
>> The toNFKC() operation returns the code point in normalization
>> form KC.  For more information, see Section 5 of Unicode Standard
>> Annex #15 [ UAX15 ].
>
> Think about implications of this together with case folding (or
> not).

I shall. :-)

Thanks again for the review. I'll work to update the spec soon.

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/


From nobody Sun Dec  7 21:58:08 2014
Return-Path: <paf@frobbit.se>
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 6ACF81A1B23 for <precis@ietfa.amsl.com>; Sun,  7 Dec 2014 21:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level: 
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 smllJlVai5Mz for <precis@ietfa.amsl.com>; Sun,  7 Dec 2014 21:58:05 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5001A6F17 for <precis@ietf.org>; Sun,  7 Dec 2014 21:58:05 -0800 (PST)
Received: from [192.168.1.83] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id A56EF21FA2; Mon,  8 Dec 2014 06:58:03 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_44C93124-DA30-4A66-92E9-386DF3ED9649"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b3
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <54851FAD.4040009@andyet.net>
Date: Mon, 8 Dec 2014 06:58:03 +0100
Message-Id: <F66680E5-2DA4-449B-81C3-9A6C0422CF0B@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Gdb2KFtgxbU4qm6NHqD-IAh-kvM
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Dec 2014 05:58:06 -0000

--Apple-Mail=_44C93124-DA30-4A66-92E9-386DF3ED9649
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


> On 8 dec 2014, at 04:49, Peter Saint-Andre - &yet <peter@andyet.net> =
wrote:
>=20
>> I would recommend explicitly mentioning the fact (destructive)
>> transformation might occur in this step.
>=20
> Destructive transformation doesn't sound good. Do you have examples of =
what that means?

When you do a transformation that does not have an inverse. For example =
lowercase.

uppercase(lowercase(cp)) is not cp for all values of cp.

In IDNA2003, the mappings where destructive, which implied that =
"toascii(unicode string)" (within quotes, because I think you know what =
I talk about) is not possible to reserve.

In IDNA2008, the ascii version and unicode version of a domain name are =
1:1 mappings and the transformation can be done however many times you =
want.

This because the mapping is _removed_ from IDNA2008, so IF one is =
interested in doing mappings, that is to be done before IDNA2008 is =
applied. Anything "inside" IDNA2008 consists of strings either in their =
ASCII version (xn-- thing) or Unicode version (in Unicode). And it is =
possible to transform one to the other back and forth.

   Patrik


--Apple-Mail=_44C93124-DA30-4A66-92E9-386DF3ED9649
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUhT3rrMabGguI180RAtJYAJ48hrsSehnEMN+eptxwnQUEtbhDygCgiaLK
BpqY3XvFNsc5TzF9NamVFOQ=
=ojq3
-----END PGP SIGNATURE-----

--Apple-Mail=_44C93124-DA30-4A66-92E9-386DF3ED9649--


From nobody Wed Dec 10 20:36:58 2014
Return-Path: <peter@andyet.net>
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 BE8CD1A8788 for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 20:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 JxiLTxm064jX for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 20:36:56 -0800 (PST)
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5081A701B for <precis@ietf.org>; Wed, 10 Dec 2014 20:36:56 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id l13so8230508iga.9 for <precis@ietf.org>; Wed, 10 Dec 2014 20:36:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KqcQia9BRoJ6iOCiETdWQXqMiwX9hPQs8AnuIfSUFdo=; b=KQKCQgUa9ZCY5IUDmmlVEGd9yOUITISKiOqOzxrK9dZubfGCKHnRmx+deJpMLUW2UX sfh3NydLfZPd3N/OAXrA2Ua8x3trCvYYvE86r+Ncf9tpXcwwHktcg2PXA0nPZpMnInVr W2o2ccjN/xeV4ithBsVjI3DSm1HxYqKWuD1eVI/1CkZlU21BGKA+TSIAfMElMBs/sXlB F03mfVVVqspO3T8ULT5IsJsEaKSrLHYafWoo3jWCAHGIfvy5dri0JnlBkRLBBd1Kogeg EGmyqTz6x5ScT1GqoFJTwyO4kYMUYEmlHn0rb/XivP3EJww88HnHLTXZmJcvNiEa8z8L tuZA==
X-Gm-Message-State: ALoCoQmPn4cDJY34cVPGphg3H6Y6FeVF+B/VUVOWywHuFDD297jU/ylqsUaVZ4Derv9wGHi4k00t
X-Received: by 10.50.93.6 with SMTP id cq6mr11823783igb.7.1418272615795; Wed, 10 Dec 2014 20:36:55 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d1sm361459igz.13.2014.12.10.20.36.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 20:36:54 -0800 (PST)
Message-ID: <54891F66.2060106@andyet.net>
Date: Wed, 10 Dec 2014 21:36:54 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>,  precis@ietf.org
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net>
In-Reply-To: <54851FAD.4040009@andyet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/rOFxdKMggg7oG3XY2ahipq5hiS0
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 04:36:57 -0000

One specific question below...

On 12/7/14, 8:49 PM, Peter Saint-Andre - &yet wrote:
> On 11/23/14, 7:58 AM, Patrik Fältström wrote:
>
>>> 4.2.1.  Valid
>>>
>>>
>>> o  Code points traditionally used as letters and numbers in
>>> writing systems, i.e., the LetterDigits ("A") category first
>>> defined in [ RFC5892] and listed here under Section 8.1 .
>>>
>>> o  Code points in the range U+0021 through U+007E, i.e., the
>>> (printable) ASCII7 ("K") rule defined under Section 8.11 .  These
>>> code points are "grandfathered" into PRECIS and thus are valid even
>>> if they would otherwise be disallowed according to the
>>> property-based rules specified in the next section.
>>>
>>> Note: Although the PRECIS IdentifierClass re-uses the LetterDigits
>>> category from IDNA2008, the range of characters allowed in the
>>> IdentifierClass is wider than the range of characters allowed in
>>> IDNA2008.  The main reason is that IDNA2008 applies the Unstable
>>> category before the LetterDigits category, thus disallowing
>>> uppercase characters, whereas the IdentifierClass does not apply
>>> the Unstable category.
>>
>> You must remove the code points of class ("C") in RFC5892.
>
> The only difference between class "C" (IDNA2008) and class "M" (PRECIS)
> is that in PRECIS we allow white space code points in the FreeformClass.
> Thus we use "C", not "M".
>
>> Or to state things differently. If one look at the Unicode tables,
>> the following combination of matches exists for code points that
>> matches category "A" and at least one more category, for Unicode
>> 7.0.0:
>>
>> AB ABC ABF AC ACI AD AE AF AI
>>
>> There are several of these combinations that is given this definition
>> is valid which I would not say is recommended for use for
>> identifiers.
>
> OK, I will look at this more closely.

I don't quite understand your concern here.

Are you saying that there are code points that match, say, the 
LetterDigits category ("A") and the IgnorableProperties category ("C") 
and the OldHangulJamo category ("I")?

Peter



From nobody Wed Dec 10 21:02:22 2014
Return-Path: <internet-drafts@ietf.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 8B08D1A0D29; Wed, 10 Dec 2014 21:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 N0SRQmTSwMbt; Wed, 10 Dec 2014 21:01:53 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8171A8F51; Wed, 10 Dec 2014 21:01:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141211050110.32286.39995.idtracker@ietfa.amsl.com>
Date: Wed, 10 Dec 2014 21:01:10 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/EqTgWoU1RqUThzgMMN8YLHRtOhM
Cc: precis@ietf.org
Subject: [precis] I-D Action: draft-ietf-precis-framework-21.txt
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 05:02:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF.

        Title           : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
        Authors         : Peter Saint-Andre
                          Marc Blanchet
	Filename        : draft-ietf-precis-framework-21.txt
	Pages           : 37
	Date            : 2014-12-10

Abstract:
   Application protocols using Unicode characters in protocol strings
   need to properly handle such strings in order to enforce
   internationalization rules for strings placed in various protocol
   slots (such as addresses and identifiers) and to perform valid
   comparison operations (e.g., for purposes of authentication or
   authorization).  This document defines a framework enabling
   application protocols to perform the preparation, enforcement, and
   comparison of internationalized strings ("PRECIS") in a way that
   depends on the properties of Unicode characters and thus is agile
   with respect to versions of Unicode.  As a result, this framework
   provides a more sustainable approach to the handling of
   internationalized strings than the previous framework, known as
   Stringprep (RFC 3454).  This document obsoletes RFC 3454.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-framework/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-framework-21

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-21


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Dec 10 21:02:31 2014
Return-Path: <internet-drafts@ietf.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 EF3B91ACD1B for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 21:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 etq2P8fkV1Tg; Wed, 10 Dec 2014 21:02:13 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1271A0AF1; Wed, 10 Dec 2014 21:01:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org,  precis@ietf.org, presnick@qti.qualcomm.com
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141211050114.32286.61748.idtracker@ietfa.amsl.com>
Date: Wed, 10 Dec 2014 21:01:14 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/djo1f6ZEFZDUwQWivZD9dhtq5v4
Subject: [precis] New Version Notification - draft-ietf-precis-framework-21.txt
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 05:02:30 -0000

A new version (-21) has been submitted for draft-ietf-precis-framework:
http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-21.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-framework/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-21

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Wed Dec 10 21:05:11 2014
Return-Path: <peter@andyet.net>
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 0F1FC1A88C1 for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 21:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 GvsR9U667Bre for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 21:04:50 -0800 (PST)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B464C1A020D for <precis@ietf.org>; Wed, 10 Dec 2014 21:04:49 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id rp18so3999217iec.24 for <precis@ietf.org>; Wed, 10 Dec 2014 21:04:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=hLMgpY5b43nCyCf1yzqxpS+qVYyqyy7PvNZ99AgbBPQ=; b=GEboq7DnRHPpXT2sahJUyEchsL8Tw/SoRQ5DY1Ndxr62og652dyXBcUZd0jEK9o94s kEgBmPrhe3DwlxTAwMHmMavn9zsagDLGM9IIJWpHaT2d+D56cm8T/mPL/pDvyP+mKzrj 1nNjXUQBqVwZvcttiDq2ofjMKd5IN/rTcWx7JY8V/8mZEM7dc5PYIhDKbEQb4xSPgl0o fOBgUhLA9EMDQWnVR/wEB6hQmEwuT09KkOBeNMP2hBENHIs0Nz7QlqYmY2AGRIyOQca7 xrwEfsDmhl/9KuT8tHSmfh6ow/3jlEFdLVt3B6oSMUGlilyOGpp6EzBMAkqCrqbQeVAe Zm7A==
X-Gm-Message-State: ALoCoQkzbw/lgv2U5p1+YlvZN7a23ycuPHPbIpW6b+Zjw3jEnpu7uOPw+1jfA0j35UnHKzc8S94f
X-Received: by 10.107.162.134 with SMTP id l128mr7913603ioe.65.1418274288952;  Wed, 10 Dec 2014 21:04:48 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id e3sm54576iod.0.2014.12.10.21.04.48 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 21:04:48 -0800 (PST)
Message-ID: <548925EF.50206@andyet.net>
Date: Wed, 10 Dec 2014 22:04:47 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "precis@ietf.org" <precis@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ZjbN7LbHNrmX_2wdPA5spBw3P3E
Subject: [precis] framework-21
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 05:05:07 -0000

I have tried my best to address Patrik's excellent feedback in version 
21 of the framework (just submitted). Unfortunately I am extremely short 
on time right now and I might have missed a few things, but I wanted to 
address the main points he raised as soon as I could.

https://datatracker.ietf.org/doc/draft-ietf-precis-framework/

http://tools.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-21.txt

Peter



From nobody Wed Dec 10 22:22:51 2014
Return-Path: <paf@frobbit.se>
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 040B21A88BE for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 22:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.27
X-Spam-Level: 
X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UPPERCASE_50_75=0.791] 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 9zxgvpuTgSTG for <precis@ietfa.amsl.com>; Wed, 10 Dec 2014 22:22:48 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2BE1A19E3 for <precis@ietf.org>; Wed, 10 Dec 2014 22:22:48 -0800 (PST)
Received: from dyn-fg122.sth.netnod.se (dyn-fg122.sth.netnod.se [77.72.226.122]) by mail.frobbit.se (Postfix) with ESMTPSA id AB0ED2276F; Thu, 11 Dec 2014 07:22:45 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D959DD18-80DE-46EA-BB23-A8CB4C0656FB"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b3
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <54891F66.2060106@andyet.net>
Date: Thu, 11 Dec 2014 07:22:45 +0100
Message-Id: <11D38E5F-ED9C-4FA1-831A-6BF87A6FA619@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54891F66.2060106@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/3nkmCNk9_99IKb5tCfjcxiwT-do
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 06:22:51 -0000

--Apple-Mail=_D959DD18-80DE-46EA-BB23-A8CB4C0656FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


> On 11 dec 2014, at 05:36, Peter Saint-Andre - &yet <peter@andyet.net> =
wrote:
>=20
> Are you saying that there are code points that match, say, the =
LetterDigits category ("A") and the IgnorableProperties category ("C") =
and the OldHangulJamo category ("I")?

Yes. There are in fact two codepoints that matches all of A, C and I at =
the same time. U+115F and U+1160.

Hope this below give you some data. The file allcodepoints.txt is one I =
have produced with one of the software packages I have written as part =
of my role as appointed expert re. IANA and IDNA. The file is in this =
example generated for Unicode 7.0.0.

#for i in AB ABC ABF AC ACI AD AE AF AI; do
#echo $i
#grep ";$i;" allcodepoints.txt | wc -l
#grep ";$i;" allcodepoints.txt | head -5
#done
AB
    4479
0041;DISALLOWED;I;AB;LATIN CAPITAL LETTER A
0042;DISALLOWED;I;AB;LATIN CAPITAL LETTER B
0043;DISALLOWED;I;AB;LATIN CAPITAL LETTER C
0044;DISALLOWED;I;AB;LATIN CAPITAL LETTER D
0045;DISALLOWED;I;AB;LATIN CAPITAL LETTER E
ABC
       2
3164;DISALLOWED;I;ABC;HANGUL FILLER
FFA0;DISALLOWED;I;ABC;HALFWIDTH HANGUL FILLER
ABF
       2
00DF;PVALID;I;ABF;LATIN SMALL LETTER SHARP S
03C2;PVALID;I;ABF;GREEK SMALL LETTER FINAL SIGMA
AC
     262
034F;DISALLOWED;I;AC;COMBINING GRAPHEME JOINER
17B4;DISALLOWED;I;AC;KHMER VOWEL INHERENT AQ
17B5;DISALLOWED;I;AC;KHMER VOWEL INHERENT AA
180B;DISALLOWED;I;AC;MONGOLIAN FREE VARIATION SELECTOR ONE
180C;DISALLOWED;I;AC;MONGOLIAN FREE VARIATION SELECTOR TWO
ACI
       2
115F;DISALLOWED;I;ACI;HANGUL CHOSEONG FILLER
1160;DISALLOWED;I;ACI;HANGUL JUNGSEONG FILLER
AD
      59
20D0;DISALLOWED;I;AD;COMBINING LEFT HARPOON ABOVE
20D1;DISALLOWED;I;AD;COMBINING RIGHT HARPOON ABOVE
20D2;DISALLOWED;I;AD;COMBINING LONG VERTICAL LINE OVERLAY
20D3;DISALLOWED;I;AD;COMBINING SHORT VERTICAL LINE OVERLAY
20D4;DISALLOWED;I;AD;COMBINING ANTICLOCKWISE ARROW ABOVE
AE
      36
0030;PVALID;I;AE;DIGIT ZERO
0031;PVALID;I;AE;DIGIT ONE
0032;PVALID;I;AE;DIGIT TWO
0033;PVALID;I;AE;DIGIT THREE
0034;PVALID;I;AE;DIGIT FOUR
AF
      30
0640;DISALLOWED;I;AF;ARABIC TATWEEL
0660;CONTEXTO;I;AF;ARABIC-INDIC DIGIT ZERO
0661;CONTEXTO;I;AF;ARABIC-INDIC DIGIT ONE
0662;CONTEXTO;I;AF;ARABIC-INDIC DIGIT TWO
0663;CONTEXTO;I;AF;ARABIC-INDIC DIGIT THREE
AI
     355
1100;DISALLOWED;I;AI;HANGUL CHOSEONG KIYEOK
1101;DISALLOWED;I;AI;HANGUL CHOSEONG SSANGKIYEOK
1102;DISALLOWED;I;AI;HANGUL CHOSEONG NIEUN
1103;DISALLOWED;I;AI;HANGUL CHOSEONG TIKEUT
1104;DISALLOWED;I;AI;HANGUL CHOSEONG SSANGTIKEUT
#

   Patrik


--Apple-Mail=_D959DD18-80DE-46EA-BB23-A8CB4C0656FB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUiTg2rMabGguI180RAnTqAJoCfP13Ynw9PreWuKTf3wzlfe7UiQCcCGyF
V+wAXITPStqAJ1OXjiieKQ8=
=zIWe
-----END PGP SIGNATURE-----

--Apple-Mail=_D959DD18-80DE-46EA-BB23-A8CB4C0656FB--


From nobody Thu Dec 11 08:43:49 2014
Return-Path: <peter@andyet.net>
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 49F901A7020 for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 08:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 6hUs0PCzqO15 for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 08:43:46 -0800 (PST)
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A96E1A6FEF for <precis@ietf.org>; Thu, 11 Dec 2014 08:43:42 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id h15so8645556igd.8 for <precis@ietf.org>; Thu, 11 Dec 2014 08:43:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RJO5vsOlcdQtjjmzmfUp2CkbmA1BCA/Q3/lW18JglUo=; b=GLzvhhazYndG9raamSlXkhd4gOlxKc01ZZyuitT3V0bqqEn3sLLA9H1WFoYa933xjX m1gpOEsBTItLqHmV5Ik45MSCnRrD6GPq4hWDesMqc72Ri/+YoZ7gGOPy17tK9sfgdSCf orjLw1r9kzW+rOHbhO/4QdagdxefPaFWjs9Y9+7fZvwQvjgBPdukKZGsfeDxO+xvwh1a zWKnB6ydfUtJfb7BhrHF4imZ1I8AU4g13HRKulshyuds5bOmlRT4q4DtDcY2Ym5Iby9O nAfr8i0zaoxd6XlESN57IaxTl/4IKKCqriIf2y4Bp1rHSysi9704AfiJOeC7HNYfiFB0 Ia0w==
X-Gm-Message-State: ALoCoQkTdn4dMAAAOViZ8XeVhRI07IuUhFJw1D9bM7G+0Ge0BXqL5qsJa+n2tLT6tCsd/lpZ94FI
X-Received: by 10.107.8.149 with SMTP id h21mr10497534ioi.74.1418316221276; Thu, 11 Dec 2014 08:43:41 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j82sm762620iod.12.2014.12.11.08.43.40 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 08:43:40 -0800 (PST)
Message-ID: <5489C9BB.2050505@andyet.net>
Date: Thu, 11 Dec 2014 09:43:39 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54891F66.2060106@andyet.net> <11D38E5F-ED9C-4FA1-831A-6BF87A6FA619@frobbit.se>
In-Reply-To: <11D38E5F-ED9C-4FA1-831A-6BF87A6FA619@frobbit.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/YjJMEaqZLNKMZNxRkTkYqabwkgo
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 16:43:47 -0000

On 12/10/14, 11:22 PM, Patrik Fältström wrote:
>
>> On 11 dec 2014, at 05:36, Peter Saint-Andre - &yet
>> <peter@andyet.net> wrote:
>>
>> Are you saying that there are code points that match, say, the
>> LetterDigits category ("A") and the IgnorableProperties category
>> ("C") and the OldHangulJamo category ("I")?
>
> Yes. There are in fact two codepoints that matches all of A, C and I
> at the same time. U+115F and U+1160.
>
> Hope this below give you some data. The file allcodepoints.txt is one
> I have produced with one of the software packages I have written as
> part of my role as appointed expert re. IANA and IDNA. The file is in
> this example generated for Unicode 7.0.0.

That's great, thank you.

Although it's good to know about this overlap, I am wondering if in 
practice it matters because in both IDNA2008 and PRECIS we specify the 
order of operations. Do you think we need to have an informational note 
about this in the framework, though?

Peter


From nobody Thu Dec 11 15:53:29 2014
Return-Path: <paf@frobbit.se>
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 28CE91A904A for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 15:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level: 
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 e6m6914eSMRl for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 15:53:25 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFD01A9040 for <precis@ietf.org>; Thu, 11 Dec 2014 15:53:24 -0800 (PST)
Received: from [192.168.43.179] (h88-129-208-210.dynamic.se.alltele.net [88.129.208.210]) by mail.frobbit.se (Postfix) with ESMTPSA id 6B66522834; Fri, 12 Dec 2014 00:53:22 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_77BCF027-11FB-4C0F-8887-5121E6BF5A34"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b3
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <5489C9BB.2050505@andyet.net>
Date: Fri, 12 Dec 2014 00:53:21 +0100
Message-Id: <41CBFE91-098F-4F7A-ABE2-F3D7F71A65D5@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54891F66.2060106@andyet.net> <11D38E5F-ED9C-4FA1-831A-6BF87A6FA619@frobbit.se> <5489C9BB.2050505@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/jVDsZP21rUvwDu8WKZ1U_2jRZMo
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Dec 2014 23:53:28 -0000

--Apple-Mail=_77BCF027-11FB-4C0F-8887-5121E6BF5A34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


> On 11 dec 2014, at 17:43, Peter Saint-Andre - &yet <peter@andyet.net> =
wrote:
>=20
> On 12/10/14, 11:22 PM, Patrik F=E4ltstr=F6m wrote:
>>=20
>>> On 11 dec 2014, at 05:36, Peter Saint-Andre - &yet
>>> <peter@andyet.net> wrote:
>>>=20
>>> Are you saying that there are code points that match, say, the
>>> LetterDigits category ("A") and the IgnorableProperties category
>>> ("C") and the OldHangulJamo category ("I")?
>>=20
>> Yes. There are in fact two codepoints that matches all of A, C and I
>> at the same time. U+115F and U+1160.
>>=20
>> Hope this below give you some data. The file allcodepoints.txt is one
>> I have produced with one of the software packages I have written as
>> part of my role as appointed expert re. IANA and IDNA. The file is in
>> this example generated for Unicode 7.0.0.
>=20
> That's great, thank you.
>=20
> Although it's good to know about this overlap, I am wondering if in =
practice it matters because in both IDNA2008 and PRECIS we specify the =
order of operations. Do you think we need to have an informational note =
about this in the framework, though?

Not as long as the _result_ of the actions you suggest leads to a stable =
result.

I.e. either your rules are stable (and leads to stable result) or not. =
Clarifying language that explain is not what you need in this case. =
Either the rules are clean or not.

   Patrik


--Apple-Mail=_77BCF027-11FB-4C0F-8887-5121E6BF5A34
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUii5yrMabGguI180RAjyLAJ0QuYGwz9LGDXxa12GqpC8EMON3aQCfTUd5
TNXpoe+m7/5JuruS4WxGS2o=
=GdQo
-----END PGP SIGNATURE-----

--Apple-Mail=_77BCF027-11FB-4C0F-8887-5121E6BF5A34--


From nobody Thu Dec 11 18:13:20 2014
Return-Path: <peter@andyet.net>
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 1A79E1A9150 for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 18:13:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 dwmj8PIvhwFl for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 18:13:16 -0800 (PST)
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE691A914D for <precis@ietf.org>; Thu, 11 Dec 2014 18:13:16 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id tr6so5873485ieb.7 for <precis@ietf.org>; Thu, 11 Dec 2014 18:13:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o4G+C1bPP/r7T07O3AGoZa6JkMU7H9Nw0xxeSr1IwOs=; b=E4HF8utbEWv2GUKk1fC2B8/Fv+drqlrTuzaZawXo2dXYxCPgkvPucXbk7ERcs5cnS8 Qq2qWfFVuWNmvyELT+Oa5TkSe9MLNAJ8QhYrVWLfPVoDZ8RQCtSC8LCONZeggIzD8/ld WctlxYpFx+1L4KUekceI7/Zwcy7/SgO526RwUDlqwGi9PQKyy8JOX4PwDmXJFjudSj25 gcOCEB0Bg6kjqOG+Ekjec4tmAdo+s0KL5wg7TysxjM0KIg6IZemvVUgkb8LgZyuVUtLj fqF+bMZivRBXM/ThzBRb/uSzMRT43D4Yw/Abv76oWWbwmioBz3N7Fr5F0bB8R1j1Mzbj ykfQ==
X-Gm-Message-State: ALoCoQnRM2k41wyOQHvOarK6JQdMSCvAz7gGLmf3C06D0Z0aZ1jFGgqY1ZO5Gq4rFCrFus+C5d3k
X-Received: by 10.107.8.149 with SMTP id h21mr13064374ioi.74.1418350395737; Thu, 11 Dec 2014 18:13:15 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id s10sm79806igr.2.2014.12.11.18.13.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 18:13:15 -0800 (PST)
Message-ID: <548A4F39.8040208@andyet.net>
Date: Thu, 11 Dec 2014 19:13:13 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54891F66.2060106@andyet.net> <11D38E5F-ED9C-4FA1-831A-6BF87A6FA619@frobbit.se> <5489C9BB.2050505@andyet.net> <41CBFE91-098F-4F7A-ABE2-F3D7F71A65D5@frobbit.se>
In-Reply-To: <41CBFE91-098F-4F7A-ABE2-F3D7F71A65D5@frobbit.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/oL6RmZxWVLNxP-PIpSffQJaUM5g
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Fri, 12 Dec 2014 02:13:18 -0000

On 12/11/14, 4:53 PM, Patrik Fältström wrote:
>
>> On 11 dec 2014, at 17:43, Peter Saint-Andre - &yet <peter@andyet.net> wrote:
>>
>> On 12/10/14, 11:22 PM, Patrik Fältström wrote:
>>>
>>>> On 11 dec 2014, at 05:36, Peter Saint-Andre - &yet
>>>> <peter@andyet.net> wrote:
>>>>
>>>> Are you saying that there are code points that match, say, the
>>>> LetterDigits category ("A") and the IgnorableProperties category
>>>> ("C") and the OldHangulJamo category ("I")?
>>>
>>> Yes. There are in fact two codepoints that matches all of A, C and I
>>> at the same time. U+115F and U+1160.
>>>
>>> Hope this below give you some data. The file allcodepoints.txt is one
>>> I have produced with one of the software packages I have written as
>>> part of my role as appointed expert re. IANA and IDNA. The file is in
>>> this example generated for Unicode 7.0.0.
>>
>> That's great, thank you.
>>
>> Although it's good to know about this overlap, I am wondering if in practice it matters because in both IDNA2008 and PRECIS we specify the order of operations. Do you think we need to have an informational note about this in the framework, though?
>
> Not as long as the _result_ of the actions you suggest leads to a stable result.
>
> I.e. either your rules are stable (and leads to stable result) or not. Clarifying language that explain is not what you need in this case. Either the rules are clean or not.

Indeed.

You highlight the following possibilities:

AB ABC ABF AC ACI AD AE AF AI

In PRECIS, we don't use categories B, C, D, and E.

Thus if we have concerns, they would be over AF (LetterDigits and 
Exceptions) and AI (LetterDigits and OldHangulJamo).

Yet the algorithm seems definitive:

    If .cp. .in. Exceptions Then Exceptions(cp);
    Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
    Else If .cp. .in. Unassigned Then UNASSIGNED;
    Else If .cp. .in. ASCII7 Then PVALID;
    Else If .cp. .in. JoinControl Then CONTEXTJ;
    Else If .cp. .in. OldHangulJamo Then DISALLOWED;
    Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED;
    Else If .cp. .in. Controls Then DISALLOWED;
    Else If .cp. .in. HasCompat Then ID_DIS or FREE_PVAL;
    Else If .cp. .in. LetterDigits Then PVALID;
    Else If .cp. .in. OtherLetterDigits Then ID_DIS or FREE_PVAL;
    Else If .cp. .in. Spaces Then ID_DIS or FREE_PVAL;
    Else If .cp. .in. Symbols Then ID_DIS or FREE_PVAL;
    Else If .cp. .in. Punctuation Then ID_DIS or FREE_PVAL;
    Else DISALLOWED;

The PRECIS framework doesn't allow classes or profiles or applications 
to change the order of operations within the algorithm. However, we 
could add normative language about that in the spec (which doesn't 
currently say that you MUST NOT change the order).

Peter



From nobody Thu Dec 11 18:19:44 2014
Return-Path: <peter@andyet.net>
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 ADB5C1A9143 for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 18:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 JBNdqa54htnu for <precis@ietfa.amsl.com>; Thu, 11 Dec 2014 18:19:39 -0800 (PST)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E319F1A9106 for <precis@ietf.org>; Thu, 11 Dec 2014 18:19:38 -0800 (PST)
Received: by mail-ig0-f171.google.com with SMTP id z20so736238igj.10 for <precis@ietf.org>; Thu, 11 Dec 2014 18:19:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x2KS4oGQlY13a6fW3I1MZSxoJdnp4xj8gZ8QqnkDqhs=; b=Zg32liMZVulpl2xnTnOHKgQt9oaAhfobwc3YakAj4nAKuOUu9sWtC4Pp+py4fs+3nz U6aUWATlyeLu4FF6ivWbELvcLD436K0Uz1G+YgCMEm0qSdAjV/BZe5zVgnOC1PFizvpX pu2oC+4SAFdGLgqYt0JfcyuOw3x1wgMJAV0gxILLN7rAapAt8Kzc/k+aRN9b2UAuXm7U 4h4rt9In6BadBINckQ0a3F1pFKFiuJSKNZCjj4jqBkBOCr8/4Bo0pcR7NLjmWwR0upq8 hfkC6aPvpUNdFofmGDAFDp8l4NLBJ/pHNY3C+d2PvWgxlDfWjpyUXqvbSXC/iCqRx/uo mL+g==
X-Gm-Message-State: ALoCoQn94ImcBCajFG2Ok6bfhgQtpckSUrIsD01JrFdfnG2n7+kzPOIPGFNx2SCozObWLZrwBY7Q
X-Received: by 10.107.32.5 with SMTP id g5mr13380670iog.20.1418350778361; Thu, 11 Dec 2014 18:19:38 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id nm13sm84785igb.5.2014.12.11.18.19.37 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 18:19:37 -0800 (PST)
Message-ID: <548A50B9.20103@andyet.net>
Date: Thu, 11 Dec 2014 19:19:37 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net> <54891F66.2060106@andyet.net> <11D38E5F-ED9C-4FA1-831A-6BF87A6FA619@frobbit.se> <5489C9BB.2050505@andyet.net> <41CBFE91-098F-4F7A-ABE2-F3D7F71A65D5@frobbit.se> <548A4F39.8040208@andyet.net>
In-Reply-To: <548A4F39.8040208@andyet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/tQIgj-guoPM8jSOYs-tMNmLKf7s
Cc: precis@ietf.org
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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: Fri, 12 Dec 2014 02:19:40 -0000

On 12/11/14, 7:13 PM, Peter Saint-Andre - &yet wrote:
> On 12/11/14, 4:53 PM, Patrik Fältström wrote:
>>
>>> On 11 dec 2014, at 17:43, Peter Saint-Andre - &yet <peter@andyet.net>
>>> wrote:
>>>
>>> On 12/10/14, 11:22 PM, Patrik Fältström wrote:
>>>>
>>>>> On 11 dec 2014, at 05:36, Peter Saint-Andre - &yet
>>>>> <peter@andyet.net> wrote:
>>>>>
>>>>> Are you saying that there are code points that match, say, the
>>>>> LetterDigits category ("A") and the IgnorableProperties category
>>>>> ("C") and the OldHangulJamo category ("I")?
>>>>
>>>> Yes. There are in fact two codepoints that matches all of A, C and I
>>>> at the same time. U+115F and U+1160.
>>>>
>>>> Hope this below give you some data. The file allcodepoints.txt is one
>>>> I have produced with one of the software packages I have written as
>>>> part of my role as appointed expert re. IANA and IDNA. The file is in
>>>> this example generated for Unicode 7.0.0.
>>>
>>> That's great, thank you.
>>>
>>> Although it's good to know about this overlap, I am wondering if in
>>> practice it matters because in both IDNA2008 and PRECIS we specify
>>> the order of operations. Do you think we need to have an
>>> informational note about this in the framework, though?
>>
>> Not as long as the _result_ of the actions you suggest leads to a
>> stable result.
>>
>> I.e. either your rules are stable (and leads to stable result) or not.
>> Clarifying language that explain is not what you need in this case.
>> Either the rules are clean or not.
>
> Indeed.
>
> You highlight the following possibilities:
>
> AB ABC ABF AC ACI AD AE AF AI
>
> In PRECIS, we don't use categories B, C, D, and E.
>
> Thus if we have concerns, they would be over AF (LetterDigits and
> Exceptions) and AI (LetterDigits and OldHangulJamo).
>
> Yet the algorithm seems definitive:
>
>     If .cp. .in. Exceptions Then Exceptions(cp);
>     Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
>     Else If .cp. .in. Unassigned Then UNASSIGNED;
>     Else If .cp. .in. ASCII7 Then PVALID;
>     Else If .cp. .in. JoinControl Then CONTEXTJ;
>     Else If .cp. .in. OldHangulJamo Then DISALLOWED;
>     Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED;
>     Else If .cp. .in. Controls Then DISALLOWED;
>     Else If .cp. .in. HasCompat Then ID_DIS or FREE_PVAL;
>     Else If .cp. .in. LetterDigits Then PVALID;
>     Else If .cp. .in. OtherLetterDigits Then ID_DIS or FREE_PVAL;
>     Else If .cp. .in. Spaces Then ID_DIS or FREE_PVAL;
>     Else If .cp. .in. Symbols Then ID_DIS or FREE_PVAL;
>     Else If .cp. .in. Punctuation Then ID_DIS or FREE_PVAL;
>     Else DISALLOWED;
>
> The PRECIS framework doesn't allow classes or profiles or applications
> to change the order of operations within the algorithm. However, we
> could add normative language about that in the spec (which doesn't
> currently say that you MUST NOT change the order).

That is, I would propose this change in Section 8...

OLD
    The algorithm to calculate the value of the derived property is as
    follows:

NEW
    The algorithm to calculate the value of the derived property is as
    follows (implementations MUST NOT modify the order of operations
    within this algorithm, since doing so would cause inconsistent
    results across implementations):

Peter


From nobody Tue Dec 23 17:41:01 2014
Return-Path: <internet-drafts@ietf.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 5846B1A701D; Tue, 23 Dec 2014 17:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 MV62mt7cjyBb; Tue, 23 Dec 2014 17:40:56 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BDA1A8788; Tue, 23 Dec 2014 17:40:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141224014055.7813.48912.idtracker@ietfa.amsl.com>
Date: Tue, 23 Dec 2014 17:40:55 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ybF9rn9ms38xMQTwE9V77Y6GSJU
Cc: precis@ietf.org
Subject: [precis] I-D Action: draft-ietf-precis-nickname-14.txt
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 24 Dec 2014 01:40:57 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF.

        Title           : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
        Author          : Peter Saint-Andre
	Filename        : draft-ietf-precis-nickname-14.txt
	Pages           : 9
	Date            : 2014-12-23

Abstract:
   This document describes methods for handling Unicode strings
   representing nicknames.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-nickname-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Dec 23 18:14:40 2014
Return-Path: <internet-drafts@ietf.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 198C81A883B; Tue, 23 Dec 2014 18:14:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Mf3oXKL3W9zc; Tue, 23 Dec 2014 18:14:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3601A8832; Tue, 23 Dec 2014 18:14:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141224021435.19890.71444.idtracker@ietfa.amsl.com>
Date: Tue, 23 Dec 2014 18:14:35 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/7mmV2ePPZQU_m-6CHVhw17FVhhw
Cc: precis@ietf.org
Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-13.txt
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 24 Dec 2014 02:14:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF.

        Title           : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
        Authors         : Peter Saint-Andre
                          Alexey Melnikov
	Filename        : draft-ietf-precis-saslprepbis-13.txt
	Pages           : 22
	Date            : 2014-12-23

Abstract:
   This document describes methods for handling Unicode strings
   representing usernames and passwords.  This document obsoletes RFC
   4013.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Dec 23 18:59:14 2014
Return-Path: <peter@andyet.net>
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 E3FBA1A897B for <precis@ietfa.amsl.com>; Tue, 23 Dec 2014 18:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 eaQKvi1kSR2c for <precis@ietfa.amsl.com>; Tue, 23 Dec 2014 18:59:10 -0800 (PST)
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C7D1A8714 for <precis@ietf.org>; Tue, 23 Dec 2014 18:59:10 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id y20so7014485ier.32 for <precis@ietf.org>; Tue, 23 Dec 2014 18:59:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H0jvjzpnb+5t3w61itMwEyY15+QoyALd7YZ7FVzzPMs=; b=HVHqOZ6kkK+jFb+YPNd4oAIQ1BdmJL3Ji7gzeZY2sVMuTtfGDsiglp3WUJCDiYIyM4 3Sv/gYLMc0tOPhSdzLi3VopcC3N0tIqkGPjK6UdE8Ia+hZfV8hLKlBAkMhE2IQOqoX7y 1NU7+A79r2zclFK8ygqabna4BBgHrdsztyhnhrELDRi+IUDhWSz/7xoZQuAMyty1s324 HE4PmxvXwm+B8ZfGCCqRz3MYOh/W91AdE+b9od5P8Sx0/2TEBaj9e+rHt9GX2StHDqpe T//wKlZtbmf0B8FHQWdEqA+F39nqqP+EUzqwFh2p38etbIIwyLjWDF5sbw/U7j2A3hMF nWCQ==
X-Gm-Message-State: ALoCoQle/3D/TnIyVdAWiUrspkaJ4EIyw896qm1gb5h8wIVXOzwjMXdw+4B5bWQHyOz4z+n3uivO
X-Received: by 10.50.67.102 with SMTP id m6mr24750250igt.4.1419389949443; Tue, 23 Dec 2014 18:59:09 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id r7sm7191088igg.20.2014.12.23.18.59.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 18:59:08 -0800 (PST)
Message-ID: <549A2BFB.1060401@andyet.net>
Date: Tue, 23 Dec 2014 19:59:07 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, =?ISO-8859-1?Q?Patrik_?= =?ISO-8859-1?Q?F=E4ltstr=F6m?= <paf@frobbit.se>, precis@ietf.org
References: <13AD33F4-1741-472E-8423-1B0302734325@frobbit.se> <54851FAD.4040009@andyet.net>
In-Reply-To: <54851FAD.4040009@andyet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Y0A9NrBiVRFE7OW_rT9QFhgUd2Q
Subject: Re: [precis] Review of current document draft-ietf-precis-framework-20
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: <http://www.ietf.org/mail-archive/web/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, 24 Dec 2014 02:59:12 -0000

On 12/7/14, 8:49 PM, Peter Saint-Andre - &yet wrote:
> On 11/23/14, 7:58 AM, Patrik Fältström wrote:
>> I have on request from the chairs done a review of three Precis
>> documents. Here is the review of draft-ietf-precis-framework-20.
>
> Patrik, many thanks for the thorough review!
>
>> The review has focused on the use of Unicode and the relationship
>> with IDNA2008.
>>
>> You see my comments below.
>>
>> Best, Patrik Fältström
>>
>>> draft-ietf-precis-framework-20
>>>
>>> Abstract
>>>
>>> Application protocols using Unicode characters in protocol strings
>>> need to properly handle such strings in order to enforce
>>> internationalization rules for strings placed in various protocol
>>> slots (such as addresses and identifiers) and to perform valid
>>> comparison operations (e.g., for purposes of authentication or
>>> authorization).  This document defines a framework enabling
>>> application protocols to perform the preparation, enforcement, and
>>> comparison of internationalized strings ("PRECIS") in a way that
>>> depends on the properties of Unicode characters and thus is agile
>>> with respect to versions of Unicode.  As a result, this framework
>>> provides a more sustainable approach to the handling of
>>> internationalized strings than the previous framework, known as
>>> Stringprep ( RFC 3454).  This document obsoletes RFC 3454 .
>>
>> Explanation on what my review is concentrating on:
>>
>> When using a character set like Unicode where things like
>> transformation, comparisons etc, the actual transformation can happen
>> in multiple locations in the architecture, and what is needed is for
>> applications to understand what format the strings are that are
>> received and what format strings are expected to be in when being
>> sent. Of course the principle of "be liberal in what you accept, and
>> conservative in what you send" is very important.
>>
>> A simplified sketch of the architecture is as follows:
>>
>> 1. [A] sends a string to [B] for storage
>>
>> 2. [C] send a string to be for lookup, which implies matching
>> algorithm is applied
>>
>> 3. If there is a match, data is sent back to [C]
>>
>> In this very simple way of looking at the issues the questions
>> include:
>>
>> A. What Unicode code points should [A] accept as input
>>
>> B. What transformation is [A] expected to do?
>>
>> C. What transformation is [A] allowed to do?
>>
>> D. What Unicode code points is [A] allowed to send to [B]?
>>
>> E. What Unicode code points can [B] expect from [A]?
>>
>> F. What transformation is [B] expected to do on data sent from [A]
>> before data is stored in the database?
>>
>> : :
>>
>> I.e. it must be as clear as possible for each one of the parties A, B
>> and C what they are expected to do, what they must (and must not)
>> do.
>
> For the profiles and application usages that go along with the framework
> (draft-ietf-precis-saslprepbis, draft-ietf-precis-nickname,
> draft-ietf-xmpp-6122bis), we have tried to address the considerations
> you raise. However, I think that in several places we could do a better
> job, such as:
>
> i. Explain not only what entities are expected to do, but also what they
> are allowed to do.
>
> ii. Specify what various using applications need to do (e.g., I don't
> think we've made that fully clear in the saslprepbis and nickname
> documents, although I think it is very clear in 6122bis).
>
> These are matters that we can focus on during WGLC for those specs, I
> think.

I have updated the saslprepbis and nickname specs in an attempt to 
address these issues:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-13.txt

http://tools.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-14.txt

Peter

-- 
Peter Saint-Andre
https://andyet.com/