|WikiProject Computing||(Rated C-class, High-importance)|
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)
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.
History of MIME is missing
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)
Difference between Q-Encoding and quoted printable
Suggest merging this article together with Internet_media_type
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)