[OpenSPARC-T2-DV] / tools / perl-5.8.0 / doc / MHonArc / app-mimeconf.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML//EN">
<HTML>
<HEAD>
<TITLE>MHonArc v2.5 -- Appendix: MIME Conformance
</TITLE>
</HEAD>
<!--
<BODY background="ssbg75.jpg"
      text="#000000" link="#0000ee" vlink="#551a8b" alink="ff0000">
-->
<BODY>

<!--X-NavButtons-Start-->
<table width="100%">
<tr valign="top">
<td align="left"><nobr><a href="app-api.html"><img src="prev.png"border=0 alt="[Prev]"></a>&nbsp;&nbsp;&nbsp;</nobr></td><td align="center" width="99%"><a href="mhonarc.html"><img src="up.png" border=0 alt="[TOC]"></a><a href="faq/faq.html"><img src="faq.png" border=0 alt="[FAQ]"></a><a href="app-bugs.html"><img src="bug.png" border=0 alt="[Bugs]"></a><a href="http://www.mhonarc.org/"><img src="home.png" border=0 alt="[Home]"></a></td><td align="right"><nobr>&nbsp;&nbsp;&nbsp;<a href="app-bugs.html"><img src="next.png" border=0 alt="[Next]"></a></nobr></td></tr></table>
<!--X-NavButtons-End-->
<HR>

<H1><a name="appendix-mimeconf">Appendix: MIME Conformance</a></H1>

<P>This appendix describes how well MHonArc implements
MIME-conformance as defined in
<a href="http://www.pobox.com/~ehood/MIME/2049/rfc2049.html">
RFC 2049: (MIME) Part Five: Conformance Criteria and Examples</a>.
Also, additional MIME-related features are summarized.
</P>

<!--X-TOC-Start-->
<ul>
<li><a href="#mime-conformance">MIME-Conformance</a>
<li><a href="#otherstuff">Other Stuff Supported</a>
</ul>
<!--X-TOC-End-->

<hr>
<H2><a name="mime-conformance">MIME-Conformance</a></H2>

<p>MIME-conformance is defined in section 2 of
<a href="http://www.pobox.com/~ehood/MIME/2049/rfc2049.html">
RFC 2049: (MIME) Part Five: Conformance Criteria and Examples</a>.
Following is the text extracted from section 2 of RFC 2049 with
annotations added on how 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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong>NOTE</strong></td>
<td><p>All notes about conformance is based upon the default MIME-related
resource settings:
<a href="resources/mimefilters.html">MIMEFILTERS</a>, 
<a href="resources/charsetconverters.html">CHARSETCONVERTERS</a>, 
<a href="resources/mimeargs.html">MIMEARGS</a> 
</p>
</td>
</tr>
</table>

<ol>
<li><p>
Always generate a "MIME-Version: 1.0" header field in
          any message it creates.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Not applicable.
</p>
<br>
</td>
</tr>
</table>
</li>
<li><p>
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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Base64, quoted-printable, 7bit, 8bit, and binary are supported.
Also, uuencode is supported: <tt>uuencode</tt>, <tt>x-uuencode</tt>, and
<tt>x-uue</tt>.
</p>
<br>
</td>
</tr>
</table>
<p>
          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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Not applicable.
</p>
<br>
</td>
</tr>
</table>
</li>
<li><p>
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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Currently, MHonArc will still call the registered
<a href="resources/mimefilters.html">content-type filter</a> for the specified
Content-Type, but the <b><tt>$isdecoded</tt></b> will be set to a false
value.  With the default set of filters, the <b><tt>$isdecoded</tt></b>
flag is ignored.  Therefore, behavior could be considered undefined when
MHonArc process a message with an unrecognized Content-Transfer-Encoding.
</p>
<br>
</td>
</tr>
</table>
</li>
<li><p>
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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>MHonArc conforms to the first sentence of the paragraph
The second sentence is not applicable.
</p>
<br>
</td>
</tr>
</table>
</li>
<li><p>
Ignore any content type parameters whose names they do
          not recognize.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
</li>
<li><p>
Explicitly handle the following media type values, to
          at least the following extents:
</p>
<p>
          Text:
</p>
<ul>
<li><p>Recognize and display "text" mail with the
            character set "US-ASCII."
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
<li><p>Recognize other character sets at least to the
            extent of being able to inform the user about what
            character set the message uses.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Not really applicable.  Warnings are generated during processing
