Re: C-d displays duplicated parts

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

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

> This was a long time ago, I might not remember everything clearly.
> I think the choice was between showing only the <rfc822> line, and
> forcing the user to do another `C-d' to _enter_ it, or trying to
> immediately serve him, and simulate a recursive `C-d' right away,
> rather seamlessly integrated with the rest.  But then, if the quoted
> message happens to be a complex one, we need some way, at the
> dissection level, to discriminate the passage from one message into
> another, so the quoted message is first announced, then
> sub-analysed.  So, you see, it is not fully seamless.  It should not
> be.

I must admit that I still don't understand why you need to introduce
more parts.  Let's say you have a multipart message, and the first
part is message/rfc822 and the second is an image.  Then nndoc will
display the following structure:

  *
  |\
  | * message/rfc822
  |  \
  |   * text/plain
   \
    * image/gif

This looks like three parts, but the message just contains two.  And
in what way is the node labeled text/plain necessary?  Why can't nndoc
just show the contents of the text/plain thing in the message/rfc822
node?

If you copy this message and leave it exactly as is, except that you
replace the message/rfc822 content type with application/octet-stream,
say, then you will get the following tree:

  *
  |\
  | * application/octet-stream
  |
   \
    * image/gif

Just changing the content-type can't make a node disappear, can it?

If nndoc is meant to accurately represent the MIME structure, then I
feel the above is suboptimal, I'm afraid.

Probably I'm overlooking something here, though, showing that I
fundamentally don't grok MIME.

kai
-- 
I like BOTH kinds of music.