On Fri, Jul 17, 2009 at 12:39:19AM -0500, Kyle Wheeler wrote: > No, I mean that MIME components (aka "entities") have meanings that > affect the interpretation of other MIME entities.
ok > 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. It depends ... I distinguish between definitions and descriptions, and since there are often many different descriptions of something (calling themselves definitions), I don't care much for so-called official definitions. Then look at different languages and the descriptions of the same thing, and even if the description of something may be very similar to one in another language, people who have different native languages can (and usually will) have a different understanding/perception/relationship/opinion of the same thing. That is something very difficult to include into a description, and it's usually not done. As to RFCs, the ones I know are more definitions than descriptions, and I consider RFCs as relevant. They are what is in use; implementing something is either compliant with RFCs or may not work. Without RFCs, one MTA couldn't understand another one, and one MUA couldn't display messages created with another one. > > Mutt says that there are 0 attachments. I say there's at least 1. > > We clearly have different definitions of the term. Yes --- but that's ok. > 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. That's fine --- it is what is useful for you. You could rename what is called "attachment counter" to "file counter" or something, or you could say that you would like to have a counter telling you how many attachments there are that you might want to save. 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. > 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. 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. > 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? > >> 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? > For the umpteenth time, no, not all MIME entities are attachments. To me, they are. > > 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". Ok, so which is the current RFC for this? 2045, or is there even another one modifying or superseding 2045? 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? > > 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? I don't think anything about RFC2183 other than that I haven't read it. I was merely telling you what I would do. > 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? as said above What is the use of being told that there is only one attachment? Arguably, #3 is not an attachment because it's supposed to be displayed in line --- as if you have a letter with a picture printed in the middle or somewhere else on it. You wouldn't say that the picture is attached to the letter merely because it's printed onto the paper just like the text (rather than "attached separately" with a staple or with glue). You can do it that way with letters, but not with email, so email has another way of transmitting the picture. But only because there are technical requirements to transmit the picture this way doesn't mean that the picture is an attachment or meant by the sender of the mail to be one. So what's the MUA supposed to tell user? 0 attachments? 1 attachment? 4 attachments? It depends on what the user wants to know or what he defines is useful for him. I'm afraid we can turn this back and forth as long as we want without getting anywhere. If mutt would count everything as attachment what the user defines should qualify as one, the problem would be solved. If that is too difficult to implement, it might be an alternative to count mime entities or mime containers and to rename the counter from "attachment counter" to "mime part counter" or something the like.
