this is a german Web-Mirror of MHONARC.ORG powered by Domainunion AG

[Prev]   [TOC][FAQ][Bugs][Home]   [Next]

Appendix: MIME Conformance

This appendix describes how well MHonArc implements MIME-conformance as defined in RFC 2049: (MIME) Part Five: Conformance Criteria and Examples. Also, additional MIME-related features are summarized.


MIME-Conformance

MIME-conformance is defined in section 2 of RFC 2049: (MIME) Part Five: Conformance Criteria and Examples. Following is the text extracted from section 2 of RFC 2049 with annotations — denoted by MHonArc — added on how well MHonArc conforms to each criteria listed. It should be noted that the criteria listed in RFC 2049 is geared towards interactive MUAs; therefore, some criteria may not be applicable to MHonArc.

NOTE:

All notes about conformance is based upon the default MIME-related resource settings: MIMEFILTERS, MIMEARGS , CHARSETCONVERTERS, CHARSETALIASES.

  1. Always generate a "MIME-Version: 1.0" header field in any message it creates.

    MHonArc

    Not applicable.

  2. Recognize the Content-Transfer-Encoding header field and decode all received data encoded by either quoted-printable or base64 implementations. The identity transformations 7bit, 8bit, and binary must also be recognized.

    MHonArc

    Base64, quoted-printable, 7bit, 8bit, and binary are supported. Also, uuencode is supported: uuencode, x-uuencode, and x-uue.

    Any non-7bit data that is sent without encoding must be properly labelled with a content-transfer-encoding of 8bit or binary, as appropriate. If the underlying transport does not support 8bit or binary (as SMTP [RFC-821] does not), the sender is required to both encode and label data using an appropriate Content-Transfer-Encoding such as quoted-printable or base64.

    MHonArc

    Not applicable.

  3. Must treat any unrecognized Content-Transfer-Encoding as if it had a Content-Type of "application/octet-stream", regardless of whether or not the actual Content-Type is recognized.

    MHonArc

    Currently, MHonArc will still call the registered content-type filter for the specified Content-Type, but the $isdecoded will be set to a false value. With the default set of filters, the $isdecoded flag is ignored. Therefore, behavior could be considered undefined when MHonArc process a message with an unrecognized Content-Transfer-Encoding.

  4. Recognize and interpret the Content-Type header field, and avoid showing users raw data with a Content-Type field other than text. Implementations must be able to send at least text/plain messages, with the character set specified with the charset parameter if it is not US-ASCII.

    MHonArc

    MHonArc conforms to the first sentence of the paragraph The second sentence is not applicable.

  5. Ignore any content type parameters whose names they do not recognize.

    MHonArc

    Yes.

  6. Explicitly handle the following media type values, to at least the following extents:

    Text:

    Image, audio, and video:

    Application:

    Multipart:

    Message:

  7. Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input.

    MHonArc

    Yes. The data is passed to the m2h_external::filter to be saved to an external file.

  8. Conformant user agents are required, if they provide non-standard support for non-MIME messages employing character sets other than US-ASCII, to do so on received messages only. Conforming user agents must not send non-MIME messages containing anything other than US-ASCII text.

    In particular, the use of non-US-ASCII text in mail messages without a MIME-Version field is strongly discouraged as it impedes interoperability when sending messages between regions with different localization conventions. Conforming user agents MUST include proper MIME labelling when sending anything other than plain text in the US-ASCII character set.

    MHonArc

    The DEFCHARSET resource can be used to specify what character set to use if no character set is specified. By default, US-ASCII is assumed.

    In addition, non-MIME user agents should be upgraded if at all possible to include appropriate MIME header information in the messages they send even if nothing else in MIME is supported. This upgrade will have little, if any, effect on non-MIME recipients and will aid MIME in correctly displaying such messages. It also provides a smooth transition path to eventual adoption of other MIME capabilities.

    MHonArc

    Not applicable.

  9. Conforming user agents must ensure that any string of non-white-space printable US-ASCII characters within a "*text" or "*ctext" that begins with "=?" and ends with "?=" be a valid encoded-word. ("begins" means: At the start of the field-body or immediately following linear-white-space; "ends" means: At the end of the field-body or immediately preceding linear-white-space.) In addition, any "word" within a "phrase" that begins with "=?" and ends with "?=" must be a valid encoded-word.

    MHonArc

    Yes.

  10. Conforming user agents must be able to distinguish encoded-words from "text", "ctext", or "word"s, according to the rules in section 4, anytime they appear in appropriate places in message headers. It must support both the "B" and "Q" encodings for any character set which it supports. The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the US-ASCII set.

    MHonArc

    MHonArc supports non-ASCII encoding of text in message headers, including the "B" and "Q" encodings. See CHARSETCONVERTERS for a list of charsets supported.


Other Stuff Supported

The following lists other MIME-related features supported by MHonArc:


[Prev]   [TOC][FAQ][Bugs][Home]   [Next]

$Date: 2003/10/06 22:04:14 $
MHonArc
Copyright © 1999, Earl Hood, mhonarc@mhonarc.org