Re: 'nndoc' view of a multipart msg problem?

["François Pinard" <pinard@iro.umontreal.ca>]

Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes:

> I've just received a multipart messages (multipart/mixed) with 3 parts:
> 1) text/plain; 2) text/html; 3) message/rfc822.  The author of the
> multipart message is A.  The author of the embedded message/rfc822 is B.
> I saw this when doing C-d:

>   [  96:  A ] <* mixed>
>        [   1:  A ] <1 text>
>        [   7:  A ] <2 html>
>        [  71:  A ] <3 rfc822>  <- note the A

> Shouldn't this be displayed as:

>    [  96:  A ] <* mixed>
>        [   1:  A ] <1 text>
>        [   7:  A ] <2 html>
>        [  71:  B ] <3 rfc822>  <-note the B
> ?

François Pinard <pinard@iro.umontreal.ca> écrit:

> Yes.  Moreover, I think the real subject of the third part should show,
> maybe after the <3 rfc822>, maybe fully replacing it.  The file name
> of an entity, if any, should show somewhere, maybe after the <number
> [sub]type> thing.

I gave more thought to this problem, and we might probably not just do that.
There are two difficulties.

1) An rfc822 subtype entity could be used in a non-multipart MIME message.
   This is at least the case, currently, after one uses `nndoc' to isolate
   an rfc822 entity from a composite one.  Moreover, if you consider that
   one could simply forward a message by turning it into an rfc822 entity
   without using multiparts, and hypothesizing that the forwarding occurred
   many times, one could theoretically end up with deep telescoped rfc822,
   still with no multipart.

2) In the summary buffer, internally, `nndoc' generates References and
   Message-ID out of thin air for ensuring that the threading respects the
   MIME hierarchical structure.  These do not show in the article buffer,
   so everything gets displayed and save using original field values.
   This creates a problem for commands, like `^', which might depend on
   `References'.  I guess they use the value from the summary instead of
   the one from the article, but I do not know.

So, I now think the original display is correct, but the lack is that
rfc822 entities should have a separate summary line.  If we want to be
strict on the respect of the original field of the rfc822 entity, including
References, we might have to untie the rfc822 message from its thread, which
is unfortunate.  Some compromise might be needed.  I'll ponder it a bit more.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard