On 3/28/16 1:58 PM, Christian Schudt wrote:
Hi,
let me raise one concern, which I had while implementing RFC 7564 and
7613. I’ve raised it already on this mailing list, but it got no
attention.
Sorry about that. Attention cycles come and go. Now that I'm working on
the bis drafts, I for one will make it a point to reply more quickly.
Instead of changing RFC 7564 §7 from MUST to SHOULD, why not changing
RFC 7613 §3.2.2 (and likely other Enforcement sections) to stick to
the order of rules?
Now that I look at RFC 7613 again more closely, I would say that it
doesn't really violate the order of operations in §7 of RFC 7564,
because for purposes of comparison it still applies the width-mapping
rule before all the other rules. However, it's also true that RFC 7613
applies the width-mapping rule before the "preparation" (or, perhaps
better, "pre-processing") steps of (a) ensuring that the string consists
only of Unicode code points that conform to the PRECIS IdentifierClass
and (b) encoding the string as UTF-8. That doesn't violate the letter of
RFC 7564 but perhaps it's confusing for implementers.
Note that the purpose of the order of operations is "to ensure proper
comparison"; I'm not convinced that what happens during preparation or
pre-processing needs to follow the same order of operations.
There's also the question of whether preparation / pre-processing is all
that useful. We added it so that constrained clients (e.g., clients that
can't realistically perform normalization) could avoid most of the
problems associated with having their strings rejected by a more
powerful server that actually does enforcement and comparison. Whether
we really need to consider such applications is another story.
For me as an implementer it simply felt more clean and
straightforward, e.g. when I faced this issue:
It’s still unclear what to do with U+212B (ANGSTROM SIGN) in
Usernames.
For better thread tracking, I'll reply separately to your original message.
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
