-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Friday, July 17 at 03:58 PM, quoth lee:
> Hm, somehow I've never had that problem. When reading the message, I
> find out if something is attached.
You're lucky! These days, I usually use the size as an indicator. A
message that's 10K or so is probably text; but 100K or more probably
means I need to have a look at its innards (at least that's ONE
benefit to MSOffice's giant files). But every now and then, I still
manage to miss an attached file (either because I didn't look, or
because it was surprisingly small).
> For this, mutt would first have to be able to count attachments
> exactly the way the user wants them to be counted.
Quite.
> Well, you could have a message with a container. The container could
> contain a number of files, JPEGs for example --- maybe portraits of
> your relatives. You could have a choice: Do you want to go to every
> file in the list and save one after another, or would you rather go
> to the container and save the whole container with all the files in
> it at once (as a new directory containing all the JPEGs).
Hmm, well, I guess I see your point, but not even mutt supports
batch-decoding like that. Do you perhaps have a perl script of some
kind that you use to bulk-decode like that?
> At some time, all this mime crap (that's how I still think of it)
> was invented.
HEH - way to make me feel old. The first MIME RFC was written in 1993,
back when I was barely a teenager and was just about to discover the
wonders of HyperCard. (My First Internet (tm) was AOL.)
But I see what you mean about your definition of an "attachment"...
though by that logic, a "message" is essentially defined by its
headers (From/To/Subject/etc.) rather than its content.
> And isn't it outright amazing that the mime guys, in a way,
> massively failed in clearly defining what an attachment is and what
> not?
Yes and no. I think a lot of those sorts of oversights tend to be the
result of assumptions, influenced by popular software abstractions.
For example, it's easy to assume that an "attachment" is anything the
user explicitly "attached" (by clicking the "attach" button) and that
any behind-the-scenes encoding nonsense doesn't count IF (and only if)
you typically operate at a level where that stuff is handled
transparently such that you never see it. If, on the other hand, you
usually read mail with `more` (or `mail` or something else that
usually shows raw email content), and you tend to *see* the MIME
encoding, then its easier to think of that as "attached" to the "plain
text message".
>> As I understand it, this means that a "Message" is generally a
>> series of text lines similar to that defined in RFC 822 but that
>> may also be divided into one or more sub-parts that are encoded
>> according to the MIME standard (RFC 2045). As such, a "message" can
>> contain another "message", as long as the "contained" message is
>> encapsulated within a MIME entity/component of the other. Thus,
>> since a MIME entity can encapsulate another message, the entity's
>> body may be a full-blown "message" in and of itself.
>
> Why don't they just say that? But what is an entity?
Ehrm... it's defined in section 2.4:
The term "entity", refers specifically to the MIME-defined header
fields and contents of either a message or one of the parts in the
body of a multipart entity. The specification of such entities is
the essence of MIME. Since the contents of an entity are often
called the "body", it makes sense to speak about the body of an
entity. Any sort of field may be present in the header of an
entity, but only those fields whose names begin with "content-"
actually have any MIME-related meaning. Note that this does NOT
imply that they have no meaning at all -- an entity that is also a
message has non-MIME header fields whose meanings are defined by
RFC 822.
So... it sounds like, because it's English, words got re-used and
redefined into confusion. As I understand it, an "entity" is
essentially anything between a pair of MIME delimiters. Entities have
a two-part format based on RFC 822 messages: a header section and a
"the rest of it" section. This latter section is referred to in RFC
822 as the "body", thus dooming us to talk about the entity's "header"
and an entity's "body". On top of that, since "beginning of data" and
"end of data" count as MIME delimiters, an original RFC 822 message
can be thought of (and often is) as a MIME entity, particularly since
they usually include MIME information in their header sections.
When a MIME "entity" is a container for other entities, those
sub-entities are contained within the "body" of their parent. The
parent entity's "body" is segmented by MIME delimiters, and the
sub-entities are always contiguous segments of that "body", and can
therefore be logically referred to as "body parts". Of course, "body
part" is an unfortunate piece of what amounts to slang (perhaps jargon
is a better term) for a sub-entity. Since sub-entities ("body parts")
are entities, they have their own header and body like any other MIME
entity. Thus, talking about a entity's body when the entity is
contained within the body of another entity means that we're talking
about a sub-entity's body, which means we're talking about a "body
part"'s body. Of course, this is only worsened by the fact that we
have a widespread non-recursive definition of the word "body" (namely,
this thing that's covered by my skin) that's a bit more ingrained into
the psyche than email.
(I invented the term "sub-entity" for clarity, to refer to an entity
that is contained within another entity)
But that's a common terminology problem with any digital generic
container (and by generic, I mean that it can contain itself). Kind of
like running a PC emulator within a PC emulator - clear descriptions
of what you're doing start to become strained.
This is a bad example, but I think you can view things similarly when
you consider the Bible. The Bible is a "book". But it contains
"books". So you can make reference to the Book's books.
~Kyle
- --
It is not bigotry to be certain we are right; but it is bigotry to be
unable to imagine how we might possibly be wrong.
-- Gilbert Chesterton
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKYQkjAAoJECuveozR/AWejtUP/1qMzFaFfDBq5FMos1SNa+ii
1+Z99ZqciS34mRz+T6K+Sa/dkPv57wPN0n/4Ml3Rt19lyI8X6p3tKSK0bXwkju2c
BqllVgwhtvUTVflmvSqv252Ez+O8tzjU8f/IerH8G5Cn/77o6LFigY/RVsjKsKo3
42n/nyH0DpGBtxz/1gx7Ibox+CduqoOtwYYI2by97FGoc/pF3iww1q5ou75oOgaj
VuJFgjo92kzt4ylj7nPbDv+kGB0ZeID6qMHqapPwtYz92Qabu1oPKNUus+H1GC/g
4yHZzEyxAx+04JdIMbBclR5sB8EycwSSWxgklVyM4iTcvdnt4A3GMWN8xUcW1EE7
nXiAdzLuoUi5HIaYYqW7fyshFL6PVIi/5rIioWkFOL+n3a6qAhx1F2ZtX7bx1op1
eINXV9UDzs5hZKZe+siNxerGEuwYae4lDK7GAzXbxMzYZP1dRM2E3SWJxNl282w6
URacqxJS1IUmpkDvVTVeMNfA40aRMROlEBoDnofYpfcKmuKPMsC6QHgfA4IpNehg
wV1oBdX7G1Qhy2xiiptPbRpi36zJcbIeqiA5bgadMAsacIWYCuzB1iDdnjmB/D1d
0kiV0Jw59TYtbWkcSyx5rDZoQO4bD651xJg5T1LR1ZoSgMSO3jgwBGsZAR9/15uP
zVIT0KtC/KhmilaRwfhI
=mBVg
-----END PGP SIGNATURE-----
