[Top] [All Lists]

Re: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-01.txt

2020-10-07 20:03:22
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

<Prev in Thread] Current Thread [Next in Thread>