File: rfc1494.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 (1067 lines) | stat: -rw-r--r-- 37,275 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
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067






Network Working Group                                      H. Alvestrand
Request for Comments: 1494                                  SINTEF DELAB
                                                             S. Thompson
                                                       Soft*Switch, Inc.
                                                             August 1993

       Equivalences between 1988 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 .............................................    2
   2.  Equivalence Table Definition .............................    2
   3.  Generic conversions ......................................    3
   3.1.  Byte copy ..............................................    3
   3.2.  Text Conversion ........................................    3
   3.3.  Image Conversion .......................................    3
   3.4.  Tunneling ..............................................    3
   4.  Conversion Table for known X.400 and MIME  Types .........    4
   4.1.  MIME to X.400 Table ....................................    4
   4.2.  X.400 to MIME Table ....................................    4
   5.  Newly defined X.400 Body Parts ...........................    5
   5.1.  Use of OBJECT IDENTIFIERs and ASN.1 MACROS .............    5
   5.2.  The Generic MIME Extended Body Part ....................    6
   5.3.  The PostScript body part ...............................    7
   5.4.  The JPEG body part .....................................    7
   5.5.  The GIF body part ......................................    8
   6.  Newly defined MIME content-types .........................    8
   6.1.  The application/x400-bp content-type ...................    8
   6.2.  The image/g3fax content-type ...........................    9
   6.2.1.  G3Fax Parameters .....................................    9
   6.2.2.  Content Encoding .....................................   10
   6.3.  The Application/ODA content-type .......................   11
   7. Equivalence Definitions ...................................   11
   7.1. IA5Text - text/plain ....................................   11
   7.2. GeneralText - text/plain (ISO-8859) .....................   12
   7.3. BilaterallyDefined -  application/octet-stream ..........   13
   7.4. ODA - application/oda ...................................   14
   7.5. g3-facsimile - image/g3fax ..............................   15
   7.6. application/postscript -  postscript-body-part ..........   16
   7.7. application/jpeg - jpeg-body-part .......................   16



Alvestrand & Thompson                                           [Page 1]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   7.8. image/gif - gif-body-part ...............................   16
   8. OID Assignments ...........................................   17
   9. IANA Registration form for new mappings ...................   17
   10. Security Considerations ..................................   18
   11. Authors' Addresses .......................................   18
   12. References ...............................................   19

1.  Introduction

   This document is a companion to [1], which defines the principles
   behind interworking between MIME-based RFC-822 mail and X.400 mail.
   This document describes the content of the "IANA MHS/MIME Equivalence
   table" referenced in the companion document, and defines the initial
   configuration of this table.  Mappings for new MIME content-types
   and/or X.400 body part types should be registered with the IANA to
   minimize redundancy and promote interoperability.

   In MIME, the term "content-type" is used to refer to an information
   object contained in the body of a message.  In contrast, X.400 uses
   the term "body part type."  In this document, the term "body part" is
   used to refer to either.

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

2.  Equivalence Table Definition

   For each MIME content-type/X.400 body part pair, the Equivalence
   Table will contain an entry with the following sections:

   X.400 Body Part
        This section identifies the X.400 Body Part governed by this
        Table entry. It includes any OBJECT IDENTIFIERs or other
        parameters necessary to uniquely identify the Body Part.

   MIME Content-Type
        This section identifies the MIME content-type governed by this
        Table entry.  The MIME content-type named here must be
        registered with the IANA.

   Conversion Type
        This section identifies the type of conversion applied.  See the
        section on Generic Conversions for an explanation of the
        possible values.







Alvestrand & Thompson                                           [Page 2]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   Comments (optional)
        This section gives any additional commentary that might be
        useful in understanding the mapping between the X.400 and MIME
        representations.

   The initial Equivalence Table entries in this document are described
   using this convention.  Any future submissions to the IANA should
   follow this format.

3.  Generic conversions

3.1.  Byte copy

   This is the trivial case, that is, no conversion at all.  The byte
   stream is simply copied between MIME and X.400.

   This is the preferred conversion, since it is the simplest.

   Implementors and vendors will be registering OBJECT IDENTIFIERs and
   MIME content-types for their various objects.  They are STRONGLY
   ENCOURAGED to specify their content formats such that a gateway can
   use Byte Copy to map between them.

   Note that in some cases, it is necessary to define exactly which
   ASN.1 construct to replace with the content of the MIME object.

