[precis] Enforcement as an Idempotent operation

William Fisher <william.w.fisher@gmail.com> Wed, 12 October 2016 19:56 UTC

Return-Path: <william.w.fisher@gmail.com>
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 CA16312958F for <precis@ietfa.amsl.com>; Wed, 12 Oct 2016 12:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 y_q4iJiAWOo1 for <precis@ietfa.amsl.com>; Wed, 12 Oct 2016 12:56:23 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C0C12958D for <precis@ietf.org>; Wed, 12 Oct 2016 12:56:23 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id q192so62517776iod.0 for <precis@ietf.org>; Wed, 12 Oct 2016 12:56:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=qDBap/ULZgS21zpskreFtBkLH2ad3IijRNY65kdCkEo=; b=0TdJmzJ5av+bU6GO/ok2mbnBCbcZpTPZsCjJb6vcANZXdUucAPTN92UJmRzf3U4IbM BcAIcChrRf5ToeaHY/2mBKmUW//a79fGEeBp89ZE81d+raeAzP8Wo40ys9dJFR1ZINEL irZ6s4y7Yc3VzPdddFchhtzmGABX7unxURbLcbZUBlms5rpRymtbPioVaWaqiRPLV4zJ KfS4bHE8JIAS3ugFcPus6FaK1Xl8LS/skEQUUXDaGP4I/tYUFRZCckddQB09URw9FyFb FQK7Sta2lTzdJOPzIrZjnpHlGrXCR+cnbAvZ3Fe1FttEjkC0/tcUl3RTicIeI2o6AaY3 QtxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qDBap/ULZgS21zpskreFtBkLH2ad3IijRNY65kdCkEo=; b=csZY85ETsRTeq1RgN/3s54doQgtbatKn4i/NjDwvwKOQr3AzU00nZhRBFJNfM54eum 8WzLGRJIUqcuUS6++gZpJVSvinYP46zsvWdJcpD8uWB9qpQkIt7NGNfu60q4E3d/NEtw kr41bZe8ynF+1bLFEEAqwpQuqtWPVsd0zw93bIPoYiZa9xgMEaYKoAwP0LnpbllUxWPL JKY4ouHDx+tMvHqhLWyb86ja40Zk+mEKMlr3psdpkyAaqpj1TBr1QP03wgXAwUHEDhV7 Ba/zRTd8T7wNGBJkoGeHaUqDCNYPlyBsYyyk2S1GG2C7zzkA6s+cXHBZs0wKpq/tMoVS knMw==
X-Gm-Message-State: AA6/9Rmc9cRmTPRVYxm1+lHwlDvs6py5ar0vnp/De20P2Mx/0ch1zGhU6KpUxLMmRgis6GPbqaik4zuDmk58qw==
X-Received: by 10.107.18.228 with SMTP id 97mr3132915ios.41.1476302182295; Wed, 12 Oct 2016 12:56:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.95.42 with HTTP; Wed, 12 Oct 2016 12:56:21 -0700 (PDT)
From: William Fisher <william.w.fisher@gmail.com>
Date: Wed, 12 Oct 2016 12:56:21 -0700
Message-ID: <CAHVjMKHVvmS6jty3-jwnnuqy-xdw-xY2j+5ExLRr6tXCMRbC2Q@mail.gmail.com>
To: precis@ietf.org
Content-Type: multipart/alternative; boundary="001a113fbb4028360a053eb063ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/OUAXe20mobpk3HEgTgVG3PQ4d5s>
Subject: [precis] Enforcement as an Idempotent operation
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, 12 Oct 2016 19:56:25 -0000

Should enforcing a string using PRECIS be idempotent?  If I apply the
enforce operation to a string twice, should I get the same result as
applying it just once?

The nickname profile is NOT idempotent for some inputs.

1. Certain characters are NFKC normalized to sequences with ASCII spaces.
This can lead to nicknames that begin with a space or contain adjacent
interior spaces that are removed if you apply the nickname profile again.

  U+00A8  =>  U+0020 U+0308  =>  U+0308

 2. Some characters can be further case mapped after NFKC normalization.

  U+1F11  => (K) => (k)

I also noticed that the RFC 7700 has case-mapping defined only when
comparing nicknames.  I thought this was confusing. I didn't understand why
username is split into two profiles (CasePreserved and CaseMapped), but
nickname is not.

If not all PRECIS profiles are idempotent, it would help to mention this in
the IANA Profile registry, e.g.

   Idempotent:  No.

As an implementer, I would prefer profiles that are idempotent.

Regards,
Bill