Thanks for all of this.
Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> wrote:
> Proposal 2: simplify, simplify
> ------------------------------
I like it too.
> I believe that proposal 2 is closer to what most implementations do
> today, and it handles goals A and B. I don't mind it failing at goal
> C because of how much simpler the matching rule is.
Agreed.
> PS in researching other ways to solve this problem, i came up with an
> approach that relies on Unicode character properties, in particular
> Grapheme_Base and Grapheme_Extend as a way to exclude control chars
> and other non-printables. This is a more sophisticated/nuanced
> approach than the RFC 6532 ABNF extensions to atext. But specifying
> it requires a character class set subtraction operation (you want to
> subtract "<" and ">" and "@" and " " from the Grapheme_* classes),
> which isn't listed in IETF's ABNF definition in RFC 5324. And
> implementing it requires a toolkit capable of discerning and acting
> on Unicode properties (e.g. the python regex module from PyPi, but
> not the re module from python's stdlib). That's too bad, because
> 6532 §3 effectively makes things like U+200B ZERO WIDTH JOINER
> allowable within dot-atom-text, which is uncomfortable and weird.
> But other implementers reliant on 6532 might accept such a localpart
> anyway. These costs don't appear to be worth the minor gain compared
> to proposal 2, so i've stopped attempting to document that approach.
> If anyone wants to take a crack at it though, i'm happy to share my
> notes.
Wow :-)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr(_at_)sandelman(_dot_)ca http://www.sandelman.ca/ | ruby on
rails [
--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp