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