-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Friday, July 17 at 11:37 AM, quoth lee:
> Mutt already supports this in that you can specify what things
> should qualify as attachments and be counted. The problem is that
> the counting doesn't work right.
Agreed!
>> What's the utility of your definition?
>
> You mean what the usefulness is of my considering everything that is
> attached to a message as an attachment? It gives me an impression
> about how messed up a message might be. If it's a message that might
> be a SPAM mail, it will prevent me from opening it.
Hm. See, I find that I really don't care how "messed up" a message
might be. For example, I often get emails from corporate secretaries
that use Outlook and some goofy HTML stationery (complete with
background picture, goofy fonts, corporate logo, etc.). Knowing that
it's a complex MIME structure isn't a useful piece of information to
me.
But to each his own, I suppose.
> What is the usefulness of knowing if something is attached to a
> message that you might want to save to a separate file? It's useful to
> you, but not really useful to me.
Well, the usefulness to me is that occasionally I receive messages
that don't make it clear that there IS an attachment in the text. For
example, I'll get an email that reads "Can you make sure that the
schedules are right for next month?". It also has a copy of the
schedules attached (probably that's messed up and isn't what had
previously been established as the schedules), but that's an easy fact
to miss in a text-based email reader (GUI email programs, and webmail,
often make such things a bit more obvious).
>> Why do *you* care how many containers are on the ship?
>
> See above --- you care about what's in the containers, I care about
> how many containers there are.
>
> How do you want to unload, i. e. would you prefer to unload all the
> bricks at once by unloading the container (save the whole container to
> disk with everything in it), or would you rather open the container
> and unload (save to disk) one brick (file) at a time?
See, here's where I think the metaphor becomes a bit strained. I don't
know how what you're talking about maps back to email.
>>>> 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?
>
> Well, what were you saying?
According to the Content-Disposition RFC (2183), which is what defines
the idea of an "inline" MIME entity versus an "attached" MIME entity,
the difference is in presentation (aka "display") to the recipient.
Here's how they describe it:
Two common ways of presenting multipart electronic messages are as
a main document with a list of separate attachments, and as a
single document with the various parts expanded (displayed)
inline. The display of an attachment is generally construed to
require positive action on the part of the recipient, while inline
message components are displayed automatically when the message is
viewed.
That, I think, pretty much restates what I was saying.
In particular, mutt observes and respects the two disposition types
outlined in that RFC:
2.1 The Inline Disposition Type
A bodypart should be marked `inline' if it is intended to be
displayed automatically upon display of the message. Inline
bodyparts should be presented in the order in which they
occur, subject to the normal semantics of multipart messages.
2.2 The Attachment Disposition Type
Bodyparts can be designated `attachment' to indicate that they
are separate from the main body of the mail message, and that
their display should not be automatic, but contingent upon
some further action of the user. The MUA might instead
present the user of a bitmap terminal with an iconic
representation of the attachments, or, on character terminals,
with a list of attachments from which the user could select
for viewing or storage.
>> For the umpteenth time, no, not all MIME entities are attachments.
>
> To me, they are.
Well, then I think it's safe to say that you have a rather unusual
view of MIME entities that is not shared by (at least some of) the
designers of the MIME standard.
> Ok, so which is the current RFC for this? 2045, or is there even
> another one modifying or superseding 2045?
There isn't an RFC that obsoletes 2045. It is updated by 2184 (MIME
Parameter values & character sets), 2231 (obsolets 2184), and 5335
(internationalized headers), but RFC 2045 is the most recent version
of the MIME standard. (check here to verify that status, if you like:
http://tools.ietf.org/html/rfc2045 - relationships to other RFCs is at
the top)
> 2045 says:
>
>
> "
> The term "message", when not further qualified, means either a
> (complete or "top-level") RFC 822 message being transferred on a
> network, or a message encapsulated in a body of type "message/rfc822"
> or "message/partial".
> "
>
>
> That's a rather unlucky definition because it uses the term it defines
> in the definition. I don't understand what "message" means when they
> say "a message encapsulated in a body". Do they mean an RFC822
> message? Do they mean "body" in the sense of RFC822?
Keep reading:
2.6. Body
The term "body", when not further qualified, means the body of
an entity, that is, the body of either a message or of a body
part.
NOTE: The previous four definitions are clearly circular. This
is unavoidable, since the overall structure of a MIME message
is indeed recursive.
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.
> I'm afraid we can turn this back and forth as long as we want
> without getting anywhere.
Agreed.
~Kyle
- --
If I had only known, I would have been a locksmith.
-- Albert Einstein
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKYMUMAAoJECuveozR/AWe/J4P/2Ct3CvefhC/wgyYyJKfYrEH
Pxh0GUKc9wyThX7AlAoDvsp+D6a1Z8udJDrFXXbomaYT+LfdfUBmYcpIp92ppDMl
+4D5QAnB8Rb6s4OFgKnoANICF7VlOGtZ4cRWAUKpDld0PJXdsW3obTWrGy0Nj4WJ
xn8/VBCs+eI7zq4oMlJRLgBn2w/T3xV4ntqLbQi/A3zu484nwAUlsOCiJcF1BpqA
1QB4yNnQxo9F69hO0nuIzGZlpKHQcuTM7uTlik752lSbuMMe1Og2TzgcYvoiBMb8
VCsbWEZ7A4FX61ZUaLLmWGPJPv5APN1tz3PqQi3o+gOslxJbqrX86/cMf5RHYzDR
pA4VfyToRBuMr3Cx0Bp+7FZA9jjtd7YL6TyIytg4qivJCTJALW4HQCZ/4EYpsoX+
IMM5znoSa3oogKmyW0yZZ3/nVFbdNLSJfzWaa6Bs8WcusrSC4dz6X2nTi405fnoG
Zhg6H1d44Zm0Xdyh36V8Lg0HIbdP+sLqRidmbxTKC9hQ/FT1j9I9oXWoPDidG2Hr
VPiqkK8YO5uZschdBlnkAlJcnefXlFdMUcJkRdz8gj3l61ZlfvUCeBFctlMvU+OQ
dDZTGE39ttuC03gBFFEFPAemojM1helY6jure00z3jvJCnEhIFlhM7QNeRF48Ry5
Cz0xraG2dhxCWkdWVavL
=ZeRy
-----END PGP SIGNATURE-----
