File: rfc1495.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 (619 lines) | stat: -rw-r--r-- 20,071 bytes parent folder | download | duplicates (8)
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
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619






Network Working Group                                      H. Alvestrand
Request for Comments: 1495                                  SINTEF DELAB
Updates: 1327                                                   S. Kille
                                                        ISODE Consortium
                                                                R. Miles
                                                       Soft*Switch, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                             S. Thompson
                                                       Soft*Switch, Inc.
                                                             August 1993

            Mapping between X.400 and RFC-822 Message Bodies

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Table of Contents

   1.  Introduction .............................................    1
   2.  Approach .................................................    2
   3.  Mapping between X.400 and RFC-822 Message Bodies .........    3
   3.1  Mapping from X.400 to RFC-822 ...........................    4
   3.2  Mapping from RFC-822 to X.400 ...........................    5
   3.2.1 Asymmetric Mappings ....................................    6
   3.2.1.1 Message/External-Body ................................    6
   3.2.1.2 Message/Partial ......................................    6
   3.2.1.3 Nested Multipart Content-types .......................    6
   3.2.2 Multipart IPMS Heading Extension .......................    7
   4.  Mapping between X.400 and RFC-822 Message Headers ........    7
   5.  OID Assignments ..........................................    9
   6.  Security Considerations ..................................    9
   7.  Authors' Addresses .......................................   10
   8.  References ...............................................   11

1.  Introduction

   The Internet community is a large collection of networks under
   autonomous administration, but sharing a core set of protocols.
   These are known as the Internet suite of protocols (or simply
   "TCP/IP").

   Use of electronic-mail in the Internet is defined primarily by one



Alvestrand, Kille, Miles, Rose & Thompson                       [Page 1]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


   document, STD-11, RFC-822 [1], which defines the standard format for
   the exchange of messages.  RFC-822 has proven immensely popular; in
   fact, the 822-connected Internet, is larger than the scope of the
   IP-connected Internet.

   The framework provided by RFC-822 allows for memo-based textual
   messages.  Each message consists of two parts:  the headers and the
   body.  The headers are analogous to the structured fields found in an
   inter-office memo, whilst the body is free-form.  Both parts are
   encoded using ASCII.

   Recently, the Internet Engineering Task Force (IETF) has developed an
   document called,

      Multipurpose Internet Mail Extensions

   or MIME RFC-1341.  The title is actually misleading.  MIME defines
   structure for Internet message bodies.  It is not an extension to
   RFC-822.

   Independently of this, the International standards community
   developed a different framework in 1984 (some say that's the
   problem).  This framework is known as the OSI Message Handling System
   (MHS) or sometimes X.400.

   Since the introduction of X.400(84), there has been work ongoing for
   defining mappings between MHS and RFC-822.  The most recent work in
   this area is RFC-1327 [3], which focuses primarily on translation of
   envelope and headers.  This document is complimentary to RFC-1327 as
   it focuses on translation of the message body.  The mappings defined
   are largely symmetrical with respect to MIME and MHS structuring
   semantics, although the MIME semantics are somewhat richer.  In order
   to provide for reversible transformations, MHS heading extensions are
   used to carry the additional MIME semantics.

   Please send comments to the MIME-MHS mailing list:
   <mime-mhs@surfnet.nl>.

2.  Approach

   The mappings have been specifically designed to provide optimal
   behavior for three different scenarios:

   (1) Allow a MIME user and an MHS user to exchange an arbitrary binary
       content;

   (2) Allow MIME content-types to "tunnel" through an MHS relay that
       is, two MIME users can exchange content-types without loss



