Re: multipart/alternative question
On Thu, Jul 16, 2009 at 10:09:16PM -0500, Kyle Wheeler wrote:
> On Thursday, July 16 at 08:18 PM, quoth lee:
> >
> > Yeah, but mutt already has a way of showing a list of attachments.
>
> Those aren't attachments, they're MIME components. There's a
> difference, at least in modern lingo. MIME components have *semantics*
> that are important.
You mean the difference between attachments and mime components is
only a semantical one?
> For example, if someone sends me a message that is a
> multipart/alternative container with both a text/plain component
> (that simply says "Your reader cannot read HTML!") and a text/html
> component, *very* few people would consider that message to have
> THREE attachments, besides the fact that it has three MIME
> components.
Well, messages are plain text in the first place. If there's a message
that doesn't have text but a container, that container is an
attachment. You might argue whether things inside the container are
also attachments or not. To me they are because it doesn't matter to
me if things attached to a mail are contained in a container or not.
If you argue that things inside containers are not to be counted as
attachments, then you cannot count a container other than the mail
itself as attachments because the mail is a container (containing
other containers) itself.
> > So what's the difference between "inline" and "attachment"?
>
> Unfortunately, those terms mean different (albeit related) things in
> the sense of MIME disposition. In MIME disposition terms, "inline"
> means "display the contents of this MIME component when the reader
> views the mail" and non-inline means "don't display the contents of
> this MIME component when the reader views the mail".
That's what I meant. Still all the components are attachments, no
matter if they are to be displayed in line or not.
> > and mutt doesn't count attachments that are inline.
>
> Yes it does. But it doesn't recurse into some MIME containers (as
> we've been discussing).
Even when mutt doesn't recurse into multipart/alternative, the
multipart/alternative itself is an attachment which should be counted:
I 1 <no description> [multipa/alternativ, 7bit, 4.2K]
I 2 ><no description> [text/plain, quoted, iso-8859-1, 1.3K]
I 3 ><no description> [text/html, quoted, iso-8859-1, 2.5K]
Mutt says that there are 0 attachments. I say there's at least 1.
> For example, I have a message with the following MIME structure:
>
> I 1 <no description> [text/plain]
> I 2 forwarded message [message/rfc822]
> I 3 `-><no description> [text/plain]
>
> With your two rules, mutt tells me that this message has ONE
> attachment. They're ALL inline, so *something* got counted!
The interesting question is: *What* has been counted :)
> As I understand it (David would know for sure) the "main body" of the
> message (MIME component #1) doesn't count toward the total.
RFC822:
"
A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
"
You could argue that the message doesn't have an attachment because
everything is to be displayed in line. I would argue that everything
that isn't either headers or body as described in RFC822 is an
attachment.
Containers? If you put a container containing 10000 bricks onto a
container ship, you have 10000 bricks on the container ship (and one
container). For the purpose of counting containers, you loaded one
container; for the purpose of counting bricks, you loaded 10000
bricks.
So what do you want to count, containers or everything that is
"attached" to the ship?
> > (Imho, there's no such thing as an "inline attachment". Something is
> > either attached or inline, and it cannot be both. Creating mails
> > with inline attachments is silly.)
>
> Then you're not understanding the idea.
Indeed --- or lets say I have a different understanding.
> It's all about *display*. Do you want the contents a given
> "attachment" (or MIME component) to be *displayed* when the rest of
> the message is displayed, or do you want it to be represented more
> succinctly, merely letting the viewer know that it exists? The former
> is an "inline" attachment, the latter is a non-inline attachment.
So you would say that all of them are attachments and therefore should
count as such, no matter how they are supposed to be displayed.
> If you include a JPEG in an email, should that JPEG be displayed when
> the user views the message, or should it just show up as an icon that
> can be downloaded and saved to disk?
Once I received the message, I either already received the JPEG or the
icon or both, as an attachment or as attachments.
You shouldn't ask me that because if I wanted to send someone a
message and a JPEG, I would send a plain text message and attach the
JPEG. If I wanted the recipient to look at the JPEG while he's looking
at the message, I would tell him in the text when he should look at
the JPEG.
> If you want it to display when
> the user opens the message, is that JPEG "attached" to the message?
When the JPEG is included in the mail, yes, it would have to be an
attachment, see RFC822.
> (if it is not attached, how would you describe its relationship to the
> message?) Should the user be able to save it separately from the rest
> of the message? Should it be allowed to have a filename associated
> with it?
yes, and yes
> The answers, according to the standard RFCs, is that yes, that JPEG is
> "attached" to the message, yes it can have a filename, and yes the
> user should be able to separate the picture from the rest of the
> message. It is merely an "inline attachment".
So why shouldn't mutt count it as one? :) Or isn't it an attachment
anymore when it's put into a container? A brick is still a brick, even
when you put it into a container.