3. Mime header field (MIME Header Fields)
MIME defines a number of new RFC822 headers to describe the Entity Content. These headers will appear at least two places:
(1) As part of the RFC822 message (Message) header information.
(2) In the multipart construct, "the Body Part" message is stored.
The form of these headers is defined as follows:
Entity-Headers: = [Content CRLF]
[Encoding CRLF]
[ID CRLF]
[Description CRLF]
* (MIME-EXTENSION-FIELD CRLF)
Mime-Message-Headers: = Entity-Headers
Fields
Version CRLF
; Current BNF implied entity head information
The order can be ignored.
Mime-part-headers: = Entity-Headers
[fields]
Any field that does not start with "content-"
It is not defined, it can be ignored.
; Current BNF implied entity head information
The order can also be ignored.
The syntax details of different MIME headers will be described in the following sections.
4. MIME-VERSION header field
Since I published RFC 822 in 1982, there is only this Internet message format standard, and almost no one realizes that it is necessary to declare the formats in use. This document is an independent statement that supplements RFC822. Although the extensions made in this document have been defined as being compatible with RFC 822, the mail processing agent still needs to know if a message is composed of new standards.
To this end, this document defines a new header field: "MIME-VERSION". It is used to declare the version number of the format used by the Internet Message Body.
According to the message configured in this document, this header field must be included in the following format:
MIME-VERSION: 1.0
This field is a declaration that indicates that the structure of the message is in line with the format specified in this document.
Because there is a possibility of expanding the message format again in the future document, here is a BNF of the mime-version header field:
Version: = "Mime-Version": "1 * Digit". "1 * DIGIT
In this way, the future format specifiers are constrained as two integers separated by decimal points, which may replace or extend characters: "1.0". If a message is received, its mime-version value is not "1.0", then it can be assumed that it does not meet the specifications of this document.
There is also a thing worth noting that you cannot use the MIME-VERSION mechanism to implement version control of the media type. Special, some formats (such as Application / PostScript) have an agreement number included in the media format. When this convention exists, MIME does not replace it. When this context does not exist, MIME will declare a "Version" parameter in the "Content-Type" field when necessary.
The problem that the implementator should pay attention to: When checking MIME-VERSION, it must ignore any comment portions defined in RFC 822. In detail, the following mime-version fields are equivalent:
MIME-VERSION: 1.0
MIME-VERSION: 1.0 (Produced by Metasend vx.x) Mime-Version: (Product by Metasend Vx.x) 1.0
MIME-VERSION: 1. (Producted by Metasend Vx.x) 0
When the MIME-VERSION field is missing, the agent (whether this agent is in line with MIME requirements) can be arbitrarily explained in accordance with the local agreed. Many of the present uses in the current use. It should be noted that in the actual non-MIME message can contain anything.
Unable to determine that only the plain text content of the US-ASCII character set in a non-MIME message message is likely to use some non-standard local conventions that have earlier than MIME, or content containing other character sets or non- The content of the text, so that the message cannot be identified automatically. (If the Unix Tar compressed file encoded by UUENCODE mode)
