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)[reply]

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.^[1]

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.^[1]

^ ^a ^b Ned Freed (2008-06-21). "name and filename parameters". Retrieved 2008-06-23.

History of MIME is missing

... and needs to be added. When have the specifications been published first? How have they been adopted? How and when have they changed? etc .. --L.Willms (talk) 19:11, 26 May 2010 (UTC)[reply]

ABNF (Augmented Backus-Naur Form) definition required

In fact such descriptive form should be provided and be required for a protocol specifications!

The existing "definitive" RFC documents are time consumingly verbose and vague and filled with antequated references and justifications useful to historians. X21J (talk) 16:59, 19 September 2011 (UTC)[reply]

Difference between Q-Encoding and quoted printable

The section title is misleading since the text actually does not say what the difference is. — Preceding unsigned comment added by 92.224.158.223 (talk) 19:14, 24 March 2013 (UTC)[reply]

Suggest merging this article together with Internet_media_type

CLOSED

Reject merging of MIME, and Mailcap article(s) as per consensus. No support for a merge. Non-Administrative closure-- GenQuest ^{"Talk to Me"} 22:12, 14 February 2016 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

In the complete list of Internet media types maintained by IANA here: http://www.iana.org/assignments/media-types/media-types.xhtml it states that MIME and Internet Media Types refer to the same thing:

List of Media Types

[RFC2046] specifies that Media Types (formerly known as MIME types) and Media Subtypes will be assigned and listed by the IANA.

http://www.iana.org/assignments/media-types/media-types.xht

Having the two terms separated as separate articles results in confusion as illustrated by this discussion on StackOverflow..

What is the difference between MIME, Internet media type..?

"Internet Media Type" is the correct term for "MIME type".

http://stackoverflow.com/a/17365121/1922144

Also suggest merge of Mailcap, due to reason 3 of WP:MERGEREASON and since the vast majority of the articles content is in regard to mime types.

David Condrey ^{log talk} 02:07, 12 July 2015 (UTC)[reply]

I don't think the article should be merged.
- "MIME" is a specific protocol format and content encoding standard for email message, not a mere concept of content type declaration.
- "MIME type" (that deals exclusively with just content type declaration) is another story. At the time of this comment, "MIME type" is already redirected to "Media type".
- People often confused and think that "MIME type" is a synonym of "MIME", it's not. Merging would further propagate this misconception.Nvtj (talk) 04:25, 19 October 2015 (UTC)[reply]
I don't think the article should be merged.--Sae1962 (talk) 12:06, 19 November 2015 (UTC)[reply]

Oppose merger. The nominator has clearly confused "MIME" with "MIME type". This a very dangerous mistake too. It is like confusing a "restaurant" with a "restaurant's employee". Best regards, Codename Lisa (talk) 16:14, 28 December 2015 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

email syntax highlighting lost

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for 'email' was unfortunately dropped, as can be seen with the plain text formatting on this page and other pages such as Internet Message Access Protocol, DomainKeys Identified Mail, Abuse Reporting Format, Email authentication, Mbox and Simple Mail Transfer Protocol and IEFBR14. If we want 'email' syntax highlight support again, it will need to be added to Pygments.

Also, 'lang=http' appears to not activate unless the first line matches the beginning of a http message. This page has one case where <source lang="http"> is used with MIME-Version: 1.0 appearing first, and the syntax highlighter ignores it. Adding HTTP/1.0 200 OK 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)[reply]

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)[reply]

[ned+ietf-smtp-1] Ned Freed (2008-06-21). "name and filename parameters". Retrieved 2008-06-23.

[1]