Alvestrand, Kille, Miles, Rose & Thompson                       [Page 2]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


       through an MHS relay); and,

   (3) Allow MHS body parts to "tunnel" through a MIME relay that is,
       two MHS users can exchange body parts without loss through a MIME
       relay).

   Other, related, scenarios can also be easily accommodated.

   To facilitate the mapping process, the Internet Assigned Numbers
   Authority (IANA) maintains a table termed the "IANA MHS/MIME
   Equivalence Table".  Once an enterprise has registered an OID to
   describe an MHS body part, it should complete a corresponding
   registry with the IANA for a MIME content-type/subtype.  In practice,
   the corresponding content-type will be "application", with an
   appropriate choice of sub-type and possible parameters.  If a new
   MIME content-type/subtype is registered with the IANA without a
   corresponding entry in the Equivalence Table, the IANA will assign it
   an OID, from the arc defined in this memo. See [4], section 5 for
   details.

   The companion document, "Equivalences between 1988 X.400 and RFC-822
   Message Bodies"[4], defines the initial configuration of this table.
   The mappings described in both this document and the companion
   document use the notational conventions of RFC-1327.

3.  Mapping between X.400 and RFC-822 Message Bodies

   MHS messages are comprised of an IPMS.heading and an IPMS.body.  The
   IPMS.Body is a sequence of IPMS.BodyParts.  An IPMS.BodyPart may be a
   nested message (IPMS.MessageBodyPart).

   A MIME message consists of headers and a content.  For the purpose of
   discussion, the content may be structured (multipart or message), or
   atomic (otherwise).  An element of a structured content may be a
   message or a content.  Both message and structured content have
   subtypes which do not have direct analogies in MHS.

   The mapping between X.400 and RFC-822 message bodies which this
   document defines is symmetrical for the following cases:

          (1) any atomic body part

          (2) multipart: digest and mixed subtypes

          (3) message/rfc822

   RFC-1327 specifies the mappings for headers.  Section 4 describes how
   those mappings are modified by this document.  When mapping between



Alvestrand, Kille, Miles, Rose & Thompson                       [Page 3]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


   an MHS body and a MIME content, the following algorithm is used:

3.1.  Mapping from X.400 to RFC-822

   This section replaces the text in RFC-1327 starting at the bottom of
   page 84,

       The IPMS.Body is mapped into the RFC-822 message body.  Each
       IPMS.BodyPart is converted to ASCII as follows:

   and continuing up to and including page 86 of Section 5.3.4 of RFC-
   1327.

             If the IPMS.Body

                  Body ::=
                      SEQUENCE OF
                          BodyPart

   consists of a single body part, then the RFC-822 message body is
   constructed as the MIME content corresponding to that body part.

   If the body part is an IPMS.MessageBodyPart (forwarded IPM), the
   mapping is applied recursively.  Otherwise, to map a specific MHS
   body part to a MIME content-type, the IANA MHS/MIME Equivalence table
   is consulted.  If the MHS body part is not identified in this table,
   then the body-part is mapped onto an "application/x400-bp" content,
   as specified in [4].

   If the IPMS.Body consists of more than one body part, then the RFC-
   822 message body is constructed as a

          multipart/mixed

   content-type, unless all of the body parts are messages, in which
   case it is mapped to a

          multipart/digest

   content-type.  Each component of the multipart content-type
   corresponds to a IPMS.BodyPart, preserving the ordering of the body
   parts in the IPMS.Body.

   There is one case which gets special treatement.  If the IPMS.Body
   consists solely of a single IA5Text body part, then the RFC822
   message body is NOT marked as a MIME content.  This prevents RFC822
   mailers from invoking MIME function unnecessarily.




Alvestrand, Kille, Miles, Rose & Thompson                       [Page 4]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


3.2.  Mapping from RFC-822 to X.400

   First, replace the first paragraph of Section 5.1.3 on page 72 of
   RFC-1327 to read as:

       The IPM (IPMS Service Request) is generated according to the
       rules of this section.  The IPMS.body usually consists of one
       IPMS.BodyPart of type

                           IPMS.IA5TextBodyPart

                      with
                           IPMS.IA5TextBodyPart.parameters.repertoire

       set to the default (ia5), which contains the body of the RFC-822
       message.  However, if the 822.MIME-Version header field is
       present, a special algorithm is used to generate the IPMS.body.


       Second, replace the "Comments:" paragraph on page 74 to reads as:

       Comments:

          If an 822.MIME-Version header field is not present,
          generate an IPMS.Bodypart of type

              IPMS.IA5TextBodyPart

          with

              IPMS.IA5TextBodyPart.parameters.repertoire

          set to the default (ia5), containing the value of
          the fields, preceded by the string "Comments: ".
          This body part shall preceed the other one.

   Third, add the remainder of this section to the end of Section 5.1.3
   of RFC-1327.

   If the 822.MIME-Version header field is present, the following
   mapping rules are used to generate the IPMS.body.

   If the MIME content-type is one of:

   (1)  any atomic body part

   (2)  multipart: digest and mixed subtypes




