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
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
