+1 mostly. Or should I say, 👍. As usual your analysis is excellent.
But you say that a MIME part with “Content-Disposition: reaction” should
have its contents restricted to UTF-8 emoji. Most likely some implementors
will ignore that and include additional UTF-8 text, or worse, pictures or
video. How should a conformant implementation handle that?
I tried to make that clear, but I guess it didn't come through. My
sugggested approach is to treat any reaction part that doesn't conform
to the specification as if it doesn't have the reaction disposition.
This makes it difficult for a bad sender to cause trouble by creating silly
states, has reasonable fallback semantics, and allows for future extension.
wIt seems like this creates an excellent opportunity for bad implementations
help people send content that might never be displayed to the recipient.
Not if doing it immediately engages the fallback behavior of treating the
part as regular text.
Although it will be the fault of the sending implementation, the consequences
will be experienced by the readers more than the senders, so it could be hard
to even notice, let alone get fixed.
I’m not sure we should dismiss out of hand the “text/reaction” idea.
Conformant implementations will treat it as a reaction — a new thing. What
does it really matter whether nonconformant implementations treat it as
text/plain or application/octet-stream?
I suggest you try it and see what happens with gmail.com and outlook.com - it
shows up as an ugly little attachment symbol, which people are unlikely to
bother clicking on. I do not regard this behavior as an acceptable fallback.
Content-disposition: reaction, OTOH, is displayed as text. It runs into
adjacent parts when used in a multipart/mixed. I really can't think of
better fallback behavior than this.
Either way, it won’t have any special automatic reaction processing, and it
will make the content available to the user either as readable text or an
attachment that the user is at least told exists.
I don't think they're told in a way where they are likely to bother
I also think this is probably a deliberate UI design choice. It's easy for bad
things to happen when people download and then click on random content. The
designers of thsee interfaces are caught between a hard conformace requirement
and a modern day security issue.
Sure, application/octet-stream is the wrong choice, but it’s no more wrong
than it has been all along for unrecognized text subtypes. In fact, if this
gives us a reaction mechanism that works for everything but Microsoft and
Google, it might actually spur those companies to start doing the right thing
with unrecognized text subtypes in general. (OK, I wouldn’t bet the farm on
that, but you never know.)
I'm not just concerned about Google and Microsoft. I've found in the past
that what they did is a good indication of what others have done.
FWIW, the MIME specification may be partly at fault here. The need to be able
to fall back to application/octet-stream so the data is at least accessible is
vital and is mentioned multiple times, including in the conformance document
But we didn't make the conformance criteria for unknown subtypes of text
nearly as clear. In RFC 2046 we said:
Unrecognized subtypes of "text" should be treated as subtype "plain"
as long as the MIME implementation knows how to handle the charset.
Unrecognized subtypes which also specify an unrecognized charset
should be treated as "application/octet- stream".
This is quite clear. But we didn't say the same thing in RFC 2049. Instead we
-- For unrecognized subtypes in a known character
set, show or offer to show the user the "raw" version
of the data after conversion of the content from
canonical form to local form.
It can be argued that this criteria is met by fallback to
application/octet-stream. An oops on our part...
These are just my reactions, I’m not yet sure what I think is the right
answer. — Nathaniel
Thanks for the feedback.
ietf-822 mailing list