3.2.  Text Conversion

   This type of conversion applies to text objects that cannot be mapped
   using a simple Byte Copy.  Conversion involves scanning and
   reformatting the object.  For example, the MIME and X.400 objects
   might differ in their encoding of nonstandard characters, or line or
   page breaks.

3.3.  Image Conversion

   This conversion type applies to raster images, like Group 3 Facsimile
   or JPEG.  Again, it differs from Byte Copy in that it involves
   scanning reformatting the byte stream.  It differs from Text
   Conversion in that it is pixel- oriented, rather than character-
   oriented.

3.4.  Tunneling

   This is not a conversion at all, but an encapsulation of the object.
   This is the fallback conversion, used when no explicit mapping
   applies.




Alvestrand & Thompson                                           [Page 3]

RFC 1494              X.400/MIME Body Equivalences           August 1993


4.  Conversion Table for known X.400 and MIME Types

   This section itemizes the equivalences for all currently known MIME
   content-types and X.400 body parts.

4.1.  MIME to X.400 Table

       MIME content-type          X.400 Body Part             Section
       -----------------          ------------------          -------
       text/plain
         charset=us-ascii         ia5-text                     7.1
         charset=iso-8859-x       EBP - GeneralText            7.2
       text/richtext              no mapping defined           5.2
       application/oda            EBP - ODA                    7.4
       application/octet-stream   bilaterally-defined          7.3
       application/postscript     EBP - mime-postscript-body   5.4, 7.6
       image/g3fax                g3-facsimile                 6.2, 7.5
       image/jpeg                 EBP - mime-jpeg-body         5.5, 7.7
       image/gif                  EBP - mime-gif-body          5.6, 7.8
       audio/basic                no mapping defined           5.2
       video/mpeg                 no mapping defined           5.2

       Abbreviation: EBP - Extended Body Part

4.2.  X.400 to MIME Table

                                Basic Body Parts

       X.400 Basic Body Part      MIME content-type           Section
       ---------------------      --------------------        -------
       ia5-text                   text/plain;charset=us-ascii 7.1
       voice                      No Mapping Defined          6.1
       g3-facsimile               image/g3fax                 6.2, 7.5
       g4-class1                  no mapping defined          6.1
       teletex                    no mapping defined          6.1
       videotex                   no mapping defined          6.1
       encrypted                  no mapping defined          6.1
       bilaterally-defined        application/octet-stream    7.3
       nationally-defined         no mapping defined          6.1
       externally-defined         See Extended Body Parts     6.1

       X.400 Extended Body Part  MIME content-type              Section
       ------------------------- --------------------           -------
       GeneralText               text/plain;charset=iso-8859-x  7.2
       ODA                       application/oda                7.4
       mime-postscript-body      application/postscript         5.3, 7.6
       mime-jpeg-body            image/jpeg                     5.4, 7.7
       mime-gif-body             image/gif                      5.5, 7.8



Alvestrand & Thompson                                           [Page 4]

RFC 1494              X.400/MIME Body Equivalences           August 1993


5.  Newly defined X.400 Body Parts

   This section defines new X.400 Body Parts for the purposes of
   interworking with MIME.

   All new X.400 Body Parts defined here will be Extended Body Parts, as
   defined in CCITT Recommendation X.420 [2].

5.1.  Use of OBJECT IDENTIFIERs and ASN.1 MACROS

   X.420 dictates that Extended Body Parts shall:

       (1)  use OBJECT IDENTIFIERs (OIDs) to uniquely identify
            the contents, and

       (2)  be defined by using the ASN.1 Macro:

               EXTENDED-BODY-PART-TYPE MACRO::=
               BEGIN
                  TYPE NOTATION  ::= Parameters Data
                  VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)

                  Parameters     ::=  "PARAMETERS" type "IDENTIFIED"
                                      "BY" value(OBJECT IDENTIFIER)
                                    | empty;
                  Data           ::= "DATA" type
               END

   To meet these requirements, this document uses the OID

      mime-mhs-bodies

   defined in [1], as the root OID for X.400 Extended Body Parts defined
   for MIME interworking.

   Each Extended Body Part contains Data and optional Parameters, each
   being named by an OID.  To this end, two OID subtrees are defined
   under mime-mhs-bodies, one for Data, and the other for Parameters:

          mime-mhs-bp-data  OBJECT IDENTIFIER ::=
                          { mime-mhs-bodies 1 }
          mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
                          { mime-mhs-bodies 2 }

   All definitions of X.400 body parts submitted to the IANA for
   registration must use the Extended Body Part Type macro for the
   definition.  See the next section for an example.




