|
74
|
1 <!doctype sinfo system>
|
|
76
|
2 <!-- $Id: tm-en.sgml,v 1.2 1996/12/28 21:03:29 steve Exp $ -->
|
|
74
|
3 <head>
|
|
76
|
4 <title>tm 7.100 Manual (English Version)
|
|
74
|
5 <author>MORIOKA Tomohiko <mail>morioka@jaist.ac.jp</mail>
|
|
76
|
6 <date>1996/12/25
|
|
74
|
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
|
|
76
|
23 <p>
|
|
74
|
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>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
160 Any byte stream is called <concept>binary</concept>.
|
|
74
|
161 <p>
|
|
76
|
162 It does not require structureof lines. It differs from from <a
|
|
|
163 node="8bit">8bit</a>.
|
|
74
|
164 <p>
|
|
76
|
165 In addition, if line structured data contain too long line (more than
|
|
|
166 998 bytes), it is regarded as binary.
|
|
74
|
167
|
|
|
168
|
|
|
169 <h3> cn-gb, gb2312
|
|
|
170 <node> cn-gb
|
|
|
171 <p>
|
|
76
|
172 A <a node="MIME charset">MIME charset</a> for simplified Chinese
|
|
|
173 mainly used in the Chinese mainland.
|
|
74
|
174 <p>
|
|
76
|
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>.
|
|
74
|
178 <p>
|
|
76
|
179 It is defined in <a node="RFC 1922">RFC 1922</a>.
|
|
74
|
180
|
|
|
181
|
|
|
182 <h3> cn-big5, big5
|
|
|
183 <node> cn-big5
|
|
|
184 <p>
|
|
76
|
185 A <a node="MIME charset">MIME charset</a> for traditional Chinese
|
|
|
186 mainly used in Taiwan and Hon Kong.
|
|
74
|
187 <p>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
197 It corresponds to <dref>CNS 11643</dref>.
|
|
74
|
198
|
|
|
199
|
|
|
200 <h3> CNS 11643-1992
|
|
76
|
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>.
|
|
74
|
207 <p>
|
|
76
|
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>
|
|
74
|
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>
|
|
76
|
243 A field to specify presentation of entity or file name. It is an
|
|
|
244 extension for <dref>MIME</dref>.
|
|
74
|
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>
|
|
76
|
317 In this document, `Emacs' means GNU Emacs released by FSF, and `emacs'
|
|
|
318 means any variants of GNU Emacs.
|
|
74
|
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>
|
|
76
|
336 Method to insert whole <a node="RFC 822">Internet message</a> into
|
|
|
337 another Internet message.
|
|
74
|
338 <p>
|
|
76
|
339 For example, it is used to forward a message.
|
|
74
|
340 <p>
|
|
|
341 <cf node="message/rfc822">
|
|
|
342
|
|
|
343
|
|
76
|
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
|
|
74
|
356 <h3> euc-kr
|
|
|
357 <node> euc-kr
|
|
|
358 <p>
|
|
76
|
359 A <dref>MIME charset</dref> for Korean.
|
|
74
|
360 <p>
|
|
76
|
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>.
|
|
74
|
364 <p>
|
|
76
|
365 It is defined in <dref>RFC 1557</dref>.
|
|
74
|
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>
|
|
76
|
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.
|
|
74
|
385 <p>
|
|
76
|
386 Final byte of <dref>ISO 2022</dref> is 04/01 (`A').
|
|
74
|
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>
|
|
76
|
397 A <dref>94x94-character set</dref> for Chinese as supplement to
|
|
|
398 <dref>GB 2312</dref>. It is a standard of China.
|
|
74
|
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
|
|
76
|
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
|
|
74
|
413 <h3> hz-gb2312
|
|
|
414 <node> hz-gb2312
|
|
|
415 <p>
|
|
76
|
416 A <a node="MIME charset">MIME charset</a> for simplified Chinese
|
|
|
417 mainly used in the Chinese mainland.
|
|
74
|
418 <p>
|
|
76
|
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.
|
|
74
|
423 <p>
|
|
76
|
424 It is defined in RFC 1842 and 1843.
|
|
74
|
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>
|
|
76
|
438 It is a standard for character code structure and <dref>code
|
|
|
439 extension</dref> technique.
|
|
74
|
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>
|
|
76
|
450 A <dref>MIME charset</dref> for Chinese.
|
|
74
|
451 <p>
|
|
76
|
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>.
|
|
74
|
456 <p>
|
|
76
|
457 It is defined in <dref>RFC 1922</dref>.
|
|
74
|
458
|
|
|
459
|
|
|
460 <h3> iso-2022-cn-ext
|
|
|
461 <node> iso-2022-cn-ext
|
|
|
462 <p>
|
|
76
|
463 A <dref>MIME charset</dref> for Chinese.
|
|
74
|
464 <p>
|
|
76
|
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.
|
|
74
|
469 <p>
|
|
76
|
470 It is defined in <dref>RFC 1922</dref>.
|
|
74
|
471 <p>
|
|
|
472 <memo>
|
|
76
|
473 MULE 2.3 and current XEmacs/mule can not use it correctly.
|
|
74
|
474 <p>
|
|
76
|
475 Emacs/mule can use it.
|
|
74
|
476 </memo>
|
|
|
477
|
|
|
478
|
|
|
479 <h3> iso-2022-jp
|
|
|
480 <node> iso-2022-jp
|
|
|
481 <p>
|
|
76
|
482 A <dref>MIME charset</dref> for Japanese.
|
|
74
|
483 <p>
|
|
76
|
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>.
|
|
74
|
488 <p>
|
|
76
|
489 It is defined in RFC 1468.
|
|
74
|
490 <p>
|
|
|
491 <memo>
|
|
76
|
492 JIS X0208-1997? will define it in annex as non-<dref>ISO 2022</dref>
|
|
|
493 encoding.
|
|
74
|
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>
|
|
76
|
522 technique to extend <dref>ASCII</dref> to use <dref>KS C5601</dref> as
|
|
|
523 <dref>7bit</dref> text.
|
|
74
|
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>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
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.
|
|
74
|
688 <p>
|
|
76
|
689 It consists of <dref>GB 2312</dref>, <dref>GB 8565.2</dref> and
|
|
|
690 additional 150 characters.
|
|
74
|
691 <p>
|
|
76
|
692 Final byte of <dref>ISO 2022</dref> is 04/05 (`E').
|
|
74
|
693
|
|
|
694
|
|
|
695 <h3> JIS X0201
|
|
|
696 <node> JIS X0201
|
|
|
697 <p>
|
|
76
|
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.
|
|
74
|
701 <p>
|
|
76
|
702 It was renamed from <concept>JIS C6220-1976</concept>.
|
|
74
|
703
|
|
76
|
704 <standard abbrev="JIS X0201-1976" org="Japanese Standards Association"
|
|
74
|
705 title-en="Code for Information Interchange" number="JIS
|
|
|
706 X 0201-1976">
|
|
|
707
|
|
76
|
708 In addition, revised version will be published in 1997.
|
|
74
|
709
|
|
76
|
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">
|
|
74
|
714
|
|
|
715
|
|
|
716 <h3> JIS C6226-1978
|
|
|
717 <node> JIS C6226
|
|
|
718 <p>
|
|
76
|
719 A <dref>94x94-character set</dref> for Japanese. It was renamed to
|
|
|
720 JIS X0208-1978.
|
|
74
|
721 <p>
|
|
|
722 <cf node="JIS X0208">
|
|
|
723
|
|
|
724
|
|
|
725 <h3> JIS X0208
|
|
|
726 <node> JIS X0208
|
|
|
727 <p>
|
|
76
|
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.
|
|
74
|
731 <p>
|
|
76
|
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.
|
|
74
|
738 <p>
|
|
76
|
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.
|
|
74
|
742
|
|
76
|
743 <standard abbrev="JIS X0208-1978" org="Japanese Standards Association"
|
|
74
|
744 title-en="Code of the Japanese graphic character set for
|
|
|
745 information interchange" number="JIS C6226" year="1978">
|
|
76
|
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">
|
|
74
|
750
|
|
|
751 <p>
|
|
76
|
752 In addition, revised version will be published in 1997. (It does not
|
|
|
753 change graphic character set)
|
|
74
|
754
|
|
76
|
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">
|
|
74
|
759
|
|
|
760
|
|
|
761 <h3> JIS X0212-1990
|
|
|
762 <node> JIS X0212
|
|
|
763 <p>
|
|
76
|
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').
|
|
74
|
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
|
|
76
|
790 04/03 (`C').
|
|
74
|
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
|
|
76
|
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
|
|
74
|
839 <h3> message
|
|
|
840 <node> message
|
|
|
841 <p>
|
|
76
|
842 In this document, it means mail defined in <dref>RFC 822</dref> and
|
|
|
843 news message defined in <dref>RFC 1036</dref>.
|
|
74
|
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>
|
|
76
|
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.
|
|
74
|
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>
|
|
76
|
903 <a node="coded character set">Coded character set</a> used in
|
|
|
904 <dref>Content-Type field</dref> or charset parameter of <a
|
|
74
|
905 node="encoded-word">encoded-word</a>.
|
|
|
906 <p>
|
|
|
907 It is defined in <dref>RFC 2045</dref>.
|
|
|
908 <p>
|
|
76
|
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)
|
|
74
|
913
|
|
|
914
|
|
|
915 <h3> MTA
|
|
|
916 <node> MTA
|
|
|
917 <p>
|
|
76
|
918 <concept>Message Transfer Agent</concept>. It means mail transfer
|
|
|
919 programs (ex. sendmail) and news servers.
|
|
74
|
920 <p>
|
|
|
921 <cf node="MUA">
|
|
|
922
|
|
|
923
|
|
|
924 <h3> MUA
|
|
|
925 <node> MUA
|
|
|
926 <p>
|
|
76
|
927 <concept>Message User Agent</concept>. It means mail readers and news
|
|
|
928 readers.
|
|
74
|
929 <p>
|
|
|
930 <cf node="MTA">
|
|
|
931
|
|
|
932
|
|
|
933 <h3> MULE
|
|
|
934 <node> MULE
|
|
|
935 <p>
|
|
76
|
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">
|
|
74
|
942 <p>
|
|
76
|
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>.
|
|
74
|
947 <p>
|
|
76
|
948 In addition, there is XEmacs with mule feature.
|
|
74
|
949 <p>
|
|
76
|
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.
|
|
74
|
956
|
|
|
957
|
|
|
958 <h3> Multipart
|
|
|
959 <node> multipart
|
|
|
960 <p>
|
|
|
961 <concept>multipart</concept> means <dref>media type</dref> to insert
|
|
76
|
962 multiple <a node="entity">entities</a> in a single body. Or it also
|
|
|
963 indicates a message consists of multiple entities.
|
|
74
|
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>
|
|
76
|
1014 It is a <dref>Security multipart</dref> defined in
|
|
|
1015 RFC 1847, used to represent encrypted message.
|
|
74
|
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>
|
|
76
|
1045 It is a <dref>Security multipart</dref> defined in
|
|
|
1046 RFC 1847, used to represent signed message.
|
|
74
|
1047 <p>
|
|
|
1048 <cf node="PGP/MIME">
|
|
|
1049
|
|
|
1050
|
|
|
1051 <h3> PGP
|
|
|
1052 <node> PGP
|
|
|
1053 <p>
|
|
76
|
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>.
|
|
74
|
1057 <p>
|
|
76
|
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.
|
|
74
|
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>
|
|
76
|
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.
|
|
74
|
1075 <p>
|
|
76
|
1076 PGP-kazu defines a <dref>media type</dref>,
|
|
|
1077 <concept>application/pgp</concept>.
|
|
74
|
1078 <p>
|
|
76
|
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.
|
|
74
|
1082 <p>
|
|
76
|
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.
|
|
74
|
1085
|
|
|
1086
|
|
|
1087 <h3> PGP/MIME
|
|
|
1088 <node> PGP/MIME
|
|
|
1089 <p>
|
|
76
|
1090 <dref>PGP</dref> and <dref>MIME</dref> integration proposed by Michael
|
|
|
1091 Elkins.
|
|
74
|
1092 <p>
|
|
76
|
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.
|
|
74
|
1097 <p>
|
|
76
|
1098 <dref>PGP/MIME</dref> will be standard of PGP message.
|
|
74
|
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>
|
|
76
|
1128 A RFC defines format of Internet mail message, mainly <concept>message
|
|
|
1129 header</concept>.
|
|
74
|
1130
|
|
|
1131 <memo>
|
|
|
1132 <p>
|
|
76
|
1133 news message is based on RFC 822, so <concept>Internet
|
|
|
1134 message</concept> may be more suitable than <concept>Internet
|
|
|
1135 mail</concept> .
|
|
74
|
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>
|
|
76
|
1146 A RFC defines an <a node="encapsulation">
|
|
|
1147 <concept>encapsulation</concept></a> method for <a node="RFC
|
|
|
1148 822">Internet mail</a>.
|
|
74
|
1149 <p>
|
|
76
|
1150 It conflicts with <dref>MIME</dref>, so you should use
|
|
|
1151 <dref>message/rfc822</dref>.
|
|
74
|
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>
|
|
76
|
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.
|
|
74
|
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>
|
|
76
|
1180 A RFC defines <dref>MIME charset</dref>s for Korean,
|
|
|
1181 <dref>euc-kr</dref> and <dref>iso-2022-kr</dref>.
|
|
74
|
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>
|
|
76
|
1191 A RFC defines <dref>MIME charset</dref>s for Chinese,
|
|
74
|
1192 <dref>iso-2022-cn</dref>, <dref>iso-2022-cn-ext</dref>,
|
|
76
|
1193 <dref>cn-gb</dref>, <dref>cn-big5</dref>, etc.
|
|
74
|
1194 <p>
|
|
76
|
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>.
|
|
74
|
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>
|
|
76
|
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">
|
|
74
|
1249
|
|
|
1250
|
|
|
1251 <h3> Security multipart
|
|
|
1252 <node> Security multipart
|
|
|
1253 <p>
|
|
76
|
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.
|
|
74
|
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>
|
|
76
|
1293 A libraries to provide user interface about <dref>MIME</dref> for
|
|
|
1294 emacs. tm stands for `tools for MIME'.
|
|
74
|
1295
|
|
76
|
1296 <memo title="Unimportant notice(^-^;">
|
|
74
|
1297 <p>
|
|
|
1298 <ul>
|
|
76
|
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 (^-^;
|
|
74
|
1302 </ul>
|
|
|
1303 </memo>
|
|
|
1304
|
|
|
1305
|
|
|
1306 <h3> tm-MUA
|
|
|
1307 <node> tm-MUA
|
|
|
1308 <p>
|
|
76
|
1309 <dref>MUA</dref> or MUA extender using <a node="tm-kernel">tm</a>.
|
|
74
|
1310 <p>
|
|
76
|
1311 <concept>tm oomori package</concept> has following extenders:
|
|
74
|
1312
|
|
|
1313 <ul>
|
|
76
|
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
|
|
74
|
1320 </ul>
|
|
|
1321
|
|
|
1322
|
|
|
1323 <h3> us-ascii
|
|
|
1324 <node> us-ascii
|
|
|
1325 <p>
|
|
76
|
1326 A <a node="MIME charset">MIME charset</a> for primary Latin script
|
|
|
1327 mainly written by English or other languages.
|
|
74
|
1328 <p>
|
|
76
|
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.
|
|
74
|
1332 <p>
|
|
76
|
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.
|
|
74
|
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
|
|
76
|
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
|
|
74
|
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>
|
