3. MIME header fields ( the MIME Header Fields )<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
MIME defines a number of new RFC822 header fields to describe MIME entity content (Content Entity) . These header fields occur in at least two places:
(1) As a rule RFC822 message (message) part of the header information.
(2) In the multiple part structure ( multipart Construct ) was present in the "main body portion" ( body Part header information) in the.
Forms of these header fields are 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-header information
; Order can be ignored.
MIME-part-headers := entity-headers
[ fields ]
; Any with " Content- field" begins
; Have not been defined, can be ignored.
; Current BNF implied entity-header information
; Orders can be ignored.
Different MIME syntax details header fields will be described in the following sections.
4. MIME-Version header field
Since 1982 it released in the RFC 822 since, in fact, there is only this kind of Internet message format standards, but few people are aware of the need to use those statements in the format. This document is a supplement RFC822 separate note. Although the extension made in this document have been defined as the RFC 822 compatible, however, the mail processing agents still need to know whether a message is constituted in accordance with the new standard.
To this end, this document defines a new header field: " MIME-Version ." It is used to declare Internet message body (message body) version number of the format used.
According to this document format message constituted (Message) , the header field must contain the following format:
MIME-Version: 1.0
This field is a statement that represents the structure of the message conform to the format set forth in this document.
Because the future of the document possible extension of the standard message format again, so here is MIME-Version header field BNF :
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Thus, future format specifier are constrained to two decimal integers separated, they may alternatively or expanded characters: " 1.0 ." If a message is received, its MIME-version value than " 1.0 ", then it can be assumed that this document does not meet specifications.
One more thing to note is that not using MIME-Version mechanism to implement version control of the media types. In particular, some of the format (e.g., file application / PostScript ) has a contracted version number contained in the interior of the media format. When the presence of this convention, the MIME not be substituted. When this agreement does not exist, MIME will be used "when necessary Content-of the type " field of a " Version declared" parameter.
Problems implementors to note: checking MIME-Version of time, be sure to ignore any in RFC822 comment section defined. In detail, the following MIME-Version fields are equivalent:
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
When the missing MIME-Version When field received mail agent (whether the agent meets MIME requirements) can be in accordance with local conventions, any explanation of the message body. Many such agreement exists in current use. It should be noted that in actual Africa MIME messages can contain anything.
Unable to identify a non- MIME mail message contains only US-ASCII plain text character set, because the news is likely to use some non-standard ratio of MIME local conventions occur earlier or contain content or other character sets content of the text, so that the message can not be automatically identified. (As with UUENCODE coded in UNIX tar archive)