Alvestrand & Thompson                                           [Page 5]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   Lastly, the IANA will use the mime-mhs-bp-data and mime-mhs-bp-
   parameter OIDs as root OIDs for any new MIME content-type/subtypes
   that aren't otherwise registered in the Equivalence Table.

5.2.  The Generic MIME Extended Body Part

   The following X.400 Body Part is defined to carry any MIME content-
   type for which there is no explicit IANA registered mapping.

         mime-body-part EXTENDED-BODY-PART-TYPE
            PARAMETERS MimeParameters
               IDENTIFIED BY mime-generic-parameters
            DATA            OCTET STRING
            ::= mime-generic-data

         MimeParameters ::=
             SEQUENCE {
                 content-type       IA5String,
                 content-parameters SEQUENCE OF
                                    SEQUENCE {
                                        parameter          IA5String,
                                        parameter-value    IA5String
                                    }

                                    -- from RFC-1327, sec. 5.1.12
                 other-header-fields RFC822FieldList
             }

         mime-generic-parameters OBJECT IDENTIFIER ::=
             { mime-mhs-bp-parameter 1 }
         mime-generic-data       OBJECT IDENTIFIER ::=
             { mime-mhs-bp-data  1 }

   To convert the MIME content-type into the X.400 mime- body-part:

       (1)  Copy the "type/subtype" string from the MIME
            Content-Type: header field into
            MimeParameters.content-type

       (2)  For each "parameter=value" string in the MIME
            Content-Type header field, create a
            MimeParameters.content-parameters structure, and copy
            the "parameter" string into MimeParameters.content-
            parameters.parameter field and the "value" string
            into the paired MimeParameters.content-
            parameters.parameter-value field.

       (3)  Convert the MIME body part into its canonical form.



Alvestrand & Thompson                                           [Page 6]

RFC 1494              X.400/MIME Body Equivalences           August 1993


            (See appendix H of RFC 1341 [3] for a discussion
            of canonical in this context.) Said another way,
            reverse the transfer encoding to recover the original
            byte stream.

       (4)  Copy the canonical byte stream into the mime-body-
            part.data octet string.

       (5)  Remove the Content-type and the Content-transfer-
            encoding header fields from the MIME body part's
            RFC822 header.

       (6)  Any header fields starting with "Content-" in the
            MIME body part is placed in the optional other-
            header-fields structure. Note that this can only
            occur when the MIME content-type occurs as part of a
            "multipart" content-type.

   The mapping from the X.400 mime-body-part to a MIME content-type is
   the inverse of the above steps.

5.3.  The PostScript body part

   The following Extended Body Part is defined for PostScript data
   streams.  It has no parameters.

         postscript-body-part EXTENDED-BODY-PART-TYPE

           DATA             OCTET STRING
           ::= mime-postscript-body

         mime-postscript-body OBJECT IDENTIFIER ::=
                   { mime-mhs-bp-data 2 }

5.4.  The JPEG body part

   The following Extended Body Part is defined for JPEG data streams.
   It has no parameters.

          jpeg-body-part EXTENDED-BODY-PART-TYPE
            DATA            OCTET STRING
            ::= mime-jpeg-body

          mime-jpeg-body OBJECT IDENTIFIER ::=
                  { mime-mhs-bp-data 3 }






Alvestrand & Thompson                                           [Page 7]

RFC 1494              X.400/MIME Body Equivalences           August 1993


5.5.  The GIF body part

   The following Extended Body Part is defined for GIF data streams.  It
   has no parameters.

          gif-body-part EXTENDED-BODY-PART-TYPE
            DATA            OCTET STRING
            ::= mime-gif-body

          mime-gif-body OBJECT IDENTIFIER ::=
                  { mime-mhs-bp-data 4 }

6.  Newly defined MIME content-types

   This section defines new MIME content-types for the purposes of
   interworking with X.400.