if a character set is encountered that is not recognized.
</p>
<br>
</td>
</tr>
</table>
<li><p>Recognize the "ISO-8859-*" character sets to the
            extent of being able to display those characters that
            are common to ISO-8859-* and US-ASCII, namely all
            characters represented by octet values 1-127.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
<li><p>For unrecognized subtypes in a known character
            set, show or offer to show the user the "raw" version
            of the data after conversion of the content from
            canonical form to local form.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>MHonArc will treat the data as text/plain and convert.
</p>
<br>
</td>
</tr>
</table>
<li><p>Treat material in an unknown character set as if
            it were "application/octet-stream".
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>No.  A warning is generated for unknown character sets.  The
data will be shown in raw form, with HTML special characters converted
to entity references.  This behavior is the default because some MUAs
are known to give incorrect charset parameters.
</p>
<br>
</td>
</tr>
</table>
</ul>
<p>
  Image, audio, and video:
</p>
<ul>
    <li><p>At a minumum provide facilities to treat any
    unrecognized subtypes as if they were
    "application/octet-stream".
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>All image, audio, and video types are saved to an external file
with a link to the file created in the HTML.  For applicable image types, they
are inlined unless the image has an attachment content-disposition.
</p>
<br>
</td>
</tr>
</table>
</ul>
<p>
  Application:
</p>
<ul>
    <li><p>Offer the ability to remove either of the quoted-printable or base64 encodings defined in this
    document if they were used and put the resulting
    information in a user file.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Most application types are decoded and saved to an external file
with a link to the file created in the HTML.  Some application types
can be converted directly to HTML.
</p>
</td>
</tr>
</table>
</ul>
<p>
  Multipart:
</p>
<ul>
    <li><p>Recognize the mixed subtype.  Display all relevant
    information on the message level and the body part
    header level and then display or offer to display
    each of the body parts individually.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.  Each part is automatically processed according to its
media-type.
</p>
<br>
</td>
</tr>
</table>
    <li><p>Recognize the "alternative" subtype, and avoid
    showing the user redundant parts of
    multipart/alternative mail.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
    <li><p>Recognize the "multipart/digest" subtype,
    specifically using "message/rfc822" rather than
    "text/plain" as the default media type for body parts
    inside "multipart/digest" entities.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
    <li><p>Treat any unrecognized subtypes as if they were
    "mixed".
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
</ul>
<p>
  Message:
</p>
<ul>
    <li><p>Recognize and display at least the RFC822 message
    encapsulation (message/rfc822) in such a way as to
    preserve any recursive structure, that is, displaying
    or offering to display the encapsulated data in
    accordance with its media type.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
    <li><p>Treat any unrecognized subtypes as if they were
    "application/octet-stream".
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
</ul>
<li><p>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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.  The data is passed to the
<a href="resources/mimefilters.html#m2h_external">m2h_external::filter</a>
to be saved to an external file.
</p>
<br>
</td>
</tr>
</table>
<li><p>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.
</p>
<p>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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>The
<a href="resources/mimefilters.html#m2h_text_plain">m2h_text_plain::filter</a>
supports an option to specify what character set to use if no character
set is specified.  By default, ISO-8859-1 is assumed.
</p>
<br>
</td>
</tr>
</table>
<p>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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Not applicable.
</p>
<br>
</td>
</tr>
</table>
<li><p>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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>Yes.
</p>
<br>
</td>
</tr>
</table>
<li><p>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.
</p>
<table border=0 cellpadding=4>
<tr valign=top>
<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
<td><p>MHonArc supports non-ASCII encoding of text in message headers,
including the "B" and "Q" encodings.  By default, US-ASCII,
ISO-8859-[1-10], and ISO-2022-JP are supported.  For encoded
words with an unrecognized character set, the word is left in
encoded form.  Additional character set support can be added via the
<a href="resources/charsetconverters.html">CHARSETCONVERTERS</a> resource.
</p>
<br>
</td>
</tr>
</table>
</ol>


<hr>
<H2><a name="otherstuff">Other Stuff Supported</a></H2>

<p>The following lists other MIME-related features supported
by MHonArc:</p>

<ul>

<li><p>Support for uuencoding as a Content-Transfer-Encoding.
</p>
</li>

