Re: multipart/alternative question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thursday, July 16 at 10:27 PM, quoth lee:
> 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?
No, I mean that MIME components (aka "entities") have meanings that
affect the interpretation of other MIME entities. For example, take
PGP/MIME, where one MIME entity (the signature) can affect the
understanding of another. As another example, take multipart/mixed,
which is only a container for other MIME entities and has no inherent
content itself.
The term "attachment", on the other hand, is a poorly defined term
that has different meanings based on who you ask. For example, you
seem to think that all MIME entities count as "attachments", while I
tend to think of "attachments" as only those things that a user has
explicitly attempted to attach (I don't think the body text of a
message counts as an "attachment").
I could appeal to something like Wikipedia (which says an email
attachment "is a computer file which is sent along with an email
message"), but I'm guessing you don't care much for so-called
"official" definitions.
> 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.
We clearly have different definitions of the term.
I find my definition more useful, because then I can use it to tell me
whether there's some component of the message that I can and will want
to save to disk. In the message structure you show there, none of
those MIME entities are things I have any interest in saving to disk.
None of those MIME entities are things the sender explicitly
"attached" to the message (by using the "attach" function of his/her
mailer). It makes sense to me.
What's the utility of your definition?
> 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?
I want to know if I need to unload anything from the ship. I want to
know the difference between a ship loaded full of empty containers
(that I don't care about) and a ship loaded full of bricks (things
that I want). Thus, I can ask "how many things are on the ship?" and
get an answer. If the ship merely has a hundred empty containers, and
my smart-alecky captain says "there's a hundred things on the ship",
I'm gonna be annoyed when I rifle through every last container and
discover that they're all empty. On the other hand, if I paid to ship
a thousand bricks, and there's one container with a thousand bricks,
when he tells me "there just one thing on the ship", I'm *still* going
to be annoyed that he was playing goofy semantic games and didn't tell
me that everything I ordered was in fact on the ship.
Why do *you* care how many containers are on the ship?
>> 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.
Am I really that hard to understand, or are you just trying to get
under my skin?
For the umpteenth time, no, not all MIME entities are attachments.
> RFC822:
RFC 2045:
This set of documents, collectively called the Multipurpose
Internet Mail Extensions, or MIME, redefines the format of
messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message
bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than
US-ASCII.
Thus, in the context of MIME, the RFC 822 definition of a message
format is no longer supreme. It has been, in the words of the MIME
RFC, "redefined".
>> 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.
So you simply don't think RFC 2183 exists? Or you think it's a stupid
RFC that has gotten far too much attention?
>> 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? :)
I think mutt *should* count it as an attachment (in most
circumstances).
> 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.
You'll get no argument from me there.
Lets take the following example MIME structure:
I 1 <no description> [multipart/mixed]
I 2 |-><no description> [text/plain]
I 3 |->portrait.jpg [image/jpeg]
I 4 `-><no description> [text/plain]
In that, I see one attachment (entity #3). You appear to think that
it's more useful to say that it has 4 attachments. Why? Put all your
semantic arguments aside, and just tell me why that is a *useful* way
of looking at it?
~Kyle
- --
Victory goes to the player who makes the next-to-last mistake.
-- Chessmaster Savielly Gricorievitch Tartakower
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKYA6GAAoJECuveozR/AWeSOQP/1jqWDBFidmR46RPloGgQJCq
uzQyDWyzWbGOLoasfdWFDMAMUpGJzTnoFlphiOJi+6c5XxtVK/oIZgS4v19PISpX
eN4alHOYLkkFmSBwMfIa+5zNOZQUrUOmS+UbyFLXgCexOAYq3xnKWtBNmwSPybyS
P4e5OW5mRU5dN5/+em5YReOHGQqQUhq//4/z+NeNvr3RGXlTP+aAG4fjag3gnJ1K
BO19ssPVaYehwy2I2doYSmdKv1cxF4M/9V3XjzFOhwC4bzXAqx5GetAM1MxaG1QA
1/j/33zbBvVdIi8xNIogzkyDLYp3iTHQcGBAPzUm36eiz7VNk9+Vfys/lBVCDC8L
QOfchwnp+eD9EMCOgSNmdCRBOMghNnP3wG5M3jmC82Utc/cGhHpH7cN/HZpra4eM
MaCterO6bb7vrtnE190eoPAA+/PreyhWmcAfhKDGxfZnIGGQHEZkDF8s8SpIViCp
URsbxrPwVxwPVbW0+8VWyraSBf3z1Aimfdw3IvzeROSbTJ++Ioc6ikDlpuo6f99H
w99p0w7ZpjU5JDERMq2ykndbkzeElUswsUzQYP7qQDraFhxtm967TuJ3/ITCVHr0
1NgmiWOyGnCOreJh2U5hCmbA1QaS5bbucqSCkzly/bqf2MjzDDqFtXHWjAnutA4H
RHTACctYWCAh/o4h0EXV
=39ou
-----END PGP SIGNATURE-----