doc/tm-en.sgml

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