Consider content-type for legacy-display part

[dkg]

given that:

• the purpose of the legacy display part is purely decorative, and
• the legacy display part will never be rendered by any non-legacy client, and
• more legacy clients are likely to actually render a text/plain part instead of a text/rfc822-headers part,

should we consider changing the legacy display part to use Content-Type: text/plain?

Also, if protected-headers="v1" is used to identify a cryptographic payload as containing protected headers (see #21), does it make sense to use the same parameter to identify the legacy display part? Shouldn't it be something like legacy-display="v1" or protected-headers="legacy-display" ?

Part of my reluctance to make either change is that some messages containing legacy display parts as described in the current document already exist. Do we want to discourage clients from dealing with them well by specifying only a new way to identify legacy display parts going forward?

We could specify for generating clients to generate the new form, and for receiving clients to handle both forms, but that sort of defeats the cleanliness rationale for having the "right" kind of markings.

On the other hand, if the only cost is that some encrypted messages from a couple of years render a little bit uglier than they used to, but we get cleaner signalling going forward, that might be a nice win.

On the third hand, legacy display is (hopefully) only useful for a limited time as it is transitioned away. So perhaps doing this cleanup would be more pain than benefit.

[BjarniRunar]

My knee-jerk reaction to this was "hell yeah, it should be text/plain", in order to maximize the odds it gets displayed.

I became slightly less convinced when people pointed out that some mature MUAs like Thunderbird, will do a nice job formatting a message/rfc822-headers part as headers, which is a UX win. But if the cost is that other MUAs don't display the data at all, then I think it's not worth it.

If only we had a lab where dedicated staff would test all the different MUAs and let us know how they interact...

I think don't think we should change the attribute on the legacy display part. Nobody sees that except implimentors, it doesn't need to be pretty.

[dkg]

@BjarniRunar wrote:

I think don't think we should change the attribute on the legacy display part. Nobody sees that except implimentors, it doesn't need to be pretty.

My rationale was less "prettiness" and more "are we going to get in trouble for using the same property to mean two different things?" -- maybe you can comment on that concern?

[BjarniRunar]

I don't think it will cause problems, the other structural headers (Content-Type etc) need to be checked no matter what, and they differentiate clearly between the two cases.

[dkg]

an additional point of reference: @Valodim mentions that K-9 shows a text/rfc822-headers legacy display part as a "weirdo attachment"

[Valodim]

So does this mean a typical message would then have a mime structure like this?:

multipart/mixed
> text/plain
> multipart/alternative
> > text/html
> > text/plain

Without thinking about it too deeply, I do have some doubts that this structure is very likely to be displayed in a desirable or useful way in any given mail client.

[BjarniRunar]

This structure is 100% legitimate, I would expect it to render just fine. But tests and some actual data are probably in order if this spec is to have any chance of moving towards standardization.

[Valodim]

Thought about this more deeply and looked over thunderbird and k-9 code bases :) I think you're right. It should be fine.

[dkg]

If we make the change to text/plain, then we probably also need some explanatory text about headers included in the legacy display part that are not US-ASCII -- for example, i think we want to avoid RFC 2047-style encodings.

[dkg]

@BjarniRunar, do you want to take a crack at making a PR for this?

[dkg]

hearing no complaints, I believe we should make this change.

I also note that (at least as of thunderbird 1:68.3.1-1 in debian) thunderbird no longer displays text/rfc822-headers parts differently than it displays a text/plain part.

I will note that recipients deciding whether to omit the legacy-display part should consider omitting it whether its content-type is either text/plain or text/rfc822-headers (and of course the MIME structure and the protected-headers parameter).

But any generator producing a legacy-display part should make it text/plain.