<li><p>Support for many media-types (including the ability to extend
that support).  For a complete list, along with more
information, see the
<a href="resources/mimefilters.html">MIMEFILTERS</a> resource.
Note, many media-types cannot be directly converted into HTML.  For
these types, they are saved to a separate file with a link to the
file inserted in the converted HTML message data.
</p>
</li>

<li><p>Support for <b><tt>multipart/related</tt></b> by allowing
<a href="resources/mimefilters.html">filters</a> to access other
message parts via content-ids.
</p>
</li>

<li><p>Support for <b><tt>cid:</tt></b> URLs in <b><tt>text/html</tt></b>
data.  The provides support for things like MHTML:
<em>MIME E-mail Encapsulation of Aggregate Documents</em>,
<a href="http://www.ietf.org/rfc/rfc2110.txt">RFC 2110</a>.
</p>
</li>

<li><p>Support for
<a href="http://www.ietf.org/rfc/rfc2369.txt">RFC 2369</a>,
<em>The Use of URLs as Meta-Syntax for Core Mail List Commands
and their Transport through Message Header Fields</em>.  The
URLs in list header fields will be converted into hypertext links.
</p>
</li>

</ul>

<hr>
<!--X-NavButtons-Start-->
<table width="100%">
<tr valign="top">
<td align="left"><nobr><a href="app-api.html"><img src="prev.png"border=0 alt="[Prev]"></a>&nbsp;&nbsp;&nbsp;</nobr></td><td align="center" width="99%"><a href="mhonarc.html"><img src="up.png" border=0 alt="[TOC]"></a><a href="faq/faq.html"><img src="faq.png" border=0 alt="[FAQ]"></a><a href="app-bugs.html"><img src="bug.png" border=0 alt="[Bugs]"></a><a href="http://www.mhonarc.org/"><img src="home.png" border=0 alt="[Home]"></a></td><td align="right"><nobr>&nbsp;&nbsp;&nbsp;<a href="app-bugs.html"><img src="next.png" border=0 alt="[Next]"></a></nobr></td></tr></table>
<!--X-NavButtons-End-->

<HR>
<address>
$Date: 2001/12/24 14:38:07 $ <br>
<img align="top" src="monicon.png" alt="">
<a href="http://www.mhonarc.org/"><strong>MHonArc</strong></a><br>
Copyright &#169; 1999, <a href="http://www.mhonarc.org/~ehood/"
>Earl Hood</a>, <a href="mailto:mhonarc@mhonarc.org"
>mhonarc@mhonarc.org</a><br>
</address>

</BODY>
</HTML>
Commit	Line	Data
86530b38 AT	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML//EN">
	2	<HTML>
	3	<HEAD>
	4	<TITLE>MHonArc v2.5 -- Appendix: MIME Conformance
	5	</TITLE>
	6	</HEAD>
	7	<!--
	8	<BODY background="ssbg75.jpg"
	9	text="#000000" link="#0000ee" vlink="#551a8b" alink="ff0000">
	10	-->
	11	<BODY>
	12
	13	<!--X-NavButtons-Start-->
	14	<table width="100%">
	15	<tr valign="top">
	16	<td align="left"><nobr><a href="app-api.html"><img src="prev.png"border=0 alt="[Prev]"></a>   </nobr></td><td align="center" width="99%"><a href="mhonarc.html"><img src="up.png" border=0 alt="[TOC]"></a><a href="faq/faq.html"><img src="faq.png" border=0 alt="[FAQ]"></a><a href="app-bugs.html"><img src="bug.png" border=0 alt="[Bugs]"></a><a href="http://www.mhonarc.org/"><img src="home.png" border=0 alt="[Home]"></a></td><td align="right"><nobr>   <a href="app-bugs.html"><img src="next.png" border=0 alt="[Next]"></a></nobr></td></tr></table>
	17	<!--X-NavButtons-End-->
	18	<HR>
	19
	20	<H1><a name="appendix-mimeconf">Appendix: MIME Conformance</a></H1>
	21
	22	<P>This appendix describes how well MHonArc implements
	23	MIME-conformance as defined in
	24	<a href="http://www.pobox.com/~ehood/MIME/2049/rfc2049.html">
	25	RFC 2049: (MIME) Part Five: Conformance Criteria and Examples</a>.
	26	Also, additional MIME-related features are summarized.
	27	</P>
	28
	29	<!--X-TOC-Start-->
	30	<ul>
	31	<li><a href="#mime-conformance">MIME-Conformance</a>
	32	<li><a href="#otherstuff">Other Stuff Supported</a>
	33	</ul>
	34	<!--X-TOC-End-->
	35
	36	<hr>
	37	<H2><a name="mime-conformance">MIME-Conformance</a></H2>
	38
	39	<p>MIME-conformance is defined in section 2 of
	40	<a href="http://www.pobox.com/~ehood/MIME/2049/rfc2049.html">
	41	RFC 2049: (MIME) Part Five: Conformance Criteria and Examples</a>.
	42	Following is the text extracted from section 2 of RFC 2049 with
	43	annotations added on how MHonArc conforms to each criteria listed.
	44	It should be noted that the criteria listed in RFC 2049 is geared
	45	towards interactive MUAs; therefore, some criteria may not be
	46	applicable to MHonArc.
	47	</p>
	48	<table border=0 cellpadding=4>
	49	<tr valign=top>
	50	<td><strong>NOTE</strong></td>
	51	<td><p>All notes about conformance is based upon the default MIME-related
	52	resource settings:
	53	<a href="resources/mimefilters.html">MIMEFILTERS</a>,
	54	<a href="resources/charsetconverters.html">CHARSETCONVERTERS</a>,
	55	<a href="resources/mimeargs.html">MIMEARGS</a>
	56	</p>
	57	</td>
	58	</tr>
	59	</table>
	60
	61	<ol>
	62	<li><p>
	63	Always generate a "MIME-Version: 1.0" header field in
	64	any message it creates.
