Re: [ietf-822] Review of and suggested changes for draft-crocker-inreply-react-01.txt

[Ned Freed <[e-mail]>]

> +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 to
> 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
looking.

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
RFC 2049.

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
said:

         -- 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.

				Ned