6.1.  The application/x400-bp content-type

   This content-type is defined to carry any X.400(88) body part for
   which there is no registered IANA mapping.

       The content-type field is

         application/x400-bp

       The parameters are:

             bp-type=<INTEGER or OBJECT IDENTIFIER>

   The body contains the raw ASN.1 IPM.body octet stream, including the
   initial tag octet.

   If the body is a basic body part, the bp-type parameter is set to the
   number of the body part's context-specific tag, that is, the tag of
   the IPMS.Body.BodyPart component.

   If the body is an Extended Body Part, the bp-type parameter is set to
   the OBJECT IDENTIFIER from

            IPMS.body.externally-defined.data.direct-reference

   No attempt is made to turn the parameters of Extended Body Parts into
   MIME parameters.  (This task is the responsibility of the recipient's
   UA).

   For example, a basic VideotexBodyPart will have




Alvestrand & Thompson                                           [Page 8]

RFC 1494              X.400/MIME Body Equivalences           August 1993


      Content-type=application/x400-bp; bp-type=6

   whilst a Extended Videotex body part will have

      Content-type=application/x400-bp; bp-type=2.6.1.4.5

   application/x400-bp will need a content-transfer-encoding of base64
   or quoted-printable when carried in 7-bit MIME.  Since there is no
   way to know beforehand the content, it is recommended to just inspect
   the first 1 KByte or so of data and choose the one that seems to
   produce the more compact encoding.

   If this is not feasible, Base64 is recommended.

6.2.  The image/g3fax content-type

   This content-type is defined to carry G3 Facsimile byte streams.

   In general, a G3Fax image contains 3 pieces of information:

       (1)  A set of flags indicating the particular coding
            scheme.  CCITT Recommendation T.30 defines how the
            flags are transmitted over telephones. In this
            medium, the flags are carried as parameters in the
            MIME content-type header field.

       (2)  A structure that divides the bits into pages.  CCITT
            recommendation T.30 describes how to define page
            boundaries.  A page break algorithm is defined here
            that is independent of how the image data is
            conveyed.

       (3)  For each page, a sequence of bits that form the
            encoding of the image.  CCITT recommendation T.4
            defines the bit image format.  This is used without
            change.

6.2.1.  G3Fax Parameters

   The following parameters are defined:

       (1)  page-length - possible values: A4, B4 and Unlimited

       (2)  page-width - possible values: A3, A4, B4

       (3)  encoding - possible values: 1-dimensional, 2-
            dimensional, Uncompressed




Alvestrand & Thompson                                           [Page 9]

RFC 1494              X.400/MIME Body Equivalences           August 1993


       (4)  resolution - possible values: Fine, Coarse

       (5)  DCS - a bit string, represented in Base64.

       (6)  pages - an integer, giving the number of pages in the
            document

   If nothing is specified, the default parameter settings are:

         page-length=A4
         page-width=A4
         encoding=1-dimensional
         resolution=Coarse

   It is possible (but misleading) to view the representation of these
   values as single-bit flags. They correspond to the following bits of
   the T.30 control string and X.400 G3FacsimileParameters:

       Parameter               T.30 bit        X.400 bit

       page-length=A4             no bit set
       page-length=B4          19              21
       page-length=Unlimited   20              20

       page-width=A4              no bit set
       page-width=A3           18              22
       page-width=B4           17              23

       encoding=1-dimensional     no bit set
       encoding=2-dimensional  16              8
       encoding=Uncompressed   26              30

       resolution=Coarse          no bit set
       resolution=Fine         15              9

   The reason for the different bit numbers is that X.400 counts bits in
   an octet from the MSB down to the LSB, while T.30 uses the opposite
   numbering scheme.

   If any bit but these are set in the Device Control String, the DCS
   parameter should be supplied.

6.2.2.  Content Encoding

   X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT
   STRINGs. Each BIT STRING is a page of facsimile image data, encoded
   as defined by Recommendation T.4.  The following content encoding is
   reversible between MIME and X.400 and ensures that page breaks are



Alvestrand & Thompson                                          [Page 10]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   honored in the MIME representation.

   An EOL is defined as a bit sequence of

          000000000001 (eleven zeroes and a one).

   Each page of the message is delimited by a sequence of six (6) EOLs
   that MUST start on a byte boundary.  The image bit stream is padded
   as needed to achieve this alignment.

   Searching for the boundary is a matter of searching for the byte
   sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside
   the image.

   See Section 7.5 for the algorithm on conversion between this encoding
   and the X.400 encoding.

   The Base64 content-transfer-encoding is appropriate for carrying this
   content-type.

