Re: [precis] RFC 8264 / 8265 Order of rules

William Fisher <> Fri, 11 May 2018 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5A0B12D86A for <>; Fri, 11 May 2018 12:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IQDjeQPIa0QT for <>; Fri, 11 May 2018 12:04:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 302A6126D73 for <>; Fri, 11 May 2018 12:04:43 -0700 (PDT)
Received: by with SMTP id r25-v6so9368792lfd.1 for <>; Fri, 11 May 2018 12:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K9xZl/1QKxKDnig/BKZZCsXc3YpyHiaSLiHyeCbwEII=; b=sgA1YOqZ7R+1eUQv6tsfSS0WfxjKUlyNaM1+MKTgepZvBVdU3JDaqv8x+ICf5YDym+ 6h/so3Aou6nH9cv6jpt20BLqXLw5VbFKf07w0i6TbV1nJig6UgLdso4L9JiXOuCtqwwn WbK0hQAuRELd+3AZrWw1zXuQtvSxB+JOBLHO7T4BthieThKc7voVKqTMvGTa36riWpQo 8CdW0HCJUonnuVOEIiCxBgXlP06Ln5sVJEzgyZZ5xAaoiH1j3d3oj2pih3WYquppIYQj OjYwgMiSw+wowWkprBRNE1RJqE/bVa898YcpazrijIXv5qOBLxeUYQ3s1TCL1aigKwLM yKyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K9xZl/1QKxKDnig/BKZZCsXc3YpyHiaSLiHyeCbwEII=; b=RLmlEZFv10Z9KTqwLvw5L28xZwkt/pO5hI02ufzUi8W4JnV6ZoXRnrjxy7oxjOjYp5 M1ndEB1QxzkpGkHGc42of8M7OWXdIw694Q+2T8NLGA+Fuig4P+jwH8C487E2pqvXeeW4 ItkLxio20D5IicbDSFyD4725z/DKuq29lOpiYC1BdSomUIGID0BQayG2Se2VqQONQgRT 3GDn2fLrNgNaFCM5V0sahRLFLbDJG5/id2e52VGDytdh+8ZRIYL6fcMue0BC/iNz+E8P fg5Mg3M+x7QnmoKSjmBcggCyJhjtyRcsahe1EL7R1c11tUmQykxShkUF5Kj1p0il/mli hCmg==
X-Gm-Message-State: ALKqPweIu6U69D9xLnJ5rtSkdJlQWQySvo06R5c/Tdf7oFT4ZhU1J0LP pZYPrZLXqKalPLRBn92rUdioQI7ktuNOlhHKO5NX0MBE
X-Google-Smtp-Source: AB8JxZrNnjMsFzkXHUdmEaSPUN5ybJl59NIxgdJwOORhn+LAl3KtKLCKpZ/my4ZxVApFD5FYHD1oNa/4cTZOGfpNajs=
X-Received: by 2002:a2e:86d9:: with SMTP id n25-v6mr4805160ljj.18.1526065481281; Fri, 11 May 2018 12:04:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: William Fisher <>
Date: Fri, 11 May 2018 12:04:29 -0700
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [precis] RFC 8264 / 8265 Order of rules
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 May 2018 19:04:45 -0000

Hi Peter,

My thoughts on your proposed text is below.

I, for one, thought you did a good job with such a complex topic.


On Wed, May 9, 2018 at 2:57 PM Peter Saint-Andre <>


> 3.3.3.  Enforcement

>     An entity that performs enforcement according to this profile MUST
>     apply the following rules specified in Section 3.3.1 in the order
>     shown:

>     1.  Width Mapping Rule

>     2.  Case Mapping Rule

>     3.  Normalization Rule

>     4.  Directionality Rule

>     After all of the foregoing rules have been enforced, the entity MUST
>     ensure that the username is not zero bytes in length (this is done
>     after enforcing the rules to prevent applications from mistakenly
>     omitting a username entirely, because when internationalized strings
>     are accepted, a non-empty sequence of characters can result in a
>     zero-length username after canonicalization).

The output string still needs to be validated by the base "IdentifierClass"
before it can be said to conform to the UsernameCaseMapped profile.


     Finally, the entity MUST ensure that the username consists only of
Unicode code points that are explicitly allowed by the PRECIS
IdentifierClass defined in Section 4.2 of [RFC8264].

>     The result of the foregoing operations is an output string that
>     conforms to the UsernameCaseMapped profile.

In RFC 8265, the opening sentence of section "3.3.2 Preparation" implies
preparation is done before enforcement. This can lead to confusion:


    An entity that prepares an input string for subsequent enforcement
    according to this profile MUST proceed as follows (applying the steps
    in the order shown).


    An entity that performs preparation according to this profile MUST apply
the following steps in the order shown.

(I am wary of the separate preparation step as something that an
application developer might use. The notion mentioned in RFC 8264 (section
3) that a client might use the "preparation" step before handing the
protocol string to an authoritative server which does the "enforcement"
step is problematic for the Username profiles. It has been shown that
preparation by itself can reject strings that enforcement would have
accepted.  Example: '\u212b' under the UsernameCasePreserved profile.)