| 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> |