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.
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? 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. If I stick to the rules in RFC 7613 § 3.2.2, it would be disallowed (HasCompat == true, => preparation *before* other rules fails). If I stick to the rules in RFC 7564 § 7, it would be allowed (NFC converts it to U+00C5 => preparation *after* other rules succeeds). The workaround for half and fullwidth characters in RFC 7613 §3.2.1 suggests, that the authors *want* a workaround for HasCompat characters, but they only specified it for a few characters, which somehow feels like they overlooked it. => It would be nice if the authors could give their thoughts on it! If all profiles simply sticked to the rules in §7, no workarounds are needed. +1 for the clarification of the meaning of „preparation“. It suggests that a string, which passes the preparation step is valid. But in fact a rule could still fail during enforcement (e.g. Bidi rule). Thanks for your attention, Christian > Am 28.03.2016 um 21:28 schrieb Marc Blanchet <[email protected]>: > > On 28 Mar 2016, at 13:30, Peter Saint-Andre wrote: > > On 3/1/16 3:56 PM, Peter Saint-Andre wrote: > > On 3/1/16 3:23 PM, Marc Blanchet wrote: > > hello, > we were thinking of closing the working group since the main topics > have been done and published as RFC. However, as some mailing list > discussions require that some corrections to RFC 7564 and 7613 are > needed, we added those two milestones to the charter. The intent is when > those are done, we would close the working group. > > Thanks, Marc. Here is my understanding of what needs to be done: > > In RFC 7564: > > • Change §5.2.3 to mention Unicode toLower() as an alternative to > Unicode Default Case Folding and describe the circumstances in which > toLower() is appropriate. > > • Change the order of operations in §7 from MUST to SHOULD (we've > already deviated from that slightly in RFC 7613 §3.2.1). > > • Clarify the meaning of 'preparation' (because it is different from > what stringprep meant by the term). > > In RFC 7613: > > a. Revisit Unicode Default Case Folding here, too. > > b. Modify the presentation (but not the content) of the rules for each > profile, along the lines of what we did in RFC 7700 (i.e., describe the > rules in one section and then use them in separate sections on > preparation, enforcement, and comparison). > > We'll also want to review and correct the errata that have been reported. > > I can commit to doing this work. > > FYI, I plan to submit -00 versions of the bis documents when the submission > window opens again on April 3. > > Marc, would you like me to submit these as individual I-Ds or WG I-Ds? (They > would be draft-[ietf|saintandre]-rfc[7564|7613|7700]-bis-00.) > > I’m sure that the wg is likely to be ok with wg drafts, but let’s do the > normal process. Please submit first as individual draft and we will call > later for wg adoption. > > Marc. > > Peter > > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis > > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
