C-d displays duplicated parts

C-d displays duplicated parts

[Vladimir Volovich]

Hi,

i received a multipart/mixed message which contains a text/plain part
(the first one), and then five message/rfc822 parts; each of them has
the following headers:

Content-Type: MESSAGE/rfc822; name=Mailbox
Content-Description: Mailbox

When pressing C-d in a summary buffer, i get the following:

R  [ 303: Himanshu Gohel      ] <* mixed> Re: shared libs in teTeX
R      [  17: Himanshu Gohel      ] <1 text>
R      [  31: Himanshu Gohel      ] <2 rfc822> Mailbox
R          [  15: Thomas Esser        ] <2 text> Re: shared lib on Solaris and -Rpath
R      [  90: Himanshu Gohel      ] <3 rfc822> Mailbox
R          [  66: Calum Mackay - Compu] <3 text> Re: shared lib on Solaris and -Rpath
R      [  44: Himanshu Gohel      ] <4 rfc822> Mailbox
R          [  20: Calum Mackay - Compu] <4 text> Re: shared lib on Solaris and -Rpath
R      [  52: Himanshu Gohel      ] <5 rfc822> Mailbox
R          [  29: Keith Refson        ] <5 text> Re: shared lib on Solaris and -Rpath
R      [  43: Himanshu Gohel      ] <6 rfc822> Mailbox
R          [  27: Thomas Esser        ] <6 text> Re: shared lib on Solaris and -Rpath

I.e. each message/rfc822 part is "duplicated". Is this correct?

	Best regards, -- Vladimir.

Re: C-d displays duplicated parts

[Justin Sheehy]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> i received a multipart/mixed message which contains a text/plain part
> (the first one), and then five message/rfc822 parts; each of them has
> the following headers:

> I.e. each message/rfc822 part is "duplicated". Is this correct?

>From what you posted, it looks like each message/rfc822 part was
presented exactly once.  Perhaps you mean something different by
"duplicated" than what I usually infer from that word...

-Justin

 

Re: C-d displays duplicated parts

[Vladimir Volovich]

"JS" == Justin Sheehy writes:

 JS> Vladimir Volovich <vvv@vvv.vsu.ru> writes:
 >> i received a multipart/mixed message which contains a text/plain
 >> part (the first one), and then five message/rfc822 parts; each of
 >> them has the following headers:

 >> I.e. each message/rfc822 part is "duplicated". Is this correct?

 JS> From what you posted, it looks like each message/rfc822 part was
 JS> presented exactly once.  Perhaps you mean something different by
 JS> "duplicated" than what I usually infer from that word...

i mean that each rfc822 part was represented with two lines, e.g. the
first one:

R      [  31: Himanshu Gohel      ] <2 rfc822> Mailbox
R          [  15: Thomas Esser        ] <2 text> Re: shared lib on Solaris and -Rpath

Pressing on the line

R      [  31: Himanshu Gohel      ] <2 rfc822> Mailbox

shows a parsed message/rfc822 buffer (i.e. headers of the original
message, then headers of the attached message, then message body of
attached message). Pressing on the line

R          [  15: Thomas Esser        ] <2 text> Re: shared lib on Solaris and -Rpath

shows only the attached rfc822 message. it seems that this is enough, :)
and the line

R      [  31: Himanshu Gohel      ] <2 rfc822> Mailbox

is not necessary: each message/rfc822 attachment is represented with
two lines, which seems wrong.

	Best regards, -- Vladimir.

Re: C-d displays duplicated parts

[Lars Magne Ingebrigtsen]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> shows only the attached rfc822 message. it seems that this is enough, :)
> and the line
> 
> R      [  31: Himanshu Gohel      ] <2 rfc822> Mailbox
> 
> is not necessary: each message/rfc822 attachment is represented with
> two lines, which seems wrong.

Well -- it's meant to be that way, so it's right.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: C-d displays duplicated parts

[François Pinard]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> > shows only the attached rfc822 message. it seems that this is enough, :)
> > and the line
> > 
> > R      [  31: Himanshu Gohel      ] <2 rfc822> Mailbox
> > 
> > is not necessary: each message/rfc822 attachment is represented with
> > two lines, which seems wrong.

> Well -- it's meant to be that way, so it's right.  :-)

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.

Remember, `C-d' is not for MIME presentation.  Gnus has much more convenient
and sophisticated machinery for doing that.  It's merely for debugging
the MIME as received, or when wanting to intimately operate on MIME parts,
independently of the viewing intent behind MIME, which may be very different.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: C-d displays duplicated parts

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

Re: C-d displays duplicated parts

[Kai Großjohann]

Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> I must admit that I still don't understand why you need to introduce
> more parts.

I now verified the introducing-parts part as follows:

I wrote a message with the following contents:

,-----
| <#part>
| this is part one
| <#part type="message/rfc822">
| From: me
| To: you
| Subject: inner message
| 
| test test
`-----

