Re: [precis] [Technical Errata Reported] RFC8265 (5479)

John C Klensin <john-ietf@jck.com> Sun, 26 August 2018 17:42 UTC

Return-Path: <john-ietf@jck.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 072B7128CE4 for <precis@ietfa.amsl.com>; Sun, 26 Aug 2018 10:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no 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 vT8eqtCJEbHi for <precis@ietfa.amsl.com>; Sun, 26 Aug 2018 10:42:47 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E0F126CB6 for <precis@ietf.org>; Sun, 26 Aug 2018 10:42:47 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ftz3V-0001DX-2U; Sun, 26 Aug 2018 13:42:29 -0400
Date: Sun, 26 Aug 2018 13:42:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, stpeter@mozilla.com, alexey.melnikov@isode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, Marc.Blanchet@viagenie.ca
cc: precis@ietf.org
Message-ID: <CCF6935FC4B273CEC03B8D62@JcK-HP5.jck.com>
In-Reply-To: <20180826171956.75779B817D7@rfc-editor.org>
References: <20180826171956.75779B817D7@rfc-editor.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/uqSYVsb6n-OTTDjraJEZOkq3HvE>
Subject: Re: [precis] [Technical Errata Reported] RFC8265 (5479)
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 26 Aug 2018 17:42:49 -0000

Two observations:

(1) While the issue identified is relevant, it is not clear that
the broader interpretation of the statement that the proposed
erratum tries to eliminate is necessarily a bad idea.  The
general goal of all of these rules for identifiers (in PRECIS,
IDNA, and elsewhere) is to reduce cases of matching problems and
visual and other confusion (whether accidental or malicious).
In that context, any kind of hair-splitting -- seeing how
narrowly assorted rules and guidelines can be interpreted -- is
generally a bad idea and inconsistent with the intent of
whatever rules are laid out and the goals they represent.  

While treating userparts separately is almost certainly what the
text intended (just as IDNA2008 treats the labels of an FQDN
separately, in part because there was no other choice),
encouraging a username that (to use the example in the report)
will have Arabic-Indic Digits in one userpart and Eastern
Arabic-Indic Digits in another userpart is really just looking
for trouble.  I haven't taken the tome to do the analysis, but
my guess is that other examples abound, if only because users
are much more likely to look at an perceive whole usernames
rather than their components.

So, I would encourage caution here.  If this text is to be
clarified wrt narrowness of the rule, I think additional
comments about hair-splitting and protocol-lawyering (perhaps by
a pointer to text elsewhere in the document) would be in order.

(2) Personally, I found the original text clear --after all, the
sentence is only about userparts -- and the proposed
parenthetical clarification more confusing than the original
text was without it.  If there is actually a problem that needs
to be solved, I think a more comprehensive rewrite of the
paragraph is needed, not the proposed insertion.

best,
    john


--On Sunday, 26 August, 2018 10:19 -0700 RFC Errata System
<rfc-editor@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC8265,
> "Preparation, Enforcement, and Comparison of Internationalized
> Strings Representing Usernames and Passwords".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5479
> 
> --------------------------------------
> Type: Technical
> Reported by: Peter Occil <poccil14@gmail.com>
> 
> Section: 3.1
> 
> Original Text
> -------------
>    A userpart is allowed to contain only code
>    points that are allowed by the PRECIS IdentifierClass
> defined in    Section 4.2 of [RFC8264] and thus consists
> almost exclusively of    letters and digits.
> 
> 
> Corrected Text
> --------------
>    A userpart is allowed to contain only code
>    points that are allowed by the PRECIS IdentifierClass
> defined in    Section 4.2 of [RFC8264] (with respect to the
> userpart containing    them, not to the username as a whole)
> and thus consists almost     exclusively of letters and digits.
> 
> Notes
> -----
> Because certain characters in IdentifierClass are CONTEXTO and
> are not valid unless the whole string doesn't contain certain
> other characters (an example is ARABIC-INDIC DIGITS), it is
> unclear whether the context-specific rules apply to the whole
> username or to individual userparts.  However, section 3.5
> strongly suggests that usernames (as opposed to userparts) are
> the matter of a higher-level protocol than this RFC.  As a
> result, this erratum adds the text in parentheses to clarify
> that context-specific rules apply to individual userparts.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be
> verified or rejected. When a decision is reached, the
> verifying party   can log in to change the status and edit the
> report, if necessary. 
> 
> --------------------------------------
> RFC8265 (draft-ietf-precis-7613bis-11)
> --------------------------------------
> Title               : Preparation, Enforcement, and Comparison
> of Internationalized Strings Representing Usernames and
> Passwords Publication Date    : October 2017
> Author(s)           : P. Saint-Andre, A. Melnikov
> Category            : PROPOSED STANDARD
> Source              : Preparation and Comparison of
> Internationalized Strings Area                : Applications
> and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> precis mailing list
> precis@ietf.org
> https://www.ietf.org/mailman/listinfo/precis