On Thu, Oct 8, 2020, at 2:13 PM, Dave Crocker wrote:
What will make the basic mechanism useful to its specific goal,
sufficient as a specification, reasonable to implement, and as simple as
possible without defeating its other goals?
Here's one thing:
The Unicode Emoji List is revised more or less annually. This means that
releasing software that validates this header against the contents of UTS #51
is liable to fall out of date.
A problem closely analogous to this one, and seen in the real world: an email
with an IDN is in transit and some system attempts to decode the IDN, finds
that it contains unallocated code points, and takes some sort of negative
action… but the code points -are- allocated, but were not allocated at time
time of the program's construction.
So: what is the implementation to do when confronted with a valid
encoded-word? If the implementation was built on Unicode 12 and encounters the
sequence { White Flag, ZWJ, Transgender Symbol } it will be unable to validate
that sequence as an emoji-forming sequence.
The problem here is that some implementors like to validate data at layers were
its validity is (probably) irrelevant to its intended use. Maybe this warrants
a note for implementors, and maybe not, but it seemed worth raising the point.
--
rjbs_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822