Re: [precis] I-D Action: draft-ietf-precis-7613bis-01.txt

Sam Whited <> Tue, 17 May 2016 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A04F12D6C7 for <>; Tue, 17 May 2016 07:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2c1OPMbQ07x for <>; Tue, 17 May 2016 07:43:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CB9512D6C2 for <>; Tue, 17 May 2016 07:43:51 -0700 (PDT)
Received: by with SMTP id x7so9621418qkd.3 for <>; Tue, 17 May 2016 07:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kuySvdoPTHw1gvUnCyxYi4TcsW8hj8nmib9sD2Np2tY=; b=gM/k/4Q2qwK7R03oi8X0oqwndUWDx1VGCLku0J+3Vx82EqMI6KM8gEY5S1V8+1/eu3 3E+EKG6nh07CWaWXGvAsFXfBJKmdUnlZ6qFywb1L+2frMmTU+yyjB7I6wdgH7Ez7rP4m qeY8WZXe8bkhPQ+O00xWGtfsqksRaJvBrMQ6I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kuySvdoPTHw1gvUnCyxYi4TcsW8hj8nmib9sD2Np2tY=; b=D0xOl3Ok/rOBRTleJy/zx09uHWZvl+vv+KRr0dR57IC2kue8jSB7mdMx90GBwSJTio oc12AKTKlw9rdFcganr3qT2QCb1INe88iSAZSzWfuBQic+C52Gx6DljqV6CFj5uiRrtO nsbq6SCgaz1AjLr18JSpYd493jhSIJcZKO0XrCh34oimk8+W/ovTU8ariGt+3kTdnLG4 ylEdRwPccnSRk5Na84fJk+mJK0yIndfu2aKbC1ZCFKtN/p1wVhCiZGXr91trIqbGEonO a61s1QcMzJPbVGdt4RFPf4Oa9CVzanTxPu9GuA0NxJwQfiV+IrwJh1sm+VMAB4Pg5V1j ortQ==
X-Gm-Message-State: AOPr4FU8hb2Ai3C/ld5iSdpyksi4pnmgExzF36i5Ip1QxxABve0BcSIoeJ5nYDCCX41za83daRzCkG0izP9U0w==
X-Received: by with SMTP id n24mr2009057qki.149.1463496230130; Tue, 17 May 2016 07:43:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 17 May 2016 07:43:10 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Sam Whited <>
Date: Tue, 17 May 2016 09:43:10 -0500
Message-ID: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [precis] I-D Action: draft-ietf-precis-7613bis-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 May 2016 14:43:53 -0000

Hi Peter et al.

Here are some notes I took while reading through the 7613 draft last
night; a few of them are actual issues, and others are probably just
me misunderstanding something:

- §3 defines Usernames, but since I was expecting a PRECIS profile
that defined a username it was confusing and I didn't really
understand it at first (until I got to §3.5 which explained the
difference between user parts and usernames). I'm not sure if this
could be made clearer or not, or if it was just me.
- Nit: §3.2.4 reads "An entity that performs comparison of two strings
according to this profile MUST prepare each string as specified in
Section 3.2.2 and then enforce the rules specified in Section 3.2.3".
Though redundant, it might make sense to modify it to read "and then
MUST enforce the rules" as well. Not sure that it matters, but it was
unclear to me on first reading (though I figured it out pretty
quickly; others probably wouldn't have been tripped up by this).
- §3.3.3 says that the Case-mapping rule should be performed as the
third step of Enforcement, but there is no case mapping rule for the
profile. This step should probably be removed or clarified (eg. is
case mapping optional, or is it required that you don't do it? I'm not
clear on how the absense of a rule works in a profile in general).
- Table 2 says "A localpart of BLACK CHESS KING". Localpart is an XMPP
term and should read "Userpart" in this context
- Nit: §4.2.2 lists the Case mapping rule as "Uppercase and titlecase
characters MUST NOT be mapped…", but other profiles just say there is
no case mapping rule. Similar to the above, if there's a difference
(especially within a single document), I think it could use some
clarification. Although I'm not sure that it matters, as
implementations are likely to just leave off case mapping either way,
which I think is the expected behavior in both cases?
- §6.1 references Unicode 7.0, if an update to the RFC is being
proposed, this could be changed to read 8.0.0 (or removed if the issue
is no longer a problem), or it could be left alone, probably doesn't
really matter.
- §6.1 also says "these code points would have been "mapped to
nothing" in stringprep, in practice a user would not notice the
difference if, upon migration to PRECIS, the code points are
removed.". Is this correct? Would this not make the username invalid
because the code points aren't allowed in the identifier class,
locking them out of their account? I'm probably missing something
- §6.2 Another possible place to update a Unicode 7 reference to 8.0.0


On Thu, May 5, 2016 at 12:42 PM,  <>; wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF.
>         Title           : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
>         Authors         : Peter Saint-Andre
>                           Alexey Melnikov
>         Filename        : draft-ietf-precis-7613bis-01.txt
>         Pages           : 25
>         Date            : 2016-05-05
> Abstract:
>    This document describes updated methods for handling Unicode strings
>    representing usernames and passwords.  The previous approach was
>    known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).
>    The methods specified in this document provide a more sustainable
>    approach to the handling of internationalized usernames and
>    passwords.  The preparation, enforcement, and comparison of
>    internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC
>    3454, and this document obsoletes RFC 7613.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> precis mailing list

Sam Whited
pub 4096R/54083AE104EA7AD3