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
- [precis] [Technical Errata Reported] RFC8265 (547… RFC Errata System
- Re: [precis] [Technical Errata Reported] RFC8265 … John C Klensin