6.3.  The Application/ODA content-type

   The "ODA" subtype of application is used to indicate that a body
   contains information encoded according to the Office Document
   Architecture [4] standards, using the ODIF representation format.
   For application/oda, the Content- Type line should also specify an
   attribute/value pair that indicates the document application profile
   (DAP), using the key word "profile", and the document class, using
   the keyword "class".

   For the keyword "class", the values "formatted", "processable" and
   "formatted-processable" are legal values.

   Thus an appropriate header field  might look like this:

       Content-Type:  application/oda; profile=Q112;
       class=formatted

   Consult the ODA standard [4] for further information.

   The Base64 content-transfer-encoding is appropriate for carrying ODA.

7.  Equivalence Definitions

7.1.  IA5Text - text/plain

   X.400 Body Part: IA5Text
   MIME Content-type: text/plain; charset=US-ASCII



Alvestrand & Thompson                                          [Page 11]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   Conversion Type: Byte copy
   Comments:

   When mapping from X.400 to MIME, the "repertoire" parameter is
   ignored.

   When mapping from MIME to X.400, the "repertoire" parameter is set to
   IA5 (5).

   NOTE: The MIME Content-type headers are omitted, when mapping from
   X.400 to MIME, if and only if the IA5Text body part is the only body
   part in the IPMS.Body sequence.

   NOTE: IA5Text specifies the "currency" symbol in position 2/4. This
   is converted without comment to the "dollar" symbol, since the author
   of this document has seen many documents in which the position was
   intended to indicate "dollar" while he has not yet seen one in which
   the "currency" symbol is intended.

   (For reference: The T.50 (1988) recommendation, which defines IA5,
   talks about ISO registered set number 2, while ASCII, using the
   "dollar" symbol, is ISO registered set number 6. There are no other
   differences.)

7.2.  GeneralText - text/plain (ISO-8859)

   X.400 Body Part: GeneralText; CharacterSets in
                           6,100,101,109,110,126,127,138,144,148
   MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
   Conversion Type: Byte copy
   Comments:

   When mapping from X.400 to MIME, the character-set chosen from table
   below according to the value of Parameters.CharacterSets.

   When mapping from MIME to X.400, GeneralText is an Extended Body
   Part, hence it requires an OID.  The OID for the GeneralText body is
   defined in [5], part 8, annex D, as {2 6 1 4 11}. The OID for the
   parameters is {2 6 1 11 11}.

   The Parameters.CharacterSets is set from table below according to the
   value of "charset"

   NOTE: The GeneralText body part is defined in ISO 10021-8 [5], and
   NOT in the corresponding CCITT recommendation. Its parameters were
   heavily modified in a defect report, and will be a SET OF INTEGER
   (indicating the ISO registry numbers of all the used sets) in the
   next version of the standard.



Alvestrand & Thompson                                          [Page 12]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   The following table lists the MIME character sets and the
   corresponding ISO registry numbers. If no correspondence is found,
   this conversion fails, and the generic body part approach is used.

   MIME charset    ISO IR numbers          Comment
   -----------------------------------------------
   ISO-8859-1      6, 100                  West European "8-bit ASCII"
   ISO-8859-2      6, 101                  East European
   ISO-8859-3      6, 109                  <regarded as obsolete>
   ISO-8859-4      6, 110                  <regarded as obsolete>
   ISO-8859-5      6, 144                  Cyrillic
   ISO-8859-6      6, 127                  Arabic
   ISO-8859-7      6, 126                  Greek
   ISO-8859-8      6, 138                  Hebrew
   ISO-8859-8      6, 148                  Other Latin-using languages

   When converting from MIME to X.400, generate the correct OIDs for use
   in the message envelope's Encoded Information Types by looking up the
   ISO IR number in the above table, and then appending it to the id-
   cs-eit-authority {1 0 10021 7 1 0} OID.

   The escape sequences to designate and invoke the relevant character
   sets in their proper positions must be added to the front of the
   GeneralText character string.

7.3.  BilaterallyDefined - application/octet-stream

   X.400 Body Part: BilaterallyDefined
   MIME Content-Type: Application/Octet-Stream (no parameters)
   Conversion Type: Byte copy
   Comments:

   When mapping from MIME to X.400, if there are parameters present in
   the Content-Type: header field, the conversion fails since the
   BilaterallyDefined Body Part does not have any corresponding ASN.1
   parameters.

   DISCUSSION: The parameters "name" "type" and "conversions" are
   advisory, but may in some cases give vital hints on the expected
   handling of the file. The parameter "conversions" is not fully
   defined, but it is expected that it will be useful, so we cannot drop
   it and expect people to be satisfied.

   The parameter "padding" changes the interpretation of the last byte
   of the data, and so cannot be deleted.

   An option is to prepend an IA5 body part that contains the parameter
   text; this will aid unmodified readers, and can probably be made



