[ietf-822] draft-crocker-inreply-react-- header field approach

[John C Klensin <[e-mail]>]

Several comments about the proposal and evolving discussion
rather than any particular note.  I have read many, but not all,
of the comments leading up to this point so, if some of what
follows is redundant, my apologies.

(1) I haven't tried to do a careful study of MUAs in years and
the one I use most often is even older, but what I keep seeing
when looking over the shoulders of others is that MUAs display
the headers they recognize and think are important.  If some
header field is not on that (typically very) short list, the
only way that a user will see it involves knowing where to find
the "show all headers" option (most end users I see, work with,
or am related to don't) and then, due in no small part to DKIM
and assorted other things related to authentication, spam
filtering, or list expansion, get buried in noise.  Not a good
way to deliver what is supposed to be a quick reaction.

(2) Some (at one time many, but I gather fewer recently) MUAs
will allow users to add their header fields of their own
choosing and a subset of them will allow adding header field
values on a per-message basis.  Like the above, I don't think
expecting casual users to do that is likely to be successful.

(3) Several of the systems I've looked at (including both
assorted filters and MUAs) don't deal kindly with messages with
empty bodies.  Even when  they are delivered, they may be
presented with obnoxious warnings.

(4) Whatever emoji may or may not be, they are not ASCII
characters.  That takes us into i18n space.  Unless SMTPUTF8 is
in use, if they appear in a header field in UTF-8, a plausible
reading of 5322 would call for that field to be rejected,
ignored, or treated with great skepticism, possibly along with
the whole message of which they are a part.  Using encoded words
should be fine except that the potential new header field is not
called out as a place where encoded words are to be accepted and
decoded.  Presumably we could amend those specs but the other
problem, connected to (1) above, is that many MUAs that support
a "show all headers" feature consider it a debugging option and
hence will display encoded words without decoding them -- not
what the user is likely to want to see.

As a consequence of the issues above, I recommend against adding
a header field for this function unless there is clear evidence
that the implementers and maintainers of the vast majority [1]
of MUAs are prepared to implement specific support for this and
feature the header as something that can be set (on the sending
side) or seen (on the receiving side) without going to more
extraordinary means than setting/looking at, e.g., a subject
line.

Of course, a different way to look at that is that a few MUA
developers and/or MSPs are anxious to offer this feature in a
way that would give them a market advantage and put those who
don't implement it quickly at a disadvantage.  Were that to be
any part of the argument or our thinking, it would be
appropriate to ask for disclosures about who is being paid by
whom to do what.  But I hope that is not happening.

best,
    john

p.s. Another note will follow (soon but not immediately) about
the use of Content-disposition, about which I'm also concerned,
but not nearly as much.

[1] By count of implementations, not of numbers of users.