Talk:MIME

Content-Disposition section
Copied below is the original section titled "Content-Disposition". For some obscure reason, the discussion is all mixed up with filename parameters. I am copying the original text here before I edit it in the main page. Reddyuday (talk) 16:25, 1 April 2010 (UTC)

Content-Disposition
The original MIME specifications only provided a means to associate filenames with application/octet-stream parts. This was done through the use of a name= parameter on the content-type. The theory here was that filenames were mostly used for type information and therefore did not need to be present in most cases. It was a mistake. The specification of content-disposition attempted to provide a more general means of providing file name information by defining a filename parameter as part of the content-disposition field.

The following example is taken from RFC 2183, where the header is defined Content-Disposition: attachment; filename=genome.jpeg; modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

The filename may be encoded as defined by RFC 2231. Besides attachment, one can specify inline, or any other disposition type. Unfortunately, no name is defined for the nominal "default" disposition that corresponds to no content-disposition being present. Thus the recommended practice for generating agents is to only include filename information when it is necessary, also to avoid leaking sensitive information. If filename information has to be included, an agent should either put it in a filename= parameter or both a filename= and name= parameter. Never ever use just a name= parameter because that opens up to gratuitous interpretation of the part using an unintended disposition value.

appearing first, and the syntax highlighter ignores it. Adding  as the first line would mean it highlights correctly. See e.g.)

I havent been able to find any handler in Pygments which is a suitable fallback for 'email', however 'http' might be an alternative that works in some cases, but especially when 'email' was used for non-email source such as here. John Vandenberg (chat) 04:06, 13 July 2015 (UTC)

How is MIME on the presentation layer?
SMTP is OSI layer 7 (the application layer). SMTP (RFC 5321) in turn delivers .eml (RFC 5322), which may then contain MIME content. Since MIME is two levels deep within layer 7, it couldn't possibly be part of OSI layer 5 (the presentation layer). (Compare with CSS, which often lives in HTML, which is usually delivered by HTTP, which is also layer 7.) I propose removing all references to abstraction layers in the MIME article. Adam KatzΔ☎  02:17, 10 March 2017 (UTC)