Alvestrand & Thompson                                          [Page 13]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   reversible with suitable chicanery, but is it worth it????

   Also, use of BilaterallyDefined Body Parts is specifically deprecated
   in both 1988 and 1992 X.400.  It is retained solely for backward
   compatibility with 1984 systems. 1992 X.400 defines a File Transfer
   Body Part to solve this problem (i.e. binary file transfer through
   email). The standard and its regional profiles are not solid enough
   yet to exploit as a solution for this problem.

7.4.  ODA - application/oda

   X.400 Body Part: ODA
   MIME Content-Type: application/oda
   Conversion Type: Byte copy
   Comments:

   The ODA body part is defined in the CCITT document T.411 [6],
   appendix E, section E.2, "ODA identification in the P2 protocol of
   MHS"

   An abbreviated version of its ASN.1 definition is:

       oda-body-part EXTENDED-BODY-PART-TYPE
            PARAMETERS      OdaBodyPartParameters
            DATA            OdaData
            ::= id-et-oda

       OdaBodyPartParameters ::= SET {
            document-application-profile    [0] OBJECT IDENTIFIER
            document-architecture-class     [1] INTEGER {
                                            formatted (0)
                                            processable (1)
                                            formatted-processable(2)}}

       id-et-oda OBJECT IDENTIFIER ::= { 2 8 1 0 1 }

   Mapping from X.400 to MIME, the following is done:

   The Parameters.document-application-profile is mapped onto the MIME
   parameter "profile" according to the table below.

       Profile         OBJECT IDENTIFIER

       Q112            { iso (1) identified-organization (3) ewos (16)
                         eg (2) oda (6) profile (0)  q112 (1) }

   The Parameters.document-architecture-class is mapped onto the MIME
   parameter "class" according to the table below



Alvestrand & Thompson                                          [Page 14]

RFC 1494              X.400/MIME Body Equivalences           August 1993


       String                  Integer

       formatted               formatted(0)
       processable             processable(1)
       formatted-processable   formatted-processable(2)

   NOTE: This parameter is not defined in RFC 1341.

   The body of the MIME content-type is the Data part of the ODA body
   part.

   When mapping from MIME to X.400, the following steps are done:

   The Parameters.document-application-profile and Parameters.document-
   architecture-class are set from the tables above.  If any of the
   parameters are missing, the values for Q112 and formatted-processable
   are used.

   It is an option for the gateway implementor to try to access them
   from inside the document, where they are defined as

   document-profile.document-characteristics.document-architecture-class

   document-profile.document-characteristics.document-application-profile

   Gateways are NOT required to do this, since the document-
   characteristics are optional parameters.  If a gateway does not, it
   simply uses the defaulting rules defined above.

   The OBJECT IDENTIFIERs for the document application profile and for
   ODA {2 8 0 0} must be added to the Encoded Information Types
   parameter of the message envelope.

7.5.  g3-facsimile - image/g3fax

   X.400 Body part: g3-facsimile
   MIME Content-Type: image/g3fax
   Conversion Type: nearly Byte copy
   Comments:

   The Parameters of the X.400 G3Fax body part are mapped to the
   corresponding Parameters on the MIME Image/G3Fax body part and vice
   versa.  Note that:

       (1)  If fineResolution is not specified, pixels will be
            twice as tall as they are wide

       (2)  If any bit not corresponding to a specially named



Alvestrand & Thompson                                          [Page 15]

RFC 1494              X.400/MIME Body Equivalences           August 1993


            option is set in the G3Fax NonBasicParameters, the
            "DCS" parameter must be used.

       (3)  Interworking is not guaranteed if any bit apart from
            those specially named are used in the
            NonBasicParameters

   From X.400 to G3Fax, the body is created in the following way:

       (1)  Any trailing EOL markers on each bitstring is
            removed. The bistring is padded to a byte boundary.

       (2)  6 consecutive EOL markers are appended to each
            bitstring.

       (3)  The padded bitstrings are concatenated together

   An EOL marker is the bit sequence 000000000001 (11 zeroes and a one).

   From G3Fax to X.400, the body is created in the following way:

       (1)  The body is split into bitstrings at each occurrence
            of 6 consecutive EOL markers, and trailing EOLs and
            padding are removed

       (2)  Each bitstring is made into an ASN.1 BITSTRING

       (3)  The bitstrings are made into an ASN.1 SEQUENCE, which
            forms the body of the G3Fax body part.

