File: rfc1154.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (395 lines) | stat: -rw-r--r-- 11,820 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395






Network Working Group                                        D. Robinson
Request for Comments: 1154                                    R. Ullmann
                                                    Prime Computer, Inc.
                                                              April 1990


              Encoding Header Field for Internet Messages

1. Status of the Memo

   This RFC proposes an elective experimental Encoding header field to
   permit the mailing of multi-part, multi-structured messages.

   The use of Encoding updates RFC 1049 (Content-Type), and is a
   suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement)
   [4,7,8].

   Distribution of this memo is unlimited.

2. Introduction

   RFC 822 [2] defines an electronic mail message to consist of two
   parts, the message header and the message body, separated by an
   apparently blank line.

   The Encoding header field permits the message body itself to be
   further broken up into parts, each part also separated from the next
   by an apparently blank line.

   Thus, conceptually, a message has a header part, followed by one or
   more body parts, all separated by blank lines.

   Each body part has an encoding type.  The default (no Encoding field
   in the header) is a message body of one part of type "text".

   3. The Encoding Field

   The Encoding field consists of one or more subfields, separated by
   commas.  Each subfield corresponds to a part of the message, in the
   order of that part's appearance.  A subfield consists of a line
   count, a keyword defining the encoding, and optional information
   relevant only to the specific encoding.  The line count is optional
   in the last subfield.

3.1. Format of the Encoding Field

   The format of the Encoding field is:




Robinson & Ullmann                                              [Page 1]

RFC 1154      Encoding Header Field for Internet Messages     April 1990


     [<count> <keyword> [<options>], ]* [<count>] <keyword> [<options>]

     where:

        <count>   := a decimal integer
        <keyword> := a single alphanumeric token starting with an alpha
        <options> := keyword-dependent options

3.2. <count>

   The line count is a decimal number specifying the number of text
   lines in the part.  Parts are separated by a blank line, which is not
   included in the count of either the proceeding or following part.
   Because a count always begins with a digit and a keywords always
   begins with an letter, it is always possible to determine if the
   count is present.  (The count is first because it is the only
   information of interest when skipping over the part.)

   The count is not required on the last or only part.

3.3. <keyword>

   The keyword defines the encoding type.  The keyword is a common
   single word name for the encoding type.  The keywords are not case-
   sensitive.

   The list of standard keywords is intended to be the same as the list
   used for the Content-Type: header described in [6].  This RFC
   proposes additions to the list.  Implementations can then treat
   "Content-Type" as an alias of "Encoding", which will always have only
   one body part.

3.4. <options>

   The optional information is used to specify additional keyword-
   specific information needed for interpreting the contents of the
   encoded part.  It is any sequence of tokens not containing a comma.

3.5. Encoding Version Numbers

   In general, version numbers for encodings, when not actually
   available within the contents of the encoded information, will be
   handled as options.

3.6. Comments

   Comments enclosed in parentheses may, of course, be inserted anywhere
   in the Encoding field.  Mail reading systems may pass the comments to



Robinson & Ullmann                                              [Page 2]

RFC 1154      Encoding Header Field for Internet Messages     April 1990


   their clients.  Comments must not be used by mail reading systems for
   content interpretation; that is the function of options.

4. Encodings

   This section describes some of the defined encodings used.

   As with the other keyword-defined parts of the header format
   standard, extensions in the form of new keywords are expected and
   welcomed.  Several basic principles should be followed in adding
   encodings:

      - The keyword should be the most common single word name for the
      encoding, including acronyms if appropriate.  The intent is that
      different implementors will be likely to choose the same name for
      the same encoding.

      - Keywords not be too general: "binary" would have been a bad
      choice for the "hex" encoding.

      - The encoding should be as free from unnecessary idiosyncracies
      as possible, except when conforming to an existing standard, in
      which case there is nothing that can be done.

      - The encoding should, if possible, use only the 7 bit ASCII
      printing characters if it is a complete transformation of a source
      document (e.g., "hex" or "uuencode").  If it is essentially a text
      format, the full range may be used.  If there is an external
      standard, the character set may already be defined.

   Keywords beginning with "X-" are permanently reserved to
   implementation-specific use.  No standard registered encoding keyword
   will ever begin with "X-".

4.1. Text

   This indicates that the message is in no particular encoded format,
   but is to be presented to the user as is.

   The full range of the ASCII character set is used.  The message is
   expected to consist of lines of reasonable length (less than 1000
   characters).

   On some transport services, only the 7 bit subset of ASCII can be
   used.  Where full 8 bit transparency is available, the text is
   assumed to be ISO 8859-1 [3] (ASCII-8).





Robinson & Ullmann                                              [Page 3]

RFC 1154      Encoding Header Field for Internet Messages     April 1990