65	</p>
66	<table border=0 cellpadding=4>
67	<tr valign=top>
68	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
69	<td><p>Not applicable.
70	</p>
71	<br>
72	</td>
73	</tr>
74	</table>
75	</li>
76	<li><p>
77	Recognize the Content-Transfer-Encoding header field
78	and decode all received data encoded by either quoted-printable or base64 implementations. The identity
79	transformations 7bit, 8bit, and binary must also be
80	recognized.
81	</p>
82	<table border=0 cellpadding=4>
83	<tr valign=top>
84	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
85	<td><p>Base64, quoted-printable, 7bit, 8bit, and binary are supported.
86	Also, uuencode is supported: <tt>uuencode</tt>, <tt>x-uuencode</tt>, and
87	<tt>x-uue</tt>.
88	</p>
89	<br>
90	</td>
91	</tr>
92	</table>
93	<p>
94	Any non-7bit data that is sent without encoding must be
95	properly labelled with a content-transfer-encoding of
96	8bit or binary, as appropriate. If the underlying
97	transport does not support 8bit or binary (as SMTP
98	[RFC-821] does not), the sender is required to both
99	encode and label data using an appropriate Content-Transfer-Encoding such as quoted-printable or base64.
100	</p>
101	<table border=0 cellpadding=4>
102	<tr valign=top>
103	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
104	<td><p>Not applicable.
105	</p>
106	<br>
107	</td>
108	</tr>
109	</table>
110	</li>
111	<li><p>
112	Must treat any unrecognized Content-Transfer-Encoding
113	as if it had a Content-Type of "application/octet-stream", regardless of whether or not the actual
114	Content-Type is recognized.
115	</p>
116	<table border=0 cellpadding=4>
117	<tr valign=top>
118	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
119	<td><p>Currently, MHonArc will still call the registered
120	<a href="resources/mimefilters.html">content-type filter</a> for the specified
121	Content-Type, but the <b><tt>$isdecoded</tt></b> will be set to a false
122	value. With the default set of filters, the <b><tt>$isdecoded</tt></b>
123	flag is ignored. Therefore, behavior could be considered undefined when
124	MHonArc process a message with an unrecognized Content-Transfer-Encoding.
125	</p>
126	<br>
127	</td>
128	</tr>
129	</table>
130	</li>
131	<li><p>
132	Recognize and interpret the Content-Type header field,
133	and avoid showing users raw data with a Content-Type
134	field other than text. Implementations must be able
135	to send at least text/plain messages, with the
136	character set specified with the charset parameter if
137	it is not US-ASCII.
138	</p>
139	<table border=0 cellpadding=4>
140	<tr valign=top>
141	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
142	<td><p>MHonArc conforms to the first sentence of the paragraph
143	The second sentence is not applicable.
144	</p>
145	<br>
146	</td>
147	</tr>
148	</table>
149	</li>
150	<li><p>
151	Ignore any content type parameters whose names they do
152	not recognize.
153	</p>
154	<table border=0 cellpadding=4>
155	<tr valign=top>
156	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
157	<td><p>Yes.
158	</p>
159	<br>
160	</td>
161	</tr>
162	</table>
163	</li>
164	<li><p>
165	Explicitly handle the following media type values, to
166	at least the following extents:
167	</p>
168	<p>
169	Text:
170	</p>
171	<ul>
172	<li><p>Recognize and display "text" mail with the
173	character set "US-ASCII."
174	</p>
175	<table border=0 cellpadding=4>
176	<tr valign=top>
177	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
178	<td><p>Yes.
179	</p>
180	<br>
181	</td>
182	</tr>
183	</table>
184	<li><p>Recognize other character sets at least to the
185	extent of being able to inform the user about what
186	character set the message uses.
187	</p>
188	<table border=0 cellpadding=4>
189	<tr valign=top>
190	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
191	<td><p>Not really applicable. Warnings are generated during processing
192	if a character set is encountered that is not recognized.
193	</p>
194	<br>
195	</td>
196	</tr>
197	</table>
198	<li><p>Recognize the "ISO-8859-*" character sets to the
199	extent of being able to display those characters that
200	are common to ISO-8859-* and US-ASCII, namely all
201	characters represented by octet values 1-127.
202	</p>
203	<table border=0 cellpadding=4>
204	<tr valign=top>
205	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
206	<td><p>Yes.
207	</p>
208	<br>
209	</td>
210	</tr>
211	</table>
212	<li><p>For unrecognized subtypes in a known character
213	set, show or offer to show the user the "raw" version
214	of the data after conversion of the content from
215	canonical form to local form.
216	</p>
217	<table border=0 cellpadding=4>
218	<tr valign=top>
219	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
220	<td><p>MHonArc will treat the data as text/plain and convert.
221	</p>
222	<br>
223	</td>
224	</tr>
225	</table>
226	<li><p>Treat material in an unknown character set as if
227	it were "application/octet-stream".
228	</p>
229	<table border=0 cellpadding=4>
230	<tr valign=top>
231	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
232	<td><p>No. A warning is generated for unknown character sets. The
233	data will be shown in raw form, with HTML special characters converted
234	to entity references. This behavior is the default because some MUAs
235	are known to give incorrect charset parameters.
236	</p>
237	<br>
238	</td>
239	</tr>
240	</table>
241	</ul>
242	<p>
243	Image, audio, and video:
244	</p>
245	<ul>
246	<li><p>At a minumum provide facilities to treat any
247	unrecognized subtypes as if they were
248	"application/octet-stream".
249	</p>
250	<table border=0 cellpadding=4>
251	<tr valign=top>
252	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
253	<td><p>All image, audio, and video types are saved to an external file
254	with a link to the file created in the HTML. For applicable image types, they
255	are inlined unless the image has an attachment content-disposition.
256	</p>
257	<br>
258	</td>
259	</tr>
260	</table>
261	</ul>
262	<p>
263	Application:
264	</p>
265	<ul>
266	<li><p>Offer the ability to remove either of the quoted-printable or base64 encodings defined in this
267	document if they were used and put the resulting
268	information in a user file.
269	</p>
270	<table border=0 cellpadding=4>
271	<tr valign=top>
272	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
273	<td><p>Most application types are decoded and saved to an external file
274	with a link to the file created in the HTML. Some application types
275	can be converted directly to HTML.
276	</p>
277	</td>
278	</tr>
279	</table>
280	</ul>
281	<p>
282	Multipart:
283	</p>
284	<ul>
285	<li><p>Recognize the mixed subtype. Display all relevant
286	information on the message level and the body part
287	header level and then display or offer to display
288	each of the body parts individually.
289	</p>
290	<table border=0 cellpadding=4>
291	<tr valign=top>
292	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
293	<td><p>Yes. Each part is automatically processed according to its
294	media-type.
295	</p>
296	<br>
297	</td>
298	</tr>
299	</table>
300	<li><p>Recognize the "alternative" subtype, and avoid
301	showing the user redundant parts of
302	multipart/alternative mail.
303	</p>
304	<table border=0 cellpadding=4>
305	<tr valign=top>
306	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
307	<td><p>Yes.
308	</p>
309	<br>
310	</td>
311	</tr>
312	</table>
313	<li><p>Recognize the "multipart/digest" subtype,
314	specifically using "message/rfc822" rather than
315	"text/plain" as the default media type for body parts
316	inside "multipart/digest" entities.
317	</p>
318	<table border=0 cellpadding=4>
319	<tr valign=top>
320	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
321	<td><p>Yes.
322	</p>
323	<br>
324	</td>
325	</tr>
326	</table>
327	<li><p>Treat any unrecognized subtypes as if they were
328	"mixed".
329	</p>
330	<table border=0 cellpadding=4>
331	<tr valign=top>
332	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
333	<td><p>Yes.
334	</p>
335	<br>
336	</td>
337	</tr>
338	</table>
339	</ul>
340	<p>
341	Message:
342	</p>
343	<ul>
344	<li><p>Recognize and display at least the RFC822 message
345	encapsulation (message/rfc822) in such a way as to
346	preserve any recursive structure, that is, displaying
347	or offering to display the encapsulated data in
348	accordance with its media type.
349	</p>
350	<table border=0 cellpadding=4>
351	<tr valign=top>
352	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
353	<td><p>Yes.
354	</p>
355	<br>
356	</td>
357	</tr>
358	</table>
359	<li><p>Treat any unrecognized subtypes as if they were
360	"application/octet-stream".
361	</p>
362	<table border=0 cellpadding=4>
363	<tr valign=top>
364	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
365	<td><p>Yes.
366	</p>
367	<br>
368	</td>
369	</tr>
370	</table>
371	</ul>
372	<li><p>Upon encountering any unrecognized Content-Type field,
373	an implementation must treat it as if it had a media
374	type of "application/octet-stream" with no parameter
375	sub-arguments. How such data are handled is up to an
376	implementation, but likely options for handling such
377	unrecognized data include offering the user to write it
378	into a file (decoded from its mail transport format) or
379	offering the user to name a program to which the
380	decoded data should be passed as input.
381	</p>
382	<table border=0 cellpadding=4>
383	<tr valign=top>
384	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
385	<td><p>Yes. The data is passed to the
386	<a href="resources/mimefilters.html#m2h_external">m2h_external::filter</a>
387	to be saved to an external file.
388	</p>
389	<br>
390	</td>
391	</tr>
392	</table>
393	<li><p>Conformant user agents are required, if they provide
394	non-standard support for non-MIME messages employing
395	character sets other than US-ASCII, to do so on
396	received messages only. Conforming user agents must not
397	send non-MIME messages containing anything other than
398	US-ASCII text.
399	</p>
400	<p>In particular, the use of non-US-ASCII text in mail
401	messages without a MIME-Version field is strongly
402	discouraged as it impedes interoperability when sending
403	messages between regions with different localization
404	conventions. Conforming user agents MUST include proper
405	MIME labelling when sending anything other than plain
406	text in the US-ASCII character set.
407	</p>
408	<table border=0 cellpadding=4>
409	<tr valign=top>
410	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
411	<td><p>The
412	<a href="resources/mimefilters.html#m2h_text_plain">m2h_text_plain::filter</a>
413	supports an option to specify what character set to use if no character
414	set is specified. By default, ISO-8859-1 is assumed.
415	</p>
416	<br>
417	</td>
418	</tr>
419	</table>
420	<p>In addition, non-MIME user agents should be upgraded if
421	at all possible to include appropriate MIME header
422	information in the messages they send even if nothing
423	else in MIME is supported. This upgrade will have
424	little, if any, effect on non-MIME recipients and will
425	aid MIME in correctly displaying such messages. It
426	also provides a smooth transition path to eventual
427	adoption of other MIME capabilities.
428	</p>
429	<table border=0 cellpadding=4>
430	<tr valign=top>
431	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
432	<td><p>Not applicable.
433	</p>
434	<br>
435	</td>
436	</tr>
437	</table>
438	<li><p>Conforming user agents must ensure that any string of
439	non-white-space printable US-ASCII characters within a
440	"text" or "ctext" that begins with "=?" and ends with
441	"?=" be a valid encoded-word. ("begins" means: At the
442	start of the field-body or immediately following
443	linear-white-space; "ends" means: At the end of the
444	field-body or immediately preceding linear-white-space.) In addition, any "word" within a "phrase" that
445	begins with "=?" and ends with "?=" must be a valid
446	encoded-word.
447	</p>
448	<table border=0 cellpadding=4>
449	<tr valign=top>
450	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
451	<td><p>Yes.
452	</p>
453	<br>
454	</td>
455	</tr>
456	</table>
457	<li><p>Conforming user agents must be able to distinguish
458	encoded-words from "text", "ctext", or "word"s,
459	according to the rules in section 4, anytime they
460	appear in appropriate places in message headers. It
461	must support both the "B" and "Q" encodings for any
462	character set which it supports. The program must be
463	able to display the unencoded text if the character set
464	is "US-ASCII". For the ISO-8859-* character sets, the
465	mail reading program must at least be able to display
466	the characters which are also in the US-ASCII set.
467	</p>
468	<table border=0 cellpadding=4>
469	<tr valign=top>
470	<td><strong><img src="monicon.png" alt="MHonArc"></strong></td>
471	<td><p>MHonArc supports non-ASCII encoding of text in message headers,
472	including the "B" and "Q" encodings. By default, US-ASCII,
473	ISO-8859-[1-10], and ISO-2022-JP are supported. For encoded
474	words with an unrecognized character set, the word is left in
475	encoded form. Additional character set support can be added via the
476	<a href="resources/charsetconverters.html">CHARSETCONVERTERS</a> resource.
477	</p>
478	<br>
479	</td>
480	</tr>
481	</table>
482	</ol>
483
484
485	<hr>
486	<H2><a name="otherstuff">Other Stuff Supported</a></H2>
487
488	<p>The following lists other MIME-related features supported
489	by MHonArc:</p>
490
491	<ul>
492
493	<li><p>Support for uuencoding as a Content-Transfer-Encoding.
494	</p>
495	</li>
496
497	<li><p>Support for many media-types (including the ability to extend
498	that support). For a complete list, along with more
499	information, see the
500	<a href="resources/mimefilters.html">MIMEFILTERS</a> resource.
501	Note, many media-types cannot be directly converted into HTML. For
502	these types, they are saved to a separate file with a link to the
503	file inserted in the converted HTML message data.
504	</p>
505	</li>
506
507	<li><p>Support for <b><tt>multipart/related</tt></b> by allowing
508	<a href="resources/mimefilters.html">filters</a> to access other
509	message parts via content-ids.
510	</p>
511	</li>
512
513	<li><p>Support for <b><tt>cid:</tt></b> URLs in <b><tt>text/html</tt></b>
514	data. The provides support for things like MHTML:
515	<em>MIME E-mail Encapsulation of Aggregate Documents</em>,
516	<a href="http://www.ietf.org/rfc/rfc2110.txt">RFC 2110</a>.
517	</p>
518	</li>
519
520	<li><p>Support for
521	<a href="http://www.ietf.org/rfc/rfc2369.txt">RFC 2369</a>,
522	<em>The Use of URLs as Meta-Syntax for Core Mail List Commands
523	and their Transport through Message Header Fields</em>. The
524	URLs in list header fields will be converted into hypertext links.
525	</p>
526	</li>
527
528	</ul>
529
530	<hr>
531	<!--X-NavButtons-Start-->
532	<table width="100%">
533	<tr valign="top">
534	<td align="left"><nobr><a href="app-api.html"><img src="prev.png"border=0 alt="[Prev]"></a>   </nobr></td><td align="center" width="99%"><a href="mhonarc.html"><img src="up.png" border=0 alt="[TOC]"></a><a href="faq/faq.html"><img src="faq.png" border=0 alt="[FAQ]"></a><a href="app-bugs.html"><img src="bug.png" border=0 alt="[Bugs]"></a><a href="http://www.mhonarc.org/"><img src="home.png" border=0 alt="[Home]"></a></td><td align="right"><nobr>   <a href="app-bugs.html"><img src="next.png" border=0 alt="[Next]"></a></nobr></td></tr></table>
535	<!--X-NavButtons-End-->
536
537	<HR>
538	<address>
539	$Date: 2001/12/24 14:38:07 $ <br>
540	<img align="top" src="monicon.png" alt="">
541	<a href="http://www.mhonarc.org/"><strong>MHonArc</strong></a><br>
542	Copyright © 1999, <a href="http://www.mhonarc.org/~ehood/"
543	>Earl Hood</a>, <a href="mailto:mhonarc@mhonarc.org"
544	>mhonarc@mhonarc.org</a><br>
545	</address>
546
547	</BODY>
548	</HTML>