7.6.  application/postscript - postscript-body-part

   X.400 Body Part: Extended Body Part, OID postscript-body-part
   MIME Content-Type: application/postscript
   Conversion Type: Byte Copy

7.7.  application/jpeg - jpeg-body-part

   X.400 Body Part: Extended Body Part, OID jpeg-body-part
   MIME Content-Type: application/jpeg
   Conversion Type: Byte Copy

7.8.  image/gif - gif-body-part

   X.400 Body Part: Extended Body Part, OID gif-body-part
   MIME Content-Type: application/gif
   Conversion Type: Byte Copy




Alvestrand & Thompson                                          [Page 16]

RFC 1494              X.400/MIME Body Equivalences           August 1993


8.  OID Assignments

       MIME-MHS-MAPPINGS DEFINITIONS ::= BEGIN


       IMPORTS
          mail, mime-mhs, mime-mhs-bodies
              FROM MIME-MHS;

       mime-mhs-bp-data OBJECT IDENTIFIER ::=
               { mime-mhs-bodies 1}

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

       mime-generic-data OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 1}

       mime-generic-parameters OBJECT IDENTIFIER ::=
               { mime-mhs-bp-parameter 1}

       mime-postscript-body OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 2}

       mime-jpeg-body OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 3}

       mime-gif-body OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 4};

9.  IANA Registration form for new mappings

   To: IANA@isi.edu
   Subject: Registration of new X.400/MIME content type mapping

   MIME type name:

   (this must have been registered previously with IANA)

   X.400 body part:

   X.400 Object Identifier for Data:

   (If left empty, an OID will be assigned by IANA under
   mime-mhs-bp-data)

   X.400 Object Identifier for Parameters:




Alvestrand & Thompson                                          [Page 17]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   (If left empty, an OID will be assigned by IANA under
   mime-mhs-bp-parameter.  If it is not used, fill in the
   words NOT USED.)

   X.400 ASN.1 Syntax:

   (must be an EXTENDED-BODY-PART-TYPE macro, or reference to
   a Basic body part type)

   Conversion algorithm:

   (must be defined completely enough for independent
   implementation. It may be defined by reference to RFCs).

   Person & email address to contact for further information:

   INFORMATION TO THE SUBMITTER:

   The accepted registrations will be listed in the "Assigned
   Numbers" series of RFCs.  The information in the
   registration form is freely distributable.

10.  Security Considerations

   Security issues are not discussed in this memo.

11.  Authors' Addresses

   Harald Tveit Alvestrand
   SINTEF DELAB
   N-7034 Trondheim
   NORWAY

   EMail: Harald.Alvestrand@delab.sintef.no


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

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








Alvestrand & Thompson                                          [Page 18]

RFC 1494              X.400/MIME Body Equivalences           August 1993


12.  References

   [1]  Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
        "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
        SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
        Consulting, Inc., Soft*Switch, Inc., August 1993.

   [2]  CCITT Recommendation X.420 (1988), Interpersonal Messaging
        System.

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

   [4]  ISO 8613; Information Processing: Text and Office System; Office
        Document Architecture (ODA) and Interchange Format (ODIF), Part
        1-8, 1989.

   [5]  ISO/IEC International Standard 10021, Information technology -
        Text Communication - Message-Oriented Text Interchange Systems
        (MOTIS) (Parts 1 to 8).

   [6]  CCITT Recommendation T.411 (1988), Open Document Architecture
        (ODA) and Interchange Format, Introduction and General
        Principles.

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

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

   [9]  CCITT Recommendation T.4, Standardization of Group 3 Facsimile
        Apparatus for Document Transmission (1988).

   [10] CCITT Recommendation T.30, Procedures For Document Facsimile
        Transmission in the General Switched Telephone Network (1988).

   [11] CCITT, Data Communication Networks - Message Handling Systems -
        Recommendations X.400 - X.420 (1988 version).

   [12] Alvestrand, H., "X.400 Use of Extended Character Sets", RFC
        1502, SINTEF DELAB, August 1993.








Alvestrand & Thompson                                          [Page 19]