Re: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages)

[Bernie Hoeneisen <[e-mail]>]

Hi Dale

On Fri, 2 Oct 2020, Dale R. Worley wrote:

> Bernie Hoeneisen <[e-mail]> writes:
>> This I-D suggests a new Content-Type Header Field Parameter "forwarded":
>> If set to "yes", the contained message was forwarded; if set to "no", the
>> message was "wrapped" for signature/encryption with Header Protection.
>
> There's a category problem:  What you're trying to capture is "What is
> the significance of this body part within the whole structure?"  It does
> not describe the *type* of the contents of the body part.
>
> I've noticed this before in SIP, the idea that if you know the *type* of
> a body part, then you know its *significance*.  That works in the
> simplest cases, but it's like saying that you can always tell which
> parameter in a function call means what if you know their types.
>
> What we need is a new "Content-Semantics" header for parts of multipart
> bodies which describes the semantics of this part within the whole.
> E.g., "contained encrypted content" or "forwarded message".

No sure how exactely you suggest to apply such a header. The use case 
also includes situations that are not multipart, such as
Content-Type: message/RFC822.


In the following example, the upper part with Content-Type: message/rfc822 
is an "outer" message containing a forwarded message with Content-Type: 
text/plain (lower part). The suggestion in the I-D would look as follows:

   [...]
   Content-Type: message/rfc822; forwarded=yes

   Content-Type: text/plain; charset="us-ascii"
   [...]


Can you please clarify whether your suggestion would be to use:

   [...]
   Content-Type: message/rfc822
   Content-Semantics: forwarded

   Content-Type: text/plain; charset="us-ascii"
   [...]

or:

   [...]
   Content-Type: message/rfc822

   Content-Type: text/plain; charset="us-ascii"
   Content-Semantics: forwarded
   [...]

?

cheers,
  Bernie