4.2. Message

   This encoding indicates that the body part is itself in the format of
   an Internet message, with its own header part and body part(s).  A
   "message" body part's message header may be a full internet message
   header or it may consist only of an Encoding field.

   Using the message encoding on returned mail makes it practical for a
   mail reading system to implement a reliable resending function, if
   the mailer generates it when returning contents.  It is also useful
   in a "copy append" MUA operation.

   Message encoding is also used when mapping to X.400 to handle
   recursively included X.400 P2 messages.

4.3. Hex

   The encoding indicates that the body part contains binary data,
   encoded as 2 hexadecimal digits per byte, highest significant nibble
   first.

   Lines consist of an even number of hexadecimal digits.  Blank lines
   are not permitted.  The decode process must accept lines with between
   2 and 1000 characters, inclusive.

4.4. EVFU

   EVFU (Electronic Vertical Format Unit) specifies that each line
   begins with a one-character "channel selector".  The original purpose
   was to select a channel on a paper tape loop controlling the printer.

   This encoding is sometimes called "FORTRAN" format. It is the default
   output format of FORTRAN programs on a number of computer systems.

   The legal characters are '0' to '9', '+', '-', and space.  These
   correspond to the 12 rows (and absence of a punch) on a printer
   control tape (used when the control unit was electromechanical).

   The channels that have generally agreed definitions are:

           1     advances to the first print line on the next page
           0     skip a line, i.e., double-space
           +     over-print the preceeding line
           -     skip 2 lines, i.e., triple-space
        (space)  print on the next line, single-space






Robinson & Ullmann                                              [Page 4]

RFC 1154      Encoding Header Field for Internet Messages     April 1990


4.5. EDI

   The EDI (Electronic Document Interchange) keyword indicates that the
   message or part is a business document, formatted according to ANSI
   X12 or related standards.

   The first word after the EDI keyword indicates the particular
   interchange standard.

   A message containing a note and 2 X12 purchase orders might have an
   encoding of:

       Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12

4.6. X.400

   The Encoding header field provides a mechanism for mapping multi-part
   messages between CCITT X.400 [1] and RFC 822.

   The X.400 keyword specifies a section that is converted from an X.400
   body part type not known to the gateway, or not corresponding to a
   useful internet encoding.

   If the message transits another gate, or if the receiving user has
   the appropriate software, it can be decoded and used.

   The X.400 keyword is followed by a second token indicating the method
   used.  The simplest form is "X.400 HEX", with the complete X.409
   encoding of the body part in hexadecimal.  More compact is "X.400
   3/4", using the 3-byte to 4-character encoding as specified in RFC
   1113, section 4.3.2.4.

4.7. uuencode

   The uuencode keyword specifies a section consisting of the output of
   the uuencode program supplied as part of uucp.

4.8. encrypted

   The encrypted keyword indicates that the section is encrypted with
   the methods in RFC 1115 [8].  This replaces the possible use of RFC
   934 [5] encapsulation.

References

  [1]  International Telegraph and Telephone Consultative Committee,
       "Data Communication Networks: Message Handling Systems", In CCITT
       Recommendations X.400 to X.430, VIIIth Plenary Assembly, Malaga-



Robinson & Ullmann                                              [Page 5]

RFC 1154      Encoding Header Field for Internet Messages     April 1990


       Torremolinos, 1984, Fascicle VIII.7 ("Red Book").

  [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", RFC 822, University of Delaware, August 1982.

  [3]  International Organization for Standardization, "Information
       processing - 8-bit single-byte coded graphic character sets -
       Part 1: Latin alphabet No. 1", ISO 8859-1, ISO, 1987.

  [4]  Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       I -- Message Encipherment and Authentication Procedures", RFC
       1113, IAB Privacy Task Force, August 1989.

  [5]  Rose, M., and E. Stefferud, "Proposed Standard for Message
       Encapsulation", RFC 943, University of Delaware and NMA, January
       1985.

  [6]  Sirbu, M., "Content-type Header Field for Internet Messages", RFC
       1049, CMU, March 1988.

  [7]  Kent, S., and J. Linn, "Privacy Enhancement for Internet
       Electronic Mail: Part II -- Certificate-Based Key Management",
       RFC 1114, IAB Privacy Task Force, August 1989.

  [8]  Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
       Task Force, August 1989.

Security Considerations

   Security issues are not addressed in this memo.

Authors' Addresses

   David Robinson 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

   Phone: +1 508 879 2960 x1774

   Email: DRB@Relay.Prime.COM


   Robert Ullmann 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701



Robinson & Ullmann                                              [Page 6]

RFC 1154      Encoding Header Field for Internet Messages     April 1990


   Phone: +1 508 879 2960 x1736

   Email: Ariel@Relay.Prime.COM
















































Robinson & Ullmann                                              [Page 7]