Alvestrand, Kille, Miles, Rose & Thompson                       [Page 5]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


   (3)  message/rfc822

   then the symmetric mapping applies as described in Section 6.1.  Note
   that the multipart content-types should be marked with the
   IPMS.HeadingExtension described below.

   Otherwise, three cases remain, which are discussed in turn.

3.2.1.  Asymmetric Mappings

3.2.1.1.  Message/External-Body

   This is mapped into a mime-body-part, as specified in [4].

3.2.1.2.  Message/Partial

   This is mapped onto a message, and the following heading extension is
   used.  The extension is derived from the message/partial parameters:

                  partial-message  HEADING-EXTENSION
                      VALUE PartialMessage
                      ::= id-hex-partial-message

                  PartialMessage ::=
                      SEQUENCE {
                          number INTEGER,
                          total  INTEGER,
                          id     IA5String
                      }

   If this heading is present when mapping from MHS to MIME, then a
   message/partial should be generated.

3.2.1.3.  Nested Multipart Content-types

   In MIME, a multipart content refers to a set of content-types, not a
   message with a set of content-types. However, a nested multipart
   content will always be mapped to an IPMS.MessageBodyPart, with an
   IPMS.BodyPart for each contained content-type.

   The only mandatory field in the heading is the IPMS.this-IPM, which
   must always be generated (by the gateway). A IPMS.subject field
   should also be generated where there is no "real" heading. This will
   present useful information to the non-MIME capable X.400(88) and to
   all X.400(84) UAs.






Alvestrand, Kille, Miles, Rose & Thompson                       [Page 6]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


   The IPM.subject fields for the various types are:

   mixed:        "Multipart Message"
   alternative:  "Alternate Body Parts containing the same information"
   digest:       "Message Digest"
   parallel:     "Body Parts to be interpreted in parallel"

3.2.2.  Multipart IPMS Heading Extension

   The following IPMS.HeadingExtension should be generated for all
   multipart content-types, with the enumerated value set according to
   the subtype:

                  multipart-message HEADING-EXTENSION
                      VALUE MultipartType
                      ::= id-hex-multipart-message

                  MultipartType ::=
                      ENUMERATED {
                          mixed(1),
                          alternative(2),
                          digest(3),
                          parallel(4)
                      }

   If this heading is present when mapping from MHS to MIME, then the
   appropriate multipart content-type should be generated.

4.  Mapping between X.400 and RFC-822 Message Headers

   Replace the first paragraph of Section 3.3.4 on page 26 of RFC-1327
   to read as:
        In cases where T.61 strings are used only for conveying human-
        interpreted information, the aim of this mapping is to render
        the characters appropriately in the remote character set, rather
        than to maximize reversibility.  For these cases, the following
        steps are followed to find an appropriate encoding:

        1) If all the characters in the string are contained within the
        ASCII repertoire, the string is simply copied.

        2) If all the characters in the string are from an IANA-
        registered character set, then the appropriate encoded-word(s)
        according to [5] are generated instead.

        3) If the characters in the string are from a character set
        which is not registered with the IANA, then the mappings to IA5
        defined in CCITT Recommendation X.408 (1988) shall be used



