doc/tm-en.sgml

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