I sent it.  I then went back and changed the "message/rfc822" into
"text/plain" and sent the changed message again.

I received two messages, and C-d on the first message showed this:

,-----
|   +[27-Aug,  0b: -> Kai Großjoha] <* mixed> test MIME
|   +    [27-Aug,  0b: -> Kai Großjoha] <1 text>
|   +    [27-Aug,  0b: -> Kai Großjoha] <2 rfc822>
|            [01-Jan,  0b: me             ] <2 text> inner message
`-----

Whereas C-d on the second message showed this:

,-----
|   +[27-Aug,  0b: -> Kai Großjoha] <* mixed> test MIME
|   +    [27-Aug,  0b: -> Kai Großjoha] <1 text>
|        [27-Aug,  0b: me             ] inner message
`-----

I think that pretty much proves my `a node is added' statement.

Can you explain why that node is added?

kai
-- 
I like BOTH kinds of music.

Re: C-d displays duplicated parts

[Lars Magne Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I must admit that I still don't understand why you need to introduce
> more parts.

   [ 168: Stephen J. Turnbull ] <* mixed> forwarded message
       [   7: Stephen J. Turnbull ] <1 text>
       [  23: Stephen J. Turnbull ] <2 rfc822>

[-- Attachment #2: Type: text/plain, Size: 619 bytes --]

           [   9: Stephen J. Turnbull ] <2 text> 日光"日光"

It's necessary if you want to treat all parts equally.  For instance,
here you have a multipart/mixed with one text/plain part and one
message/rfc822.  If you select the parts on the second "level", you
get articles that have headers from the parent.  The last article here
has headers from the rfc822 part itself.  And so on.

Not doing it this way would raise the contents of the rfc822 part "up"
one level, above where it properly belongs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: C-d displays duplicated parts

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> It's necessary if you want to treat all parts equally.  For instance,
> here you have a multipart/mixed with one text/plain part and one
> message/rfc822.  If you select the parts on the second "level", you
> get articles that have headers from the parent. [...]

Oh.  Yes, I understand what you're saying now.  I still think that the
other position is defensible, but yours is, too.  So I'll just keep my
mouth shut.

kai
-- 
I like BOTH kinds of music.

Re: C-d displays duplicated parts

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Oh.  Yes, I understand what you're saying now.

Er...  You do?  Could you explain it to me, then?  I'm not quite sure
I got it right, but François's explanation of it makes perfect sense
every time I read it.  :-)

> I still think that the other position is defensible, but yours is,
> too.  So I'll just keep my mouth shut.

:-)

Anyway, the MIME nndoc thing is just so that one can inspect and reply
to various parts of it, and the more details the better.  People
aren't supposed to actually use it for normal viewing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: C-d displays duplicated parts

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > Oh.  Yes, I understand what you're saying now.
> 
> Er...  You do?  Could you explain it to me, then?

Hm.  I understood that the parts usually use the headers of their
parent, so you (and François) want to do that for message/rfc822 as
well.  Hence you need to show two sets of headers for a message/rfc822
part, hence two parts.

Err.

When a text/plain part looks like a message/rfc822 part, the From and
Subject headers are displayed at the top level and there is no extra
part.  Oh, well...

Anybody got that explanation from François?

kai
-- 
I like BOTH kinds of music.

Re: C-d displays duplicated parts

[François Pinard]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) écrit:

> Anybody got that explanation from François?

Please don't take me too seriously, even if if I look like having opinions.
(People without opinions are boring, people being nothing but opinions
are unbearable.  Worse is that some receive opinions as deadly missiles :-).

`C-d' is useful to dissect a MIME message for analysis, and if it might
be improved, so be it.  But this is a very secondary matter, in practice.
It was meant, at the very earliest stages of MIME support in Gnus, as a
tool so Lars and developers could study the structure of existing MIME
messages, but maybe more importantly, as a way to remove in advance the
encumbrance of many concerns which traditionally plagued other MIME readers,
prohibiting these to get a clear grasp of what should really be done.

The MIME viewer in Gnus is already quite satisfying as it stands, and so
far that I understand things, is much in the spirit of the MIME designer.
The worse dangers being discarded by now, `C-d' has played its main role.
I would surely not object that it evolves into something a bit different,
and moreover, this is Lars who decides.  Maybe he might accept patches?  Yet,
my feeling is that it is not really worth working much on `C-d'.  Rather,
instead, one should build nice things using the more recent Gnus MIME API.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard