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

[Peter Saint-Andre <[e-mail]>]

Hi Sam,

Thanks for the feedback. Comments inline.

On 5/17/16 8:43 AM, Sam Whited wrote:
> 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.

Few people talk about "user parts" whereas the term "username" is 
familiar. Also RFC 4013 uses the term "user name".

> - 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).

The additional clarity can't hurt.

> - §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).

Let's remove it.

> - Table 2 says "A localpart of BLACK CHESS KING". Localpart is an XMPP
> term and should read "Userpart" in this context

Noted.

> - 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?

I think this would be good:

    3.  Case-Mapping Rule: There is no case mapping rule (because mapping
        uppercase and titlecase characters to their lowercase equivalents
        would lead to false positives and thus to reduced security).

> - §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.

In all of these documents we pointed to specific chapters of the Unicode 
7.0.0 version in a few cases, but I now think that's unnecessary so I'd 
prefer to remove it (and the note about MONGOLIAN
TODO SOFT HYPHEN (U+1806) is very much an edge case, so I think it's 
fine to remove that, too). And we're up to 9.0.0 now!

> - §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
> here.

First, these are some pretty obscure characters (SOFT HYPHEN, COMBINING 
GRAPHEME JOINER, MONGOLIAN TODO SOFT HYPHEN, ZERO WIDTH SPACE, etc.) 
that are extremely rare or nonexistent in usernames because I'd guess 
that very few input method editors even allow users to input these into 
a username registration flow (in general, they are invisible):

https://tools.ietf.org/html/rfc3454#appendix-B.1

Second, before migration, the characters would have been mapped to 
nothing, so that a username "StU+00ADPeter" if you will would have been 
registered as "StPeter" and not "StU+00ADPeter" (again, these are 
invisible characters), so that even if the user's client saved the 
username as "StU+00ADPeter" the service at which stringprep was applied 
would not have stored the username that way.

Third, after migration the username would be "StPeter" (not 
"StU+00ADPeter"), leading to the same behavior as before.

So I think we're safe here.

> - §6.2 Another possible place to update a Unicode 7 reference to 8.0.0

Or delete it. :-)

Thanks!

Peter