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

Paul Crovella <paul.crovella@gmail.com> Wed, 14 March 2018 16:04 UTC

Return-Path: <paul.crovella@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 82F71126D73 for <precis@ietfa.amsl.com>; Wed, 14 Mar 2018 09:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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: 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 X5q6uinIyEG6 for <precis@ietfa.amsl.com>; Wed, 14 Mar 2018 09:04:38 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 C252B1252BA for <precis@ietf.org>; Wed, 14 Mar 2018 09:04:37 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id a22-v6so5607546lfg.9 for <precis@ietf.org>; Wed, 14 Mar 2018 09:04:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GhmI/3ceB9ksUfXme4DB9EdO7CrCBo9i83NeD9a4SqU=; b=lvGLQRxUeIze9ONopW0rzVYGFbyH+5KW1EVcRepoISFdbBVFUulkKv3Cw58XX/OnRy kxqvaWzwsME0WCkUg9amgi921Cagxe+kJVhCmuNB4FCe3sW5lSS1QAYbZljEUuE12IyI esRck1kzSoKw8stQcpahj4sTbTxI0U1FdbX5zS3BfZqe6BAi+LJAodfyykg6S4tuavex ARJsfhNmYaNKzu3w5DVSNxH0jmj9uV5pAf7bjcqaJSs/gHRPzxtrSo2eUFhnRr36poEK hz3+MNHLcCRetphmPAhvWATGZtAstHltuiCN+5oXTYsEshAHyNBnESaNFmWScMSh70+7 RXGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GhmI/3ceB9ksUfXme4DB9EdO7CrCBo9i83NeD9a4SqU=; b=DIkS2mKsYxonI77zEUwxia9sQb02JuqeNcoC37nW3Lth8GsQdDko7sXk2CWny7LZ+2 /io5Cotin8fRFi10oQEVWC7KyEoF5Oy7WMbybJaRQFUrWn0TXfa/5F7Jrq31kyWEYHH5 oWekiaxKvTh8wAJUapRgWdV7CPm9HMHng96fHb4I6V+BtbZF4P5jKuIkRazFHIvW05bi Y87nu26b7i+KRUP+DeWleFYOsN6kY2nvtvyQFsP6DV/DXLTMAvhWNaJLFAijxM34kWKb oqqrnJlB5nKsdfIlc0y1lrUBDIJ8MIwatrXSeH2yD5xfH0h9Acb5Gsbavbdb85+7DNM9 +QZA==
X-Gm-Message-State: AElRT7GrygACjAVaVdlh1Th/6m4gMOCLBDn+GsaFpXBzsBcHlCTgmLou u8R7M0WAH4yAnLLGKdHayfDf8KcNccz5dOKZ1iOC
X-Google-Smtp-Source: AG47ELuEnSU4RXLYGdjR0sCmHurCAQgExOW9rxCPN67NLsedRTexxL2VwZH08mBqg1CVzpJQFG5rAKZwVGOAw8T9U0Y=
X-Received: by 2002:a19:9cd2:: with SMTP id f201-v6mr3747947lfe.9.1521043475847; Wed, 14 Mar 2018 09:04:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.23.141 with HTTP; Wed, 14 Mar 2018 09:04:35 -0700 (PDT)
From: Paul Crovella <paul.crovella@gmail.com>
Date: Wed, 14 Mar 2018 09:04:35 -0700
Message-ID: <CAN2symj4jCLiM0y52Ey07rQSrh8ui4x9gZjmc53WbEYfWcoZtA@mail.gmail.com>
To: precis@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/NJfdSCLe1Ahs06ttp680X3Ok8BU>
Subject: Re: [precis] RFC 8264 / 8265 Order of rules
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
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, 14 Mar 2018 16:08:37 -0000

Followup question on
https://www.ietf.org/mail-archive/web/precis/current/msg01445.html

> implementations should follow the order of rules in Section 7 of RFC 8264.

Should string class validation then be moved from the preparation step
of all profiles to the end of enforcement? I don't know whether
there'd be a practical effect on profiles using the FreeformClass
string class (OpaqueString and RFC 8266's Nickname), or if there's the
potential to be, but it'd be nice to know where to do things.

Cheers,
Paul