Re: [precis] order of operations

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

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576CB12D5B7 for <precis@ietfa.amsl.com>; Wed, 4 May 2016 15:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvzfl1t5C-el for <precis@ietfa.amsl.com>; Wed, 4 May 2016 15:52:21 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8912D5A3 for <precis@ietf.org>; Wed, 4 May 2016 15:52:20 -0700 (PDT)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 68F98E8241; Wed, 4 May 2016 17:01:59 -0600 (MDT)
To: Sam Whited <sam@samwhited.com>
References: <20160301221928.17792.35793.idtracker@ietfa.amsl.com> <1C1668EA-1734-4D90-82E6-3894ECB6407C@viagenie.ca> <56D61E27.40000@stpeter.im> <56F96A20.7030509@stpeter.im> <E5D59850-BE7B-4AB9-863F-E883DA9C4E13@viagenie.ca> <CECC45A3-B52F-489A-B64E-8D9B8DCDBD47@gmx.de> <572A5FB7.9000305@stpeter.im> <CAHbk4RLOc=LXWAR1E6Mrm99TPUzeFfWTSg=Xd1-On_cQRXDjAg@mail.gmail.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <572A7D23.4080404@stpeter.im>
Date: Wed, 4 May 2016 16:52:19 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAHbk4RLOc=LXWAR1E6Mrm99TPUzeFfWTSg=Xd1-On_cQRXDjAg@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/fERUjh40miIg3G7l2PYjCbuilKU>
Cc: precis@ietf.org
Subject: Re: [precis] order of operations
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2016 22:52:22 -0000

On 5/4/16 4:26 PM, Sam Whited wrote:
> On Wed, May 4, 2016 at 3:46 PM, Peter Saint-Andre <stpeter@stpeter.im>; wrote:
>> There's also the question of whether preparation / pre-processing is all
>> that useful. We added it so that constrained clients (e.g., clients that
>> can't realistically perform normalization) could avoid most of the problems
>> associated with having their strings rejected by a more powerful server that
>> actually does enforcement and comparison. Whether we really need to consider
>> such applications is another story.
>
> I'd be curious to know a "real world" use case for the preparation
> step optimization where enforcement is prohibitively expensive and
> comparison is not necessary (since comparison necessitates
> enforcement)?

The original suggestion (some years ago now) was browser-based clients 
that could not easily download the entire Unicode character database 
from a web server to the browser in order to do enforcement or 
comparison, but which could do something simpler like allow a user to 
create a username using a restricted repertoire of characters such as 
ASCII or "extended Latin".

Another example might be IoT clients running on microcontrollers with 
very limited memory and processor speed.

However, I have not seen benchmarks for such applications with respect 
to handling of internationalized strings.

> While benchmarking the implementation I did for Go I
> decided that it wasn't necessary to include a preparation step. Even
> on a heavily resource constrained server

Right, we've always figured that servers have more horsepower.

Peter