Re: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-r

Overall impression: It's a useful facility, probably workable, could use 
some tweaks to the specification.   I appreciate the effort to keep this 
proposal simple.
Specific impressions and questions, in no particular order:


- I wonder if it makes sense to have a way for the subject message to 
provide a set of reaction choices recommended for use by a recipient in 
composing a reply.   Such a facility could be used, for example, by a 
mailing list to request specific responses,  or even for voting.  
Presumably a separate header field would be used in the subject message 
to specify choices, e.g.:
reply-react-choices = "Reply-React-Choices:" ("single" / "multiple") ";" 
lwsp react-choice *("," lwsp react-choice)
; single means: please choose up to one of these to include in an 
In-Reply-React response
; multiple means: multiple choices are acceptable (no more than one of 
any choice) in an In-Reply-React response
react-choice = { rfc2047 encoded-word no longer than 75 characters, 
using "utf-8" as charset and the "B" encoding }
One advantage of this might be an improvement in user interface for 
recipients composing replies, since recipients could choose from a small 
menu rather than being expected to input arbitrary characters.
While useful, voting would introduce additional security considerations 
such as lack of authentication, ease of forging votes on others' behalf, 
need to handle potential (deliberate or accidental) duplicate or 
conflicting votes.
Another way to look at it: if we were to add a voting facility to email 
messages, would it be better to combine it with In-Reply-React, or for 
the two to be separate?

- I might prefer it if the responses were not limited to emojis but 
could be arbitrary (short) text (say, no more than a single RFC2047 
encoded-word).    Part of my reason for this preference is that whenever 
I receive emoji in text or email, I often find myself wondering what it 
actually means.   On the other hand, a set of lengthy (in terms of 
screen space) choices might be more difficult to manage on handheld devices.
[One downside: a limitation of a single encoded-word would be unfair to 
some languages for which UTF-8 encodings are not as compact as others.]

- I think the service would work more reliably, and be more consistently 
implemented, if all responses were encoded using the UTF-8 charset and 
the "B" encoding.   In other words, the encoding of the In-Reply-React 
field should be consistent for all sending user agents.

- RFC2047 section 5 permits use of encoded-words only in certain 
portions of a message header.   I don't view this as a showstopper.   
Presumably a new header field can define whatever encoding it wants, 
including an encoding that's identical to one defined in RFC2047.   But 
some additional explanation might be in order to resolve an apparent 
conflict between this specification and RFC 2047 section 5.

- As for use of 2047 as the encoding, I have no strong opinion about 
this either way.  Clearly it's already established and widely 
implemented.   There may be MTAs and gateways in the wild that take the 
decode encoded-words any where they find them, and some that take the 
liberty of translating encoded-words to unencoded text.   I have heard 
from vendors of malware filters that decode 2047 encoded-words to look 
for malicious content (I have no idea what kinds of content they 
consider malicious).   I don't know whether the use of encoded-words in 
a new header field would trigger spam or malware filters.   etc.  
Overall, though, I suspect this proposal is Mostly Harmless.

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822