doc/tm-en.sgml

   1 <!doctype sinfo system>
   2 <!-- $Id: tm-en.sgml,v 1.2 1996/12/23 21:17:11 morioka Exp $ -->
   3 <head>
   4 <title>tm 7.98 Manual (English Version)
   5 <author>MORIOKA Tomohiko <mail>morioka@jaist.ac.jp</mail>
   6 <date>1996/12/24
   7
   8 <toc>
   9 </head>
  10
  11 <body>
  12
  13 <abstract>
  14 <p>
  15 This file documents tm, a MIME package for GNU Emacs.
  16 </abstract>
  17
  18 <h1> What is tm?
  19 <node> Introduction
  20 <p>
  21 The tm package is a set of modules to enjoy MIME on GNU Emacs.  Using
  22 tm, you can
  23 <p>
  24 <ul>
  25 <li> playback or view the MIME messages using tm-view
  26 <li> compose MIME message using tm-edit
  27 <li> use the enhanced MIME features with mh-e, GNUS, Gnus, RMAIL and VM
  28 </ul>
  29
  30 <noindent>
  31 and more.
  32 <p>
  33 Please read following about each topics:
  34
  35 <ul>
  36 <li><a file="gnus-mime-en">tm-MUA for Gnus</a>
  37 <li><a file="tm-gnus-en">tm-MUA for GNUS</a>
  38 <li><a file="tm-mh-e-en">tm-MUA for mh-e</a>
  39 <li><a file="tm-view-en">mime/viewer-mode</a>
  40 <li><a file="tm-edit-en">mime/editor-mode</a>
  41 </ul>
  42
  43
  44 <h2> Glossary
  45 <node> Glossary
  46
  47 <h3> 7bit
  48 <node> 7bit
  49 <p>
  50 <concept>7bit</concept> means any integer between 0 .. 127.
  51 <p>
  52 Any data represented by 7bit integers is called <concept>7bit
  53 data</concept>.
  54 <p>
  55 Textual string consisted of Control characters between 0 .. 31 and
  56 127, and space represented by 32, and graphic characters between 33
  57 .. 236 are called <concept>7bit (textual) string</concept>.
  58 <p>
  59 Traditional Internet <a node="MTA">MTA</a> can translate 7bit data, so
  60 it is no need to translate by <a
  61 node="Quoted-Printable">Quoted-Printable</a> or <a
  62 node="Base64">Base64</a> for 7bit data.
  63 <p>
  64 However if there are too long lines, it can not translate by 7bit MTA
  65 even if it is 7bit data.  <dref>RFC 821</dref> and <dref>RFC
  66 2045</dref> require lines in 7bit data must be less than 998 bytes.
  67 So if a ``7bit data'' has a line more than 999 bytes, it is regarded
  68 as <dref>binary</dref>.  For example, Postscript file should be
  69 encoded by Quoted-Printable.
  70
  71
  72 <h3> 8bit
  73 <node> 8bit
  74 <p>
  75 <concept>8bit</concept> means any integer between 0 .. 255.
  76 <p>
  77 Any data represented by 8bit integers is called <concept>8bit
  78 data</concept>.
  79 <p>
  80 Textual string consisted of Control characters between 0 .. 31, 127,
  81 and 128 .. 159, and space represented by 32, and graphic characters
  82 between 33 .. 236 and 160 .. 255 are called <concept>8bit (textual)
  83 string</concept>.
  84 <p>
  85 For example, <dref>iso-8859-1</dref> or <dref>euc-kr</dref> are
  86 coded-character-set represented by 8bit textual string.
  87 <p>
  88 Traditional Internet <a node="MTA">MTA</a> can translate only
  89 <dref>7bit</dref> data, so if a 8bit data will be translated such MTA,
  90 it must be encoded by <dref>Quoted-Printable</dref> or
  91 <dref>Base64</dref>.
  92 <p>
  93 However 8bit MTA are increasing today.
  94 <p>
  95 However if there are too long lines, it can not translate by 8bit MTA
  96 even if it is 8bit data.  <dref>RFC 2045</dref> require lines in 8bit
  97 data must be less than 998 bytes.  So if a ``8bit data'' has a line
  98 more than 999 bytes, it is regarded as <dref>binary</dref>, so it must
  99 be encoded by Base64 or Quoted-Printable.
 100
 101
 102 <h3> 94-character set
 103 <node> 94-character set
 104 <p>
 105 <concept>94-character set</concept> is a kind of 1 byte <dref>graphic
 106 character set</dref>, each characters are in positions 02/01 (33) to
 107 07/14 (126) or 10/01 (161) to 15/14 (254).  (ex. <dref>ASCII</dref>,
 108 JIS X0201-Latin)
 109
 110
 111 <h3> 96-character set
 112 <node> 96-character set
 113 <p>
 114 <concept>96-character set</concept> is a kind of 1 byte <dref>graphic
 115 character set</dref>, each characters are in positions 02/00 (32) to
 116 07/15 (126) or 10/00 (160) to 15/15 (255). (ex. ISO 8859)
 117
 118
 119 <h3> 94x94-character set
 120 <node> 94x94-character set
 121 <p>
 122 <concept>94x94-character set</concept> is a kind of 2 byte
 123 <dref>graphic character set</dref>, each bytes are in positions 02/01
 124 (33) to 07/14 (126) or 10/01 (161) to 15/14 (254).  (ex. <dref>JIS
 125 X0208</dref>, <dref>GB 2312</dref>)
 126
 127
 128 <h3> ASCII
 129 <node> ASCII
 130 <p>
 131 <concept>ASCII</concept> is a <dref>94-character set</dref> contains
 132 primary latin characters (A-Z, a-z), numbers and some characters.  It
 133 is a standard of the United States of America.  It is a variant of <a
 134 node="ISO 646">ISO 646</a>.
 135
 136 <standard abbrev="ASCII" title-en="Coded Character Set -- 7-Bit
 137               American Standard Code for Information Interchange"
 138               number="ANSI X3.4" year="1986">
 139
 140
 141 <h3> Base64
 142 <node> Base64
 143 <p>
 144 <concept>Base64</concept> is a transfer encoding method of
 145 <dref>MIME</dref> defined in <dref>RFC 2045</dref>.
 146 <p>
 147 The encoding process represents 24-bit groups of input bits as output
 148 strings of 4 encoded characters.  Encoded characters represent integer
 149 0 .. 63 or <concept>pad</concept>.  Base64 data must be 4 * n bytes,
 150 so pad is used to adjust size.
 151 <p>
 152 These 65 characters are subset of all versions of ISO 646, including
 153 US-ASCII, and all versions of EBCDIC.  So it is safe even if it is
 154 translated by non-Internet gateways.
 155
 156
 157 <h3> binary
 158 <node> binary
 159 <p>
 160 Any byte stream is called <concept>binary</concept>.
 161 <p>
 162 It does not require structureof lines.  It differs from from <a
 163 node="8bit">8bit</a>.
 164 <p>
 165 In addition, if line structured data contain too long line (more than
 166 998 bytes), it is regarded as binary.
 167
 168
 169 <h3> cn-gb, gb2312
 170 <node> cn-gb
 171 <p>
 172 A <a node="MIME charset">MIME charset</a> for simplified Chinese
 173 mainly used in the Chinese mainland.
 174 <p>
 175 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
 176 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 177 <dref>GB 2312</dref>.
 178 <p>
 179 It is defined in <a node="RFC 1922">RFC 1922</a>.
 180
 181
 182 <h3> cn-big5, big5
 183 <node> cn-big5
 184 <p>
 185 A <a node="MIME charset">MIME charset</a> for traditional Chinese
 186 mainly used in Taiwan and Hon Kong.
 187 <p>
 188 It is a <dref>8bit</dref> <dref>coded character set</dref> not based
 189 on <dref>ISO 2022</dref>.  It is a de-fact standard.
 190 <p>
 191 It is defined in <a node="RFC 1922">RFC 1922</a>.
 192 <p>
 193 cf. <report abbrev="BIG5" author="Institute for Information Industry"
 194               title-en="Chinese Coded Character Set in Computer"
 195               date="March 1984">
 196 <p>
 197 It corresponds to <dref>CNS 11643</dref>.
 198
 199
 200 <h3> CNS 11643-1992
 201 <node> CNS 11643
 202 <p>
 203 <dref>Graphic character set</dref>s for Chinese mainly written by
 204 traditional Chinese mainly used in Taiwan and Hong Kong.  It is a
 205 standard of Taiwan.  Currently there are seven <dref>94x94
 206 character set</dref>.
 207 <p>
 208 Final byte of <dref>ISO 2022</dref> are following:
 209
 210 <dl>
 211 <dt>plane 1<dd>04/07 (`G')
 212 <dt>plane 2<dd>04/08 (`H')
 213 <dt>plane 3<dd>04/09 (`I')
 214 <dt>plane 4<dd>04/10 (`J')
 215 <dt>plane 5<dd>04/11 (`K')
 216 <dt>plane 6<dd>04/12 (`L')
 217 <dt>plane 7<dd>04/13 (`M')
 218 </dl>
 219
 220 <standard abbrev="CNS 11643-1992" title-en="Standard Interchange Code
 221               for Generally-Used Chinese Characters" number="CNS
 222               11643" year="1992">
 223
 224
 225 <h3> Coded character set, Character code
 226 <node> coded character set
 227 <p>
 228 A set of unambiguous rules that establishes a character set and the
 229 one-to-one relationship between the characters of the set and their
 230 bit combinations.
 231
 232
 233 <h3> Code extension
 234 <node> code extension
 235 <p>
 236 The techniques for the encoding of characters that are not included in
 237 the character set of a given code. (ex. <dref>ISO 2022</dref>)
 238
 239
 240 <h3> Content-Disposition field
 241 <node> Content-Disposition
 242 <p>
 243 A field to specify presentation of entity or file name.  It is an
 244 extension for <dref>MIME</dref>.
 245 <p>
 246 <rfc number="1806" type="Experimental" author="E R. Troost and
 247               S. Dorner" title="Communicating Presentation Information
 248               in Internet Messages: The Content-Disposition Header"
 249               date="June 1995">
 250
 251
 252 <h3> Content-Type field
 253 <node> Content-Type field
 254 <p>
 255 Header field to represent information about body, such as <dref>media
 256 type</dref>, <dref>MIME charset</dref>.  It is defined in <dref>RFC
 257 2045</dref>.
 258
 259 <memo>
 260 <p>
 261 Historically, Content-Type field was proposed in RFC 1049.  In it,
 262 Content-Type did not distinguish type and subtype.  However MIME
 263 parser may be able to accept RFC 1049 based Content-Type as unknown
 264 type.
 265 </memo>
 266
 267 <p>
 268 Content-Type field is defined as following:
 269
 270 <quote>
 271 ``Content-Type'' ``:'' <concept>type</concept> ``/''
 272 <concept>subtype</concept> *( ``;'' <concept>parameter</concept> )
 273 </quote>
 274
 275 <p>
 276 For example:
 277
 278 <quote>
 279 <verb>
 280 Content-Type: image/jpeg
 281 </verb>
 282 </quote>
 283
 284 <quote>
 285 <verb>
 286 Content-Type: text/plain; charset=iso-2022-jp
 287 </verb>
 288 </quote>
 289
 290 <memo>
 291 <p>
 292 A part does not have content-type field is regarded as
 293
 294 <quote>
 295 <verb>
 296 Content-Type: text/plain; charset=us-ascii
 297 </verb>
 298 </quote>
 299
 300 <noindent>
 301 <cf node="us-ascii">
 302
 303 And a part has unknown type/subtype is regarded as
 304
 305 <quote>
 306 <verb>
 307 Content-Type: application/octet-stream
 308 </verb>
 309 </quote>
 310
 311 </memo>
 312
 313
 314 <h3> Emacs
 315 <node> Emacs
 316 <p>
 317 In this document, `Emacs' means GNU Emacs released by FSF, and `emacs'
 318 means any variants of GNU Emacs.
 319
 320
 321 <h3> encoded-word
 322 <node> encoded-word
 323 <p>
 324 Representation non <dref>ASCII</dref> characters in header.  It
 325 is defined in <concept>RFC 2047</concept>.
 326 <p>
 327 <rfc number="2047" type="Standards Track" author="K. Moore"
 328               title="MIME (Multipurpose Internet Mail Extensions) Part
 329               Three: Message Header Extensions for Non-ASCII Text"
 330               date="November 1996" obsolete="1521,1522,1590">
 331
 332
 333 <h3> encapsulation
 334 <node> encapsulation
 335 <p>
 336 Method to insert whole <a node="RFC 822">Internet message</a> into
 337 another Internet message.
 338 <p>
 339 For example, it is used to forward a message.
 340 <p>
 341 <cf node="message/rfc822">
 342
 343
 344 <h3> euc-kr
 345 <node> euc-kr
 346 <p>
 347 A <dref>MIME charset</dref> for Korean.
 348 <p>
 349 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
 350 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 351 <dref>KS C5601</dref>.
 352 <p>
 353 It is defined in <dref>RFC 1557</dref>.
 354 <p>
 355 cf. <standard abbrev="euc-kr" org="Korea Industrial Standards
 356               Association" title-en="Hangul Unix Environment"
 357               number="KS C 5861" year="1992">
 358
 359
 360 <h3> FTP <node> FTP
 361 <p>
 362 <rfc name="FTP" number="959" type="STD 9" author="Postel, J. and
 363               J. Reynolds" title="File Transfer Protocol"
 364               date="October 1985">
 365
 366
 367 <h3> GB 2312-1980
 368 <node> GB 2312
 369 <p>
 370 A <dref>94x94 character set</dref> for Chinese mainly written by
 371 simplified Chinese mainly used in the Chinese mainland.  It is a
 372 standard of China.
 373 <p>
 374 Final byte of <dref>ISO 2022</dref> is 04/01 (`A').
 375
 376 <standard abbrev="GB 2312"
 377               title-en="Code of Chinese Graphic Character Set for
 378               Information Interchange - Primary Set" number="GB 2312"
 379               year="1980">
 380
 381
 382 <h3> GB 8565.2-1988
 383 <node> GB 8565.2
 384 <p>
 385 A <dref>94x94 character set</dref> for Chinese as supplement to
 386 <dref>GB 2312</dref>.  It is a standard of China.
 387
 388 <standard abbrev="GB 8565.2" title-en="Information Processing - Coded
 389               Character Sets for Text Communication - Part 2: Graphic
 390               Characters used with Primary Set" number="GB 8565.2"
 391               year="1988">
 392
 393
 394 <h3> Graphic Character Set
 395 <node> graphic character set
 396 <p>
 397 <dref>Coded character set</dref> for graphic characters.
 398
 399
 400 <h3> hz-gb2312
 401 <node> hz-gb2312
 402 <p>
 403 A <a node="MIME charset">MIME charset</a> for simplified Chinese
 404 mainly used in the Chinese mainland.
 405 <p>
 406 It extends <dref>ASCII</dref> to combine <dref>GB 2312</dref>, its
 407 technique is like <dref>iso-2022-jp</dref>, but it is designed to be
 408 ASCII printable to use special form for ESC sequence to designate GB
 409 2312 to G0.
 410 <p>
 411 It is defined in RFC 1842 and 1843.
 412
 413 <rfc number="1842" type="Informational" author="Y. Wei, Y. Zhang,
 414               J. Li, J. Ding and Y. Jiang" title="ASCII Printable
 415               Characters-Based Chinese Character Encoding for Internet
 416               Messages" date="August 1995">
 417 <rfc number="1843" type="Informational" author="F. Lee" title="HZ - A
 418               Data Format for Exchanging Files of Arbitrarily Mixed
 419               Chinese and ASCII characters" date="August 1995">
 420
 421
 422 <h3> ISO 2022
 423 <node> ISO 2022
 424 <p>
 425 It is a standard for character code structure and <dref>code
 426 extension</dref> technique.
 427
 428 <standard abbrev="ISO 2022" org="International Organization for
 429               Standardization (ISO)" title-en="Information Processing:
 430               ISO 7-bit and 8-bit coded character sets: Code extension
 431               techniques" number="ISO/IEC 2022" year="1994">
 432
 433
 434 <h3> iso-2022-cn
 435 <node> iso-2022-cn
 436 <p>
 437 A <dref>MIME charset</dref> for Chinese.
 438 <p>
 439 It is a <dref>7bit</dref> <dref>coded character set</dref> based on
 440 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 441 <dref>GB 2312</dref> and/or <a node="CNS 11643">CNS 11643 plain 1,
 442 plain 2</a>.
 443 <p>
 444 It is defined in <dref>RFC 1922</dref>.
 445
 446
 447 <h3> iso-2022-cn-ext
 448 <node> iso-2022-cn-ext
 449 <p>
 450 A <dref>MIME charset</dref> for Chinese.
 451 <p>
 452 It is a <dref>7bit</dref> <dref>coded character set</dref> based on
 453 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 454 <dref>GB 2312</dref>, <a node="CNS 11643">CNS 11643 plain 1 .. 7</a>,
 455 <dref>ISO-IR-165</dref> and other Chinese graphic character sets.
 456 <p>
 457 It is defined in <dref>RFC 1922</dref>.
 458 <p>
 459 <memo>
 460 MULE 2.3 and current XEmacs/mule can not use it correctly.
 461 <p>
 462 Emacs/mule can use it.
 463 </memo>
 464
 465
 466 <h3> iso-2022-jp
 467 <node> iso-2022-jp
 468 <p>
 469 A <dref>MIME charset</dref> for Japanese.
 470 <p>
 471 It is a <dref>7bit</dref> <dref>coded character set</dref> based on
 472 old <dref>ISO 2022</dref>.  It switches <dref>ASCII</dref>, JIS
 473 X0201-Latin, <a node="JIS C6226-1978">JIS X0208-1978</a> and <a
 474 node="JIS X0208">JIS X0208-1983</a>.
 475 <p>
 476 It is defined in RFC 1468.
 477 <p>
 478 <memo>
 479 JIS X0208-1997? will define it in annex as non-<dref>ISO 2022</dref>
 480 encoding.
 481 </memo>
 482
 483 <rfc name="iso-2022-jp" number="1468" author="Murai J., M. Crispin,
 484               and E. van der Poel" title="Japanese Character Encoding
 485               for Internet Messages" date="June 1993">
 486
 487
 488 <h3> iso-2022-jp-2
 489 <node> iso-2022-jp-2
 490 <p>
 491 A <dref>MIME charset</dref>, which is a multilingual extension of
 492 <dref>iso-2022-jp</dref>.
 493 <p>
 494 It is defined in RFC 1554.
 495
 496 <rfc name="iso-2022-jp-2" number="1554" type="Informational"
 497               author="Ohta M. and Handa K." title="ISO-2022-JP-2:
 498               Multilingual Extension of ISO-2022-JP" date="December
 499               1993">
 500
 501
 502 <h3> iso-2022-kr
 503 <node> iso-2022-kr
 504 <p>
 505 A <a node="MIME charset">MIME charset</a> for Korean language (Hangul
 506 script).
 507 <p>
 508 It is based on <dref>ISO 2022</dref> <dref>code extension</dref>
 509 technique to extend <dref>ASCII</dref> to use <dref>KS C5601</dref> as
 510 <dref>7bit</dref> text.
 511 <p>
 512 It is defined in <dref>RFC 1557</dref>.
 513
 514
 515 <h3> ISO 646
 516 <node> ISO 646
 517 <p>
 518 <standard abbrev="ISO 646" org="International Organization for
 519               Standardization (ISO)" title-en="Information technology:
 520               ISO 7-bit coded character set for information
 521               interchange" number="ISO/IEC 646" year="1991">
 522
 523
 524 <h3> ISO 8859-1
 525 <node> ISO 8859-1
 526 <p>
 527 <standard abbrev="ISO 8859-1" org="International Organization for
 528               Standardization (ISO)" title-en="Information Processing
 529               -- 8-bit Single-Byte Coded Graphic Character Sets --
 530               Part 1: Latin Alphabet No.1" number="ISO 8859-1"
 531               year="1987">
 532
 533
 534 <h3> iso-8859-1
 535 <node> iso-8859-1
 536 <p>
 537 <concept>iso-8859-1</concept> is a <dref>MIME charset</dref> for
 538 west-European languages written by Latin script.
 539 <p>
 540 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
 541 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 542 <dref>ISO 8859-1</dref>.
 543 <p>
 544 It is defined in <dref>RFC 2046</dref>.
 545
 546
 547 <h3> ISO 8859-2
 548 <node> ISO 8859-2
 549 <p>
 550 <standard abbrev="ISO 8859-2" org="International Organization for
 551               Standardization (ISO)" title-en="Information Processing
 552               -- 8-bit Single-Byte Coded Graphic Character Sets --
 553               Part 2: Latin alphabet No.2" number="ISO 8859-2"
 554               year="1987">
 555
 556
 557 <h3> iso-8859-2
 558 <node> iso-8859-2
 559 <p>
 560 <concept>iso-8859-2</concept> is a <dref>MIME charset</dref> for
 561 east-European languages written by Latin script.
 562 <p>
 563 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
 564 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 565 <dref>ISO 8859-2</dref>.
 566 <p>
 567 It is defined in <dref>RFC 2046</dref>.
 568
 569
 570 <h3> ISO 8859-3
 571 <node> ISO 8859-3
 572 <p>
 573 <standard abbrev="ISO 8859-3" org="International Organization for
 574                 Standardization (ISO)" title-en="Information
 575                 Processing -- 8-bit Single-Byte Coded Graphic
 576                 Character Sets -- Part 3: Latin alphabet No.3"
 577                 number="ISO 8859-3" year="1988">
 578
 579
 580 <h3> ISO 8859-4
 581 <node> ISO 8859-4
 582 <p>
 583 <standard abbrev="ISO 8859-4" org="International Organization for
 584                 Standardization (ISO)" title-en="Information
 585                 Processing -- 8-bit Single-Byte Coded Graphic
 586                 Character Sets -- Part 4: Latin alphabet No.4"
 587                 number="ISO 8859-4" year="1988">
 588
 589
 590 <h3> ISO 8859-5
 591 <node> ISO 8859-5
 592 <p>
 593 <standard abbrev="ISO 8859-5" org="International Organization for
 594               Standardization (ISO)" title-en="Information Processing
 595               -- 8-bit Single-Byte Coded Graphic Character Sets --
 596               Part 5: Latin/Cyrillic alphabet" number="ISO 8859-5"
 597               year="1988">
 598
 599
 600 <h3> iso-8859-5
 601 <node> iso-8859-5
 602 <p>
 603 <concept>iso-8859-5</concept> is a <dref>MIME charset</dref> for
 604 Cyrillic script.
 605 <p>
 606 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
 607 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 608 <dref>ISO 8859-5</dref>.
 609 <p>
 610 It is defined in <dref>RFC 2046</dref>.
 611
 612
 613 <h3> ISO 8859-6
 614 <node> ISO 8859-6
 615 <p>
 616 <standard abbrev="ISO 8859-6" org="International Organization for
 617                 Standardization (ISO)" title-en="Information
 618                 Processing -- 8-bit Single-Byte Coded Graphic
 619                 Character Sets -- Part 6: Latin/Arabic alphabet"
 620                 number="ISO 8859-6" year="1987">
 621
 622
 623 <h3> ISO 8859-7
 624 <node> ISO 8859-7
 625 <p>
 626 <standard abbrev="ISO 8859-7" org="International Organization for
 627               Standardization (ISO)" title-en="Information Processing
 628               -- 8-bit Single-Byte Coded Graphic Character Sets --
 629               Part 7: Latin/Greek alphabet" number="ISO 8859-7"
 630               year="1987">
 631
 632
 633 <h3> iso-8859-7
 634 <node> iso-8859-7
 635 <p>
 636 <concept>iso-8859-7</concept> is a <dref>MIME charset</dref> for
 637 Greek script.
 638 <p>
 639 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
 640 <dref>ISO 2022</dref>.  It extends <dref>ASCII</dref> to combine
 641 <dref>ISO 8859-7</dref>.
 642 <p>
 643 It is defined in RFC 1947.
 644
 645 <rfc name="iso-8859-7" number="1947" type="Informational"
 646               author="D. Spinellis" title="Greek Character Encoding
 647               for Electronic Mail Messages" date="May 1996">
 648
 649
 650 <h3> ISO 8859-8
 651 <node> ISO 8859-8
 652 <p>
 653 <standard abbrev="ISO 8859-8" org="International Organization for
 654                 Standardization (ISO)" title-en="Information
 655                 Processing -- 8-bit Single-Byte Coded Graphic
 656                 Character Sets -- Part 8: Latin/Hebrew alphabet"
 657                 number="ISO 8859-8" year="1988">
 658
 659
 660 <h3> ISO 8859-9
 661 <node> ISO 8859-9
 662 <p>
 663 <standard abbrev="ISO 8859-9" org="International Organization for
 664                 Standardization (ISO)" title-en="Information
 665                 Processing -- 8-bit Single-Byte Coded Graphic
 666                 Character Sets -- Part 9: Latin alphabet No.5"
 667                 number="ISO 8859-9" year="1990">
 668
 669
 670 <h3> ISO-IR-165, CCITT Extended GB <node> ISO-IR-165
 671 <p>
 672 A <dref>94x94-character set</dref> for Chinese mainly written by
 673 simplified Chinese mainly used in the Chinese mainland registered by
 674 CCITT.
 675 <p>
 676 It consists of <dref>GB 2312</dref>, <dref>GB 8865.2</dref> and
 677 additional 150 characters.
 678 <p>
 679 Final byte of <dref>ISO 2022</dref> is 04/05 (`E').
 680
 681
 682 <h3> JIS X0201
 683 <node> JIS X0201
 684 <p>
 685 It defines two <dref>94-character set</dref>, for Latin script (a
 686 variant of <dref>ISO 646</dref>) and Katakana script, and 7bit and
 687 8bit <dref>coded character set</dref>s.
 688 <p>
 689 It was renamed from <concept>JIS C6220-1976</concept>.
 690
 691 <standard abbrev="JIS X0201-1976" org="Japanese Standards Association"
 692               title-en="Code for Information Interchange" number="JIS
 693               X 0201-1976">
 694
 695 In addition, revised version will be published in 1997.
 696
 697 <standard abbrev="JIS X0201-1997?" org="Japanese Standards
 698               Association" title-en="7-bit and 8-bit coded character
 699               sets for information interchange" number="JIS X 0201"
 700               year="1997?  draft">
 701
 702
 703 <h3> JIS C6226-1978
 704 <node> JIS C6226
 705 <p>
 706 A <dref>94x94-character set</dref> for Japanese.  It was renamed to
 707 JIS X0208-1978.
 708 <p>
 709 <cf node="JIS X0208">
 710
 711
 712 <h3> JIS X0208
 713 <node> JIS X0208
 714 <p>
 715 A <dref>94x94-character set</dref> for Japanese.  Japanese standard.
 716 It was published in 1978, and revised in 1983 and 1990.  In the
 717 Internet message, 1983 edition is major.
 718 <p>
 719 JIS X0208 contains some symbols, numbers, primary Latin script,
 720 Hiragana script, Katakana script, Greek script, Cyrillic script, box
 721 drawing parts, Kanji (Ideographic characters used in Japanese).
 722 Notice that some symbols and box drawing parts were added in 1983 and
 723 some Kanjis were changed or swapped code points.  So 1978 edition and
 724 1983 edition are regarded as different graphic character set.
 725 <p>
 726 1990 edition added some characters, so designation of 1990 edition
 727 requires `identify revised registration' sequence, ESC 02/06 4/0 as
 728 prefix of designation sequence.
 729
 730 <standard abbrev="JIS X0208-1978" org="Japanese Standards Association"
 731               title-en="Code of the Japanese graphic character set for
 732               information interchange" number="JIS C6226" year="1978">
 733 <standard abbrev="JIS X0208-1983,1990" org="Japanese Standards
 734               Association" title-en="Code of the Japanese graphic
 735               character set for information interchange" number="JIS
 736               X0208" year="1983,1990">
 737
 738 <p>
 739 In addition, revised version will be published in 1997. (It does not
 740 change graphic character set)
 741
 742 <standard abbrev="JIS X0208-1997?" org="Japanese Standards
 743               Association" title-en="7-bit and 8-bit double byte coded
 744               Kanji sets for information interchange" number="JIS X
 745               0208" year="1997? draft">
 746
 747
 748 <h3> JIS X0212-1990
 749 <node> JIS X0212
 750 <p>
 751 A <dref>94x94 character set</dref> for Japanese as supplement to
 752 <dref>JIS X0208</dref>.  It is a standard of Japan.
 753 <p>
 754 Final byte of <dref>ISO 2022</dref> is 04/04 (`D').
 755
 756
 757 <h3> koi8-r
 758 <node> koi8-r
 759 <p>
 760 A <dref>MIME charset</dref> for Cyrillic script for Russian or other
 761 languages.
 762 <p>
 763 It is a 1 byte <dref>8bit</dref> <dref>coded character set</dref>, not
 764 based on <dref>ISO 2022</dref>.  It is a de-fact standard.
 765 <p>
 766 It is defined in RFC 1489.
 767 <p>
 768 <rfc number="1489" author="A. Chernov" title="Registration of a
 769               Cyrillic Character Set" date="July 1993">
 770
 771
 772 <h3> KS C5601-1987
 773 <node> KS C5601
 774 <p>
 775 A <dref>94x94-character set</dref> for Korean language (Hangul
 776 script).  Korean Standard.  Final byte of <dref>ISO 2022</dref> is
 777 04/03 (`C').
 778
 779 <standard abbrev="KS C5601" org="Korea Industrial Standards
 780               Association" title-en="Code for Information Interchange
 781               (Hangul and Hanja)" number="KS C 5601" year="1987">
 782
 783
 784 <h3> media type
 785 <node> media type
 786 <p>
 787 <concept>media type</concept> specifies the nature of the data in the
 788 body of <dref>MIME</dref> <dref>entity</dref>.  It consists of
 789 <concept>type</concept> and <concept>subtype</concept>.  It is defined
 790 in <dref>RFC 2046</dref>.
 791 <p>
 792 Currently there are following types:
 793
 794 <ul>
 795 <li><concept>text</concept>
 796 </li>
 797 <li><concept>image</concept>
 798 </li>
 799 <li><concept>audio</concept>
 800 </li>
 801 <li><concept>video</concept>
 802 </li>
 803 <li><concept>application</concept>
 804 </li>
 805 <li><a node="multipart"><concept>multipart</concept></a>
 806 </li>
 807 <li><concept>message</concept>
 808 </ul>
 809
 810 <p>
 811 And there are various subtypes, for example, application/octet-stream,
 812 audio/basic, image/jpeg, <dref>multipart/mixed</dref>,
 813 <dref>text/plain</dref>, video/mpeg...
 814 <p>
 815 You can refer registered media types at <a
 816 href="ftp://ftp.isi.edu/in-notes/iana/assignments/media-types">MEDIA
 817 TYPES</a>.
 818 <p>
 819 In addition, you can use private type or subtype using
 820 <concept>x-token</concept>, which as the prefix `x-'.  However you can
 821 not use them in public.
 822 <p>
 823 <cf node="Content-Type field">
 824
 825
 826 <h3> message
 827 <node> message
 828 <p>
 829 In this document, it means mail defined in <dref>RFC 822</dref> and
 830 news message defined in <dref>RFC 1036</dref>.
 831
 832
 833 <h3> message/rfc822
 834 <node> message/rfc822
 835 <p>
 836 <concept>message/rfc822</concept> indicates that the body contains an
 837 encapsulated message, with the syntax of an <dref>RFC 822</dref>
 838 message.  It is the replacement of traditional <dref>RFC 934</dref>
 839 encapsulation.  It is defined in <dref>RFC 2046</dref>.
 840
 841
 842 <h3> method
 843 <node> method
 844 <p>
 845 Application program of tm-view to process for specified <dref>media
 846 type</dref> when user plays an entity.
 847 <p>
 848 There are two kinds of methods, <concept>internal method</concept> and
 849 <concept>external method</concept>.  Internal method is written by
 850 Emacs Lisp.  External method is written by C or script languages and
 851 called by asynchronous process call.
 852 <p>
 853 <cf file="tm-view-en" node="method">
 854
 855
 856 <h3> MIME
 857 <node> MIME
 858 <p>
 859 MIME stands for <concept>Multipurpose Internet Mail
 860 Extensions</concept>, it is an extension for <dref>RFC 822</dref>.
 861 <p>
 862 According to RFC 2045:
 863 <p>
 864 STD 11, RFC 822, defines a message representation protocol specifying
 865 considerable detail about US-ASCII message headers, and leaves the
 866 message content, or message body, as flat US-ASCII text.  This set of
 867 documents, collectively called the Multipurpose Internet Mail
 868 Extensions, or MIME, redefines the format of messages to allow for
 869 <p>
 870 <ol>
 871 <li>textual message bodies in character sets other than US-ASCII,
 872 </li>
 873 <li>an extensible set of different formats for non-textual message
 874 bodies,
 875 </li>
 876 <li>multi-part message bodies, and
 877 </li>
 878 <li>textual header information in character sets other than US-ASCII.
 879 </ol>
 880
 881 <p>
 882 It is defined in <dref>RFC 2045</dref>, <dref>RFC 2046</dref>, <a
 883 node="encoded-word">RFC 2047</a>, <dref>RFC 2048</dref> and <dref>RFC
 884 2049</dref>.
 885
 886
 887 <h3> MIME charset
 888 <node> MIME charset
 889 <p>
 890 <dref>Coded character set</dref> used in <dref>Content-Type
 891 field</dref> or charset parameter of <a
 892 node="encoded-word">encoded-word</a>.
 893 <p>
 894 It is defined in <dref>RFC 2045</dref>.
 895 <p>
 896 <dref>iso-2022-jp</dref> or <dref>euc-kr</dref> are kinds of it.  (In
 897 this document, MIME charsets are written by small letters to
 898 distinguish <dref>graphic character set</dref>.  For example, ISO
 899 8859-1 is a graphic character set, and iso-8859-1 is a MIME charset)
 900
 901
 902 <h3> MTA
 903 <node> MTA
 904 <p>
 905 <concept>Message Transfer Agent</concept>.  It means mail transfer
 906 programs (ex. sendmail) and news servers.
 907 <p>
 908 <cf node="MUA">
 909
 910
 911 <h3> MUA
 912 <node> MUA
 913 <p>
 914 <concept>Message User Agent</concept>.  It means mail readers and news
 915 readers.
 916 <p>
 917 <cf node="MTA">
 918
 919
 920 <h3> MULE
 921 <node> MULE
 922 <p>
 923 Multilingual extension of GNU <dref>Emacs</dref> by HANDA Ken'ichi et
 924 al.
 925
 926 <inproc abbrev="MULE" author="Nishikimi M., Handa K. and Tomura S."
 927               title-en="Mule: MULtilingual Enhancement to GNU Emacs"
 928               book-en="Proc. of INET'93" date="August, 1993">
 929 <p>
 930 Now, FSF and HANDA Ken'ichi et al. are working to merge MULE feature
 931 into Emacs, there is <a
 932 href="ftp://etlport.etl.go.jp/pub/mule/mule-19.33-delta.taz">alpha
 933 version of mule merged emacs</a>.
 934 <p>
 935 In addition, there is XEmacs with mule feature.
 936 <p>
 937 So now, there are 3 kinds of mule variants.
 938 <p>
 939 In this document, <concept>mule</concept> means any mule variants,
 940 <concept>MULE</concept> means original MULE (..2.3),
 941 <concept>Emacs/mule</concept> means mule merged Emacs,
 942 <concept>XEmacs/mule</concept> means XEmacs with mule feature.
 943
 944
 945 <h3> Multipart
 946 <node> multipart
 947 <p>
 948 <concept>multipart</concept> means <dref>media type</dref> to insert
 949 multiple <dref>entities</dref> in a single body.  Or it also indicates
 950 a message consists of multiple entities.
 951 <p>
 952 There are following subtypes registered in <dref>RFC 2046</dref>:
 953
 954 <ul>
 955 <li><dref>multipart/mixed</dref>
 956 <li><dref>multipart/alternative</dref>
 957 <li><dref>multipart/digest</dref>
 958 <li><dref>multipart/parallel</dref>
 959 </ul>
 960
 961 <noindent>
 962 and registered in <a node="Security multipart">RFC 1847</a>:
 963
 964 <ul>
 965 <li><dref>multipart/signed</dref>
 966 <li><dref>multipart/encrypted</dref>
 967 </ul>
 968
 969
 970 <h3> multipart/alternative
 971 <node> multipart/alternative
 972 <p>
 973 <concept>multipart/digest</concept> is one of <dref>multipart</dref>
 974 media types.  This type is syntactically identical to
 975 <dref>multipart/mixed</dref>, but the semantics are different.  In
 976 particular, each of the body parts is an ``alternative'' version of
 977 the same information.
 978 <p>
 979 <cf node="RFC 2046">
 980
 981
 982 <h3> multipart/digest
 983 <node> multipart/digest
 984 <p>
 985 <concept>multipart/digest</concept> is one of <dref>multipart</dref>
 986 media types.  This type is syntactically identical to
 987 <dref>multipart/mixed</dref>, but the semantics are different.  In
 988 particular, in a digest, the default Content-Type value for a body
 989 part is changed from <dref>text/plain</dref> to
 990 <dref>message/rfc822</dref>.
 991 <p>
 992 This is the replacement of traditional <dref>RFC 1153</dref> based
 993 <dref>encapsulation</dref>.
 994 <p>
 995 <cf node="RFC 2046">
 996
 997
 998 <h3> multipart/encrypted
 999 <node> multipart/encrypted
1000 <p>
1001 It is a <dref>Security multipart</dref> defined in
1002 RFC 1847, used to represent encrypted message.
1003 <p>
1004 <cf node="PGP/MIME">
1005
1006
1007 <h3> multipart/mixed
1008 <node> multipart/mixed
1009 <p>
1010 Primary and default subtype of <dref>multipart</dref>, it is used when
1011 the body parts are independent and need to be bundled in a particular
1012 order.
1013 <p>
1014 <cf node="RFC 2046">
1015
1016
1017 <h3> multipart/parallel
1018 <node> multipart/parallel
1019 <p>
1020 <concept>multipart/parallel</concept> is a subtype of
1021 <dref>multipart</dref>.  This type is syntactically identical to
1022 <dref>multipart/mixed</dref>, but the semantics are different.  In
1023 particular, in a parallel entity, the order of body parts is not
1024 significant.
1025 <p>
1026 <cf node="RFC 2046">
1027
1028
1029 <h3> multipart/signed
1030 <node> multipart/signed
1031 <p>
1032 It is a <dref>Security multipart</dref> defined in
1033 RFC 1847, used to represent signed message.
1034 <p>
1035 <cf node="PGP/MIME">
1036
1037
1038 <h3> PGP
1039 <node> PGP
1040 <p>
1041 A public key encryption program by Phil Zimmermann.  It provides
1042 encryption and signature for <dref>message</dref>.  PGP stands for
1043 <concept>Pretty Good Privacy</concept>.
1044 <p>
1045 Traditional PGP uses <dref>RFC 934</dref> <dref>encapsulation</dref>.
1046 It is conflict with <dref>MIME</dref>.  So <dref>PGP/MIME</dref> is
1047 defined.  On the other hand, <dref>PGP-kazu</dref> was proposed to use
1048 PGP encapsulation in MIME.  But it is obsoleted.
1049 <p>
1050 <rfc name="PGP" number="1991" type="Informational" author="D. Atkins,
1051               W. Stallings and P. Zimmermann" title="PGP Message
1052               Exchange Formats" date="August 1996">
1053
1054
1055
1056 <h3> PGP-kazu
1057 <node> PGP-kazu
1058 <p>
1059 In this document, <concept>PGP-kazu</concept> means a method to use
1060 traditional PGP encapsulation in <dref>MIME</dref>, proposed by
1061 YAMAMOTO Kazuhiko.
1062 <p>
1063 PGP-kazu defines a <dref>media type</dref>,
1064 <concept>application/pgp</concept>.
1065 <p>
1066 In application/pgp entity, PGP <dref>encapsulation</dref> is used.
1067 PGP encapsulation conflicts with MIME, so it requires PGP-processing
1068 to read as MIME message.
1069 <p>
1070 It was obsoleted, so you should use <dref>PGP/MIME</dref>.  However if
1071 you want to use traditional PGP message, it might be available.
1072
1073
1074 <h3> PGP/MIME
1075 <node> PGP/MIME
1076 <p>
1077 <dref>PGP</dref> and <dref>MIME</dref> integration proposed by Michael
1078 Elkins.
1079 <p>
1080 It is based on <a node="Security multipart">RFC 1847</a>, so it is
1081 harmonious with MIME, but it is not compatible with traditional PGP
1082 encapsulation.  However MIME MUA can read PGP/MIME signed message even
1083 if it does not support PGP/MIME.
1084 <p>
1085 <dref>PGP/MIME</dref> will be standard of PGP message.
1086
1087 <rfc name="PGP/MIME" number="2015" type="Standards Track"
1088               author="M. Elkins" title="MIME Security with Pretty Good
1089               Privacy (PGP)" date="October 1996">
1090
1091
1092 <h3> Quoted-Printable
1093 <node> Quoted-Printable
1094 <p>
1095 <concept>Quoted-Printable</concept> is a transfer encoding method of
1096 <dref>MIME</dref> defined in <dref>RFC 2045</dref>.
1097 <p>
1098 If the data being encoded are mostly US-ASCII text, the encoded form
1099 of the data remains largely recognizable by humans.
1100 <p>
1101 <cf node="Base64">
1102
1103
1104 <h3> RFC 821
1105 <node> RFC 821
1106 <p>
1107 <rfc name="SMTP" number="821" type="STD 10" author="J. Postel"
1108               title="Simple Mail Transfer Protocol" date="August
1109               1982">
1110
1111
1112 <h3> RFC 822
1113 <node> RFC 822
1114 <p>
1115 A RFC defines format of Internet mail message, mainly <concept>message
1116 header</concept>.
1117
1118 <memo>
1119 <p>
1120 news message is based on RFC 822, so <concept>Internet
1121 message</concept> may be more suitable than <concept>Internet
1122 mail</concept> .
1123 </memo>
1124
1125 <rfc number="822" type="STD 11" author="D. Crocker" title="Standard
1126               for the Format of ARPA Internet Text Messages"
1127               date="August 1982">
1128
1129
1130 <h3> RFC 934
1131 <node> RFC 934
1132 <p>
1133 A RFC defines an <a node="encapsulation">
1134 <concept>encapsulation</concept></a> method for <a node="RFC
1135 822">Internet mail</a>.
1136 <p>
1137 It conflicts with <dref>MIME</dref>, so you should use
1138 <dref>message/rfc822</dref>.
1139
1140 <rfc number="934" author="Marshall T. Rose and Einar A. Stefferud"
1141               title="Proposed Standard for Message Encapsulation"
1142               date="January 1985">
1143
1144
1145 <h3> RFC 1036
1146 <node> RFC 1036
1147 <p>
1148 A RFC defines format of USENET message.  It is a subset of <dref>RFC
1149 822</dref>.  It is not Internet standard, but a lot of netnews
1150 excepting Usenet uses it.
1151
1152 <rfc name="USENET" number="1036" author="M. Horton and R. Adams"
1153               title="Standard for Interchange of USENET Messages"
1154               date="December 1987" obsolete="850">
1155
1156
1157 <h3> RFC 1153
1158 <node> RFC 1153
1159 <p>
1160 <rfc number="1153" author="F. Wancho" title="Digest Message Format"
1161               date="April 1990">
1162
1163
1164 <h3> RFC 1557
1165 <node> RFC 1557
1166 <p>
1167 A RFC defines <dref>MIME charset</dref>s for Korean,
1168 <dref>euc-kr</dref> and <dref>iso-2022-kr</dref>.
1169
1170 <rfc number="1557" type="Informational" author="U. Choi, K. Chon and
1171               H. Park" title="Korean Character Encoding for Internet
1172               Messages" date="December 1993">
1173
1174
1175 <h3> RFC 1922
1176 <node> RFC 1922
1177 <p>
1178 A RFC defines <dref>MIME charset</dref>s for Chinese,
1179 <dref>iso-2022-cn</dref>, <dref>iso-2022-cn-ext</dref>,
1180 <dref>cn-gb</dref>, <dref>cn-big5</dref>, etc.
1181 <p>
1182 In addition, it defines additional parameters of <dref>Content-Type
1183 field</dref> field, <concept>charset-edition</concept> and
1184 <concept>charset-extension</concept>.
1185
1186 <rfc number="1922" type="Informational" author="Zhu, HF., Hu, DY.,
1187               Wang, ZG., Kao, TC., Chang, WCH. and Crispin, M."
1188               title="Chinese Character Encoding for Internet Messages"
1189               date="March 1996">
1190
1191
1192 <h3> RFC 2045
1193 <node> RFC 2045
1194 <p>
1195 <rfc number="2045" type="Standards Track" author="N. Freed and
1196               N. Borenstein" title="Multipurpose Internet Mail
1197               Extensions (MIME) Part One: Format of Internet Message
1198               Bodies" date="November 1996" obsolete="1521, 1522,
1199               1590">
1200
1201
1202 <h3> RFC 2046
1203 <node> RFC 2046
1204 <p>
1205 <rfc number="2046" type="Standards Track" author="N. Freed and
1206               N. Borenstein" title="Multipurpose Internet Mail
1207                  Extensions (MIME) Part Two: Media Types"
1208                  date="November 1996" obsolete="1521, 1522, 1590">
1209
1210
1211 <h3> RFC 2048
1212 <node> RFC 2048
1213 <p>
1214 <rfc number="2048" type="Standards Track" author="N. Freed, J. Klensin
1215               and J. Postel" title="Multipurpose Internet Mail
1216               Extensions (MIME) Part Four: Registration Procedures"
1217               date="November 1996" obsolete="1521, 1522, 1590">
1218
1219
1220 <h3> RFC 2049
1221 <node> RFC 2049
1222 <p>
1223 <rfc number="2049" type="Standards Track" author="N. Freed and
1224               N. Borenstein" title="Multipurpose Internet Mail
1225               Extensions (MIME) Part Five: Conformance Criteria and
1226               Examples" date="November 1996" obsolete="1521, 1522,
1227               1590">
1228
1229
1230 <h3> plain text
1231 <node> plain text
1232 <p>
1233 A textual data represented by only <dref>coded character set</dref>.
1234 It does not have information about font or typesetting.
1235 <cf node="text/plain">
1236
1237
1238 <h3> Security multipart
1239 <node> Security multipart
1240 <p>
1241 A format to represent signed/encrypted message in <dref>MIME</dref>.
1242 <p>
1243 It defines two multipart media types, <a
1244 node="multipart/signed"><concept>multipart/signed</concept></a> and <a
1245 node="multipart/encrypted"><concept>multipart/encrypted</concept></a>.
1246 <p>
1247 MOSS and <dref>PGP/MIME</dref> are based on it.
1248
1249 <rfc name="Security multipart" number="1847" type="Standards Track"
1250               author="James Galvin, Gale Murphy, Steve Crocker and Ned
1251               Freed" title="Security Multiparts for MIME:
1252               Multipart/Signed and Multipart/Encrypted" date="October
1253               1995">
1254
1255
1256 <h3> text/enriched
1257 <node> text/enriched
1258 <p>
1259 <rfc name="text/enriched" number="1896" author="P. Resnick and
1260               A. Walker" title="The text/enriched MIME Content-type"
1261               date="February 1996" obsolete="1563">
1262
1263
1264 <h3> text/plain
1265 <node> text/plain
1266 <p>
1267 <concept>text/plain</concept> is a <dref>media type</dref> for
1268 <dref>plain text</dref>, defined in <dref>RFC 2046</dref>.
1269 <p>
1270 The default media type of ``text/plain; charset=us-ascii'' for
1271 Internet mail describes existing Internet practice.  That is, it is
1272 the type of body defined by <dref>RFC 822</dref>.
1273 <p>
1274 <cf node="MIME charset"><cf node="us-ascii">
1275
1276
1277 <h3> tm-kernel, tm
1278 <node> tm-kernel
1279 <p>
1280 A libraries to provide user interface about <dref>MIME</dref> for
1281 emacs.  tm stands for `tools for MIME'.
1282
1283 <memo title="Unimportant notice(^-^;">
1284 <p>
1285 <ul>
1286   <li> tm may not stand for ``tiny-mime''(^-^;
1287   <li> tm may not stand for initial of an author (^-^;
1288   <li> ``Tools for MIME'' may be strained (^-^;
1289 </ul>
1290 </memo>
1291
1292
1293 <h3> tm-MUA
1294 <node> tm-MUA
1295 <p>
1296 <dref>MUA</dref> or MUA extender using <a node="tm-kernel">tm</a>.
1297 <p>
1298 <concept>tm oomori package</concept> has following extenders:
1299
1300 <ul>
1301 <li><a file="tm-mh-e-en"><concept>tm-mh-e</concept></a>
1302  for <a file="mh-e">mh-e</a>
1303 <li><a file="tm-gnus_en"><concept>tm-gnus</concept></a> for GNUS
1304 <li><a file="gnus-mime-en"><concept>gnus-mime</concept></a> for Gnus
1305 <li><a file="tm-vm_en"><concept>tm-vm</concept></a> for VM
1306 <li><concept>tm-rmail</concept> for RMAIL
1307 </ul>
1308
1309
1310 <h3> us-ascii
1311 <node> us-ascii
1312 <p>
1313 A <a node="MIME charset">MIME charset</a> for primary Latin script
1314 mainly written by English or other languages.
1315 <p>
1316 It is a 7bit <dref>coded character set</dref> based on <dref>ISO
1317 2022</dref>, it contains only
1318 <dref>ASCII</dref> and <dref>code extension</dref> is not allowed.
1319 <p>
1320 It is standard coded character set of Internet mail.  If MIME charset
1321 is not specified, <concept>us-ascii</concept> is used as default.
1322 <p>
1323 In addition, <concept>ASCII</concept> of <dref>RFC 822</dref> should
1324 be interpreted as us-ascii.
1325
1326
1327 <h1> Setting
1328 <node> Setting
1329 <p>
1330 In the tm package, two files, <file>mime-setup.el</file> and
1331 <file>tm-setup.el</file>, are provided to ease the setup.
1332 <p>
1333 The <file>mime-setup.el</file> is used for the whole MIME related
1334 setup including MIME encoding using <file>tm-edit.el</file>, while
1335 <file>tm-setup.el</file> is used to set up tm-MUA only.
1336
1337
1338 <h2> Normal setting
1339 <node> mime-setup
1340 <p>
1341 If you want normal setting, please use <concept>mime-setup</concept>.
1342 For example, please insert following into <file>~/.emacs</file>:
1343
1344 <lisp>
1345 (load "mime-setup")
1346 </lisp>
1347
1348 <p>
1349 As <file>mime-setup.el</file> loads <file>tm-setup.el</file>, you
1350 don't need to load <file>tm-setup.el</file> when you use
1351 <file>mime-setup.el</file> (Description of old version of Gnus FAQ is
1352 wrong!)
1353
1354
1355 <h3> signature
1356 <node> signature
1357 <p>
1358 You can set up the <concept>automatic signature selection
1359 tool</concept> using <file>mime-setup</file>. If you want to
1360 automatically select the signature file depending on how the message
1361 headers show, add lines like shown below to your .emacs (Refer to the
1362 reference manual of <file>signature.el</file> for more details).
1363
1364 <lisp>
1365 (setq signature-file-alist
1366       '((("Newsgroups" . "jokes")       . "~/.signature-jokes")
1367         (("Newsgroups" . ("zxr" "nzr")) . "~/.signature-sun")
1368         (("To" . ("ishimaru" "z-suzuki")) . "~/.signature-sun")
1369         (("To" . "tea")                 . "~/.signature-jokes")
1370         (("To" . ("sim" "oku" "takuo")) . "~/.signature-formal")
1371         ))
1372 </lisp>
1373
1374
1375 <defvar name="mime-setup-use-signature">
1376 <p>
1377 If it is not <code>nil</code>, <file>mime-setup.el</file> sets up for
1378 <file>signature.el</file>.  Its default value is <code>t</code>.
1379 </defvar>
1380
1381
1382 <defvar name="mime-setup-signature-key-alist">
1383 <p>
1384 It defines key to bind signature inserting command for each
1385 major-mode.  Its default value is following:
1386
1387 <lisp>
1388         ((mail-mode . "\C-c\C-w"))
1389 </lisp>
1390
1391 <p>
1392 If you want to change, please rewrite it.  For example:
1393
1394 <lisp>
1395 (set-alist 'mime-setup-signature-key-alist
1396            'news-reply-mode "\C-c\C-w")
1397 </lisp>
1398
1399 </defvar>
1400
1401
1402 <defvar name="mime-setup-default-signature-key">
1403 <p>
1404 If key to bind signature inserting command for a major-mode is not
1405 found from <code>mime-setup-signature-key-alist</code>, its value is
1406 used as key.  Its default value is <code>"\C-c\C-s"</code>.
1407 </defvar>
1408
1409
1410 <h3> Notices for GNUS
1411 <node> Notice about GNUS
1412 <p>
1413 When <file>mime-setup.el</file> sets up for <file>signature.el</file>,
1414 it sets variable <code>gnus-signature-file</code> to <code>nil</code>.
1415 Therefore GNUS does not insert signature automatically when it is
1416 sending a message.  Reason of this setting is following:
1417 <p>
1418 GNUS inserts signature after <file>tm-edit.el</file> composed as MIME
1419 message.  Therefore signature inserted by GNUS is not processed as a
1420 valid MIME part.  In particular, for multipart message, signature
1421 places in outside of MIME part.  So MIME MUA might not display it.
1422 <p>
1423 Other notice is key bind.  In historical reason, key bind to insert
1424 signature is <kbd>C-c C-s</kbd> (like <a file="mh-e">mh-e</a>) instead
1425 of <kbd>C-c C-w</kbd>. If you change to GNUS's default, please set
1426 following:
1427
1428 <lisp>
1429 (set-alist 'mime-setup-signature-key-alist 'news-reply-mode "\C-c\C-w")
1430 </lisp>
1431
1432
1433 <h2> Setting not to use tm-edit
1434 <node> tm-setup
1435 <p>
1436 <concept>tm-setup</concept> only sets up <a node="tm-MUA">tm-MUA</a>s.
1437 In other words, it is a setting to avoid to use tm-edit.  If you don't
1438 want to compose MIME message or want to use other MIME composer,
1439 please use it instead of <file>mime-setup.el</file>.
1440 <p>
1441 For example, please insert following into <file>~/.emacs</file>:
1442
1443 <lisp>
1444 (load "tm-setup")
1445 </lisp>
1446
1447 <p>
1448
1449 <memo>
1450 <p>
1451 If you use <file>mime-setup.el</file>, you you don't need to load
1452 <file>tm-setup.el</file>.
1453 </memo>
1454
1455
1456 <h2> Setting for VM
1457 <node> setting for VM
1458 <p>
1459 If you use <concept>vm</concept>, please insert following in
1460 <file>~/.vm</file>:
1461
1462 <lisp>
1463 (require 'tm-vm)
1464 </lisp>
1465
1466
1467 <memo title="Notice">
1468 <p>
1469 If you use <concept>BBDB</concept>, please insert <code>(require
1470 'tm-vm)</code> <bf>after</bf> <code>(bbdb-insinuate-vm)</code>.
1471 </memo>
1472
1473
1474 <h2> Setting up without loading provided setup files
1475 <node> manual setting
1476 <p>
1477 You may find the valuable hints in <file>mime-setup.el</file> or
1478 <file>tm-setup.el</file> if you want to set up MIME environment
1479 without loading the tm-provided setup files.
1480
1481 <memo>
1482 <p>
1483 Current tm provides some convenient features to expect tm-edit, and
1484 they can not use if <file>mime-setup.el</file> is not used.  If you
1485 want to set up original setting to use tm-edit, please declare
1486 following setting:
1487
1488 <lisp>
1489 (provide 'mime-setup)
1490 </lisp>
1491
1492 </memo>
1493
1494
1495 <h1> How to report bug and about mailing list of tm
1496 <node> Bug report
1497 <p>
1498 If you write bug-reports and/or suggestions for improvement, please
1499 send them to the tm Mailing List:
1500
1501 <ul>
1502 <li> Japanese <mail>bug-tm-ja@chamonix.jaist.ac.jp</mail>
1503 <li> English <mail>bug-tm-en@chamonix.jaist.ac.jp</mail>
1504 </ul>
1505
1506 <p>
1507 Notice that, we does not welcome bug reports about too old version.
1508 Bugs in old version might be fixed.  So please try latest version at
1509 first.
1510 <p>
1511 You should write <concept>good bug report</concept>.  If you write
1512 only ``tm does not work'', we can not find such situations.  At least,
1513 you should write name, type, variants and version of OS, emacs, tm and
1514 MUA, and setting.  In addition, if error occurs, to send backtrace is
1515 very important. <cf file="emacs" node="Bugs">
1516 <p>
1517 Bug may not appear only your environment, but also in a lot of
1518 environment (otherwise it might not bug).  Therefor if you send mail
1519 to author directly, we must write a lot of mails.  So please send mail
1520 to address for tm bugs instead of author.
1521 <p>
1522 Via the tm ML, you can report tm bugs, obtain the latest release of
1523 tm, and discuss future enhancements to tm.  To join the tm ML, send
1524 e-mail to:
1525
1526 <ul>
1527 <li> Japanese <mail>tm-ja-admin@chamonix.jaist.ac.jp</mail>
1528 <li> English  <mail>tm-en-admin@chamonix.jaist.ac.jp</mail>
1529 </ul>
1530
1531 <noindent>
1532 Since the user registration is done manually, please write the mail
1533 body in human-recognizable language (^_^).
1534
1535
1536 <h1> Concept Index
1537 <node> Concept Index
1538
1539 <cindex>
1540
1541
1542 <h1> Variable Index
1543 <node> Variable Index
1544
1545 <vindex>
1546
1547 </body>