Alvestrand, Kille, Miles, Rose & Thompson                       [Page 7]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


        [CCITT/ISO88a].  These will then be encoded in ASCII.

        This approach will only be used for human-readable information
        (Subject and FreeForm Name).

        When mapping from an RFC-822 header, when an encoded-word (as
        defined in [5]) is encountered:

        1) If all the characters contained therein are mappable to T.61,
        the string content shall be converted into T.61.

        2) Otherwise, the encoded-word shall be copied directly into the
        T.61 string.

   Modify procedure "2a" on page 56 of RFC-1327 to read as:
        If the IPMS.ORDescriptor.free-form-name is present, convert it
        to ASCII or T.61 (Section 3.3.4), and use this as the 822.phrase
        component of the 822.mailbox construct.

   Modify the final paragraph of procedure "2" on page 55 of RFC-1327 to
   read as:
        The string is then encoded into T.61 or ASCII using a human-
        oriented mapping (as described in Section 3.3.4).  If the string
        is not null, it is assigned to IPMS.ORDescriptor.free-form.name.

   Modify the second paragraph of procedure "3" on page 55 of RFC-1327
   to read as:
        If the 822.group construct is present, any included 822.mailbox
        is encoded as above to generate a separate IPMS.ORDescriptor.
        The 822.group is mapped to T.61 or ASCII (as described in
        Section 3.3.4), and an IPMS.ORDescriptor with only an free-
        form-name component is built from it.

   Modify procedure "822.Subject" on page 62 of RFC-1327 to read as:

        Mapped to IMPS.Heading.subject.  The field-body uses the human-
        oriented mapping referenceed in Section 3.3.4.

   Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327 to
   read as:
        Mapped to "Subject:".  The contents are converted to ASCII or
        T.61 (Section 3.3.4).  Any CRLF are not mapped, but are used as
        points at which the subject field must be folded.








Alvestrand, Kille, Miles, Rose & Thompson                       [Page 8]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


5.  OID Assignments

   MIME-MHS DEFINITIONS ::= BEGIN


   mail OBJECT IDENTIFIER ::= { internet 7 }

   mime-mhs OBJECT IDENTIFIER ::= { mail 1 }

   mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }

   id-hex-partial-message OBJECT IDENTIFIER ::=
           { mime-mhs-headings 1 }

   id-hex-multipart-message OBJECT IDENTIFIER ::=
           { mime-mhs-headings 2 }


   mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }


   END

6.  Security Considerations

   There are no explicit security provisions in this document.  However,
   a warning is in order.  This document maps two mechanisms between
   RFC822 and X.400 that could cause problems.  The first is the
   transfer of binary files.  The inherent risks are well known and
   won't be reiterated here.  The second is the propagation of strong
   content typing.  The typing can be used to automatically "launch" or
   initiate applications against those contents.  Any such launching
   leaves the invoker vulnerable to application-specific viruses; for
   example, a spreadsheet macro or Postscript command that deletes
   files.  See [2], Section 7.4.2 for a Postscript-specific discussion
   of this issue.















Alvestrand, Kille, Miles, Rose & Thompson                       [Page 9]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


7.  Authors' Addresses

   Harald Tveit Alvestrand
   SINTEF DELAB
   N-7034 Trondheim
   NORWAY

   EMail: Harald.Alvestrand@delab.sintef.no


   Steve Kille
   ISODE Consortium
   P.O. Box 505
   London
   SW11 1DX
   England

   Phone: +44-71-223-4062
   EMail: S.Kille@ISODE.COM


   Robert S. Miles
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

   Phone: (215) 640-7556
   EMail: rsm@spyder.ssw.com


   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186
   US

   Phone: +1 415 968 1052
   Fax:   +1 415 968 2510
   EMail: mrose@dbc.mtview.ca.us


   Steven J. Thompson
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

   Phone: (215) 640-7556
   EMail: sjt@gateway.ssw.com



Alvestrand, Kille, Miles, Rose & Thompson                      [Page 10]

RFC 1495            MHS/RFC-822 Message Body Mapping         August 1993


8.  References

   [1] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying
       and Describing the Format of Internet Message Bodies", RFC 1341,
       Bellcore, Innosoft, June 1992.

   [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
       and RFC-822", RFC 1327, University College London, May 1992.

   [4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400
       and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch,
       Inc., August 1993.

   [5] Moore, K., "Representation of Non-ASCII Text in Internet Message
       Headers Message Bodies", RFC 1342, University of Tennesse, June
       1992.
































Alvestrand, Kille, Miles, Rose & Thompson                      [Page 11]