idnits 2.17.1 draft-ietf-mixer-bodymap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-mixer-bodymap-01.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mixer-bodymap-01.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mixer-bodymap-01.txt.', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-mixer-bodymap-01.txt.', but the file name used is 'draft-ietf-mixer-bodymap-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Introduction and General Principles' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 408: '... (6) EOLs that MUST start on a byte ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 58 has weird spacing: '...ined in the b...' == Line 158 has weird spacing: '...-stream bila...' == Line 425 has weird spacing: '... a body conta...' == Line 427 has weird spacing: '...ntation forma...' == Line 429 has weird spacing: '...e/value pair ...' == (2 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date () is 739384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MIXER' on line 951 looks like a reference -- Missing reference section? 'ODA' on line 444 looks like a reference -- Missing reference section? 'MOTIS' on line 972 looks like a reference -- Missing reference section? '0' on line 595 looks like a reference -- Missing reference section? '1' on line 596 looks like a reference -- Missing reference section? 'New' on line 866 looks like a reference -- Missing reference section? 'RFC-822' on line 940 looks like a reference -- Missing reference section? 'MIME' on line 945 looks like a reference -- Missing reference section? 'RFC-X400USE' on line 986 looks like a reference Summary: 16 errors (**), 1 flaw (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Equivalences between 1988 X.400 and RFC-822 Message Bodies 3 Tue May 16 13:42:18 MET DST 1995 5 Harald Tveit Alvestrand 6 UNINETT 7 Harald.T.Alvestrand@uninett.no 9 Steven J. Thompson 10 Soft*Switch, Inc. 11 sjt@gateway.ssw.com 13 Status of this Memo 15 The name of this draft is draft-ietf-mixer-bodymap-01.txt. 17 The following text is required for all drafts: 19 This document is an Internet Draft. Internet Drafts 20 are working documents of the Internet Engineering 21 Task Force (IETF), its Areas, and its Working Groups. 22 Note that other groups may also distribute working 23 documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a 26 maximum of six months. Internet Drafts may be 27 updated, replaced, or obsoleted by other documents at 28 any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other 30 than as a "working draft" or "work in progress." 32 Please check the I-D abstract listing contained in 33 each Internet Draft directory to learn the current 34 status of this or any other Internet Draft. 36 This document is an update to RFC 1494, and will obsolete 37 it once it is ready for publication. 39 draft X.400/MIME body equivalences July 95 41 Please send comments to the MIXER mailing list: 42 44 draft X.400/MIME body equivalences July 95 46 1. Introduction 48 This document is a companion to [MIXER], which defines the 49 principles behind interworking between MIME-based RFC-822 50 mail and X.400 mail. This document describes the content 51 of the "IANA MHS/MIME Equivalence table" referenced in the 52 companion document, and defines the initial configuration 53 of this table. Mappings for new MIME content-types and/or 54 X.400 body part types should be registered with the IANA 55 to minimize redundancy and promote interoperability. 57 In MIME, the term "content-type" is used to refer to an 58 information object contained in the body of a message. 59 In contrast, X.400 uses the term "body part type." In 60 this document, the term "body part" is used to refer to 61 either. 63 draft X.400/MIME body equivalences July 95 65 2. Equivalence Table Definition 67 For each MIME content-type/X.400 body part pair, the 68 Equivalence Table will contain an entry with the following 69 sections: 71 X.400 Body Part 72 This section identifies the X.400 Body Part governed 73 by this Table entry. It includes any OBJECT 74 IDENTIFIERs or other parameters necessary to uniquely 75 identify the Body Part. 77 MIME Content-Type 78 This section identifies the MIME content-type 79 governed by this Table entry. The MIME content-type 80 named here must be registered with the IANA. 82 Conversion Type 83 This section identifies the type of conversion 84 applied. See the section on Generic Conversions for 85 an explanation of the possible values. 87 Comments (optional) 88 This section gives any additional commentary that 89 might be useful in understanding the mapping between 90 the X.400 and MIME representations. 92 The initial Equivalence Table entries in this document are 93 described using this convention. Any future submissions 94 to the IANA should follow this format. 96 draft X.400/MIME body equivalences July 95 98 3. Generic conversions 100 3.1. Byte copy 102 This is the trivial case, that is, no conversion at all. 103 The byte stream is simply copied between MIME and X.400. 105 This is the preferred conversion, since it is the 106 simplest. 108 Implementors and vendors will be registering OBJECT 109 IDENTIFIERs and MIME content-types for their various 110 objects. They are STRONGLY ENCOURAGED to specify their 111 content formats such that a gateway can use Byte Copy to 112 map between them. 114 Note that in some cases, it is necessary to define exactly 115 which ASN.1 construct to replace with the content of the 116 MIME object. 118 In this case, conversion can be performed even if 119 "conversion prohibited" is set in the X.400 message. 121 3.2. Text Conversion 123 This type of conversion applies to text objects that 124 cannot be mapped using a simple Byte Copy. Conversion 125 involves scanning and reformatting the object. For 126 example, the MIME and X.400 objects might differ in their 127 encoding of nonstandard characters, or line or page 128 breaks. 130 3.3. Image Conversion 132 This conversion type applies to raster images, like Group 133 3 Facsimile or JPEG. Again, it differs from Byte Copy in 134 that it involves scanning reformatting the byte stream. 135 It differs from Text Conversion in that it is pixel- 136 oriented, rather than character-oriented. 138 In this case, "conversion prohibited" will prohibit the 139 conversion, while "conversion with loss prohibited" will 140 not. 142 draft X.400/MIME body equivalences July 95 144 4. Conversion Table for known X.400 and MIME Types 146 This section itemizes the equivalences for all currently 147 known MIME content-types and X.400 body parts. 149 4.1. MIME to X.400 Table 151 MIME content-type X.400 Body Part Section 152 ----------------- ------------------ ------- 153 text/plain 154 charset=3Dus-ascii ia5-text 7.1 155 charset=3Diso-8859-x EBP - GeneralText 7.2 156 text/richtext no mapping defined MIXER 157 application/oda EBP - ODA 7.4 158 application/octet-stream bilaterally-defined 7.3 159 application/postscript EBP - mime-postscript-body 5.4, 7.6 160 image/g3fax g3-facsimile 6.2, 7.5 161 image/jpeg EBP - mime-jpeg-body 5.5, 7.7 162 image/gif EBP - mime-gif-body 5.6, 7.8 163 audio/basic no mapping defined MIXER 164 video/mpeg no mapping defined MIXER 165 message/rfc822 ForwardedIPMessage MIXER 167 Abbreviation: EBP - Extended Body Part 169 4.2. X.400 to MIME Table 170 Basic Body Parts 172 X.400 Basic Body Part MIME content-type Section 173 --------------------- -------------------- ------- 174 ia5-text text/plain;charset=3Dus-ascii 7.1 175 voice No Mapping Defined MIXER 176 g3-facsimile image/g3fax 6.2, 7.5 177 g4-class1 no mapping defined MIXER 178 teletex no mapping defined MIXER 179 videotex no mapping defined MIXER 180 encrypted no mapping defined MIXER 181 bilaterally-defined application/octet-stream 7.3 182 nationally-defined no mapping defined MIXER 183 externally-defined See Extended Body Parts below 184 ForwardedIPMessage message/rfc822 or multi MIXER 186 X.400 Extended Body Part MIME content-type Section 188 draft X.400/MIME body equivalences July 95 190 ------------------------- -------------------- ------- 191 GeneralText text/plain;charset=3Diso-8859-x 7.2 192 ODA application/oda 7.4 193 mime-postscript-body application/postscript 5.3, 7.6 194 mime-jpeg-body image/jpeg 5.4, 7.7 195 mime-gif-body image/gif 5.5, 7.8 197 draft X.400/MIME body equivalences July 95 199 In all cases where "MIXER" is named in the third column, 200 the fallback conversion described in [MIXER] is applied. 201 This conversion is not a "conversion" as defined in X.400, 202 so will be allowed no matter what is forbidden in the 203 X.400 per message flags. 205 5. Newly defined X.400 Body Parts 207 This section defines new X.400 Body Parts for the purposes 208 of interworking with MIME. 210 All new X.400 Body Parts defined here will be Extended 211 Body Parts, as defined in CCITT Recommendation X.420 212 [X.420]. 214 5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS 216 X.420 dictates that Extended Body Parts shall: 218 (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify 219 the contents, and 221 (2) be defined by using the ASN.1 Macro: 223 EXTENDED-BODY-PART-TYPE MACRO::=3D 224 BEGIN 225 TYPE NOTATION ::=3D Parameters Data 226 VALUE NOTATION ::=3D value (VALUE OBJECT IDENTIFIER) 228 Parameters ::=3D "PARAMETERS" type "IDENTIFIED" 229 "BY" value(OBJECT IDENTIFIER) 230 | empty; 231 Data ::=3D "DATA" type 232 END 234 To meet these requirements, this document uses the OID 236 mime-mhs-bodies 238 defined in [MIXER], as the root OID for X.400 Extended 239 Body Parts defined for MIME interworking. 241 Each Extended Body Part contains Data and optional 243 draft X.400/MIME body equivalences July 95 245 Parameters, each being named by an OID. To this end, two 246 OID subtrees are defined under mime-mhs-bodies, one for 247 Data, and the other for Parameters: 249 mixer-bp-data OBJECT IDENTIFIER ::=3D 250 { mixer-bodies 1 } 252 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 253 { mixer-bodies 2 } 255 All definitions of X.400 body parts submitted to the IANA 256 for registration must use the Extended Body Part Type 257 macro for the definition. See the next section for an 258 example. 260 Lastly, the IANA will use the mixer-bp-data and mixer-bp- 261 parameter OIDs as root OIDs for any new MIME content- 262 type/subtypes that aren't otherwise registered in the 263 Equivalence Table. 265 5.2. The PostScript body part 267 The following Extended Body Part is defined for PostScript 268 data streams. It has no parameters. 270 postscript-body-part EXTENDED-BODY-PART-TYPE 271 DATA OCTET STRING 272 ::=3D mime-postscript-body 274 mime-postscript-body OBJECT IDENTIFIER ::=3D 275 { mixer-bp-data 2 } 277 5.3. The JPEG body part 279 The following Extended Body Part is defined for JPEG data 280 streams. It has no parameters. 282 jpeg-body-part EXTENDED-BODY-PART-TYPE 283 DATA OCTET STRING 284 ::=3D mime-jpeg-body 286 draft X.400/MIME body equivalences July 95 288 mime-jpeg-body OBJECT IDENTIFIER ::=3D 289 { mixer-bp-data 3 } 291 5.4. The GIF body part 293 The following Extended Body Part is defined for GIF data 294 streams. It has no parameters. 296 gif-body-part EXTENDED-BODY-PART-TYPE 297 DATA OCTET STRING 298 ::=3D mime-gif-body 300 mime-gif-body OBJECT IDENTIFIER ::=3D 301 { mixer-bp-data 4 } 303 draft X.400/MIME body equivalences July 95 305 6. Newly defined MIME content-types 307 This section defines new MIME content-types for the 308 purposes of interworking with X.400. 310 6.1. The image/g3fax content-type 312 This content-type is defined to carry G3 Facsimile byte 313 streams. 315 In general, a G3Fax image contains 3 pieces of 316 information: 318 (1) A set of flags indicating the particular coding 319 scheme. CCITT Recommendation T.30 defines how the 320 flags are transmitted over telephones. In this 321 medium, the flags are carried as parameters in the 322 MIME content-type header field. 324 (2) A structure that divides the bits into pages. 325 CCITT recommendation T.4 describes a "return to 326 command mode" string; this is used here to indicate 327 page breaks. 329 (3) For each page, a sequence of bits that form the 330 encoding of the image. CCITT recommendation T.4 331 defines the bit image format. This is used without 332 change. The highest bit of the first byte is the 333 first bit of the T.4 bitstream. 335 6.1.1. G3Fax Parameters 337 The following parameters are defined: 339 (1) page-length - possible values: A4, B4 and Unlimited 341 (2) page-width - possible values: A3, A4, B4 343 (3) encoding - possible values: 1-dimensional, 344 2-dimensional, Uncompressed 346 (4) resolution - possible values: Fine, Coarse 348 draft X.400/MIME body equivalences July 95 350 (5) DCS - a bit string, represented in Base64. 352 (6) pages - an integer, giving the number of pages in 353 the document 355 If nothing is specified, the default parameter settings 356 are: 358 page-length=3DA4 359 page-width=3DA4 360 encoding=3D1-dimensional 361 resolution=3DCoarse 363 It is possible (but misleading) to view the representation 364 of these values as single-bit flags. They correspond to 365 the following bits of the T.30 control string and X.400 366 G3FacsimileParameters: 368 Parameter T.30 bit X.400 bit 370 page-length=3DA4 no bit set 371 page-length=3DB4 19 21 372 page-length=3DUnlimited 20 20 374 page-width=3DA4 no bit set 375 page-width=3DA3 18 22 376 page-width=3DB4 17 23 378 encoding=3D1-dimensional no bit set 379 encoding=3D2-dimensional 16 8 380 encoding=3DUncompressed 26 30 382 resolution=3DCoarse no bit set 383 resolution=3DFine 15 9 385 The reason for the different bit numbers is that X.400 386 counts bits in an octet from the MSB down to the LSB, 387 while T.30 uses the opposite numbering scheme. 389 If any bit but these are set in the Device Control String, 390 the DCS parameter should be supplied. 392 draft X.400/MIME body equivalences July 95 394 6.1.2. Content Encoding 396 X.400 defines the g3-facsimile data stream as a SEQUENCE 397 of BIT STRINGs. Each BIT STRING is a page of facsimile 398 image data, encoded as defined by Recommendation T.4. The 399 following content encoding is reversible between MIME and 400 X.400 and ensures that page breaks are honored in the MIME 401 representation. 403 An EOL is defined as a bit sequence of 405 000000000001 (eleven zeroes and a one). 407 Each page of the message is delimited by a sequence of six 408 (6) EOLs that MUST start on a byte boundary. The image 409 bit stream is padded with zeroes as needed to achieve this 410 alignment. 412 Searching for the boundary is a matter of searching for 413 the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, which 414 cannot occur inside the image. 416 See Section 7.5 for the algorithm on conversion between 417 this encoding and the X.400 encoding. 419 The Base64 content-transfer-encoding is appropriate for 420 carrying this content-type. 422 6.2. The Application/ODA content-type 424 The "ODA" subtype of application is used to indicate that 425 a body contains information encoded according to the 426 Office Document Architecture [ODA] standards, using 427 the ODIF representation format. For application/oda, 428 the Content- Type line should also specify an 429 attribute/value pair that indicates the document 430 application profile (DAP), using the key word "profile", 431 and the document class, using the keyword "class". 433 For the keyword "class", the values "formatted", 434 "processable" and "formatted-processable" are legal 435 values. 437 draft X.400/MIME body equivalences July 95 439 Thus an appropriate header field might look like this: 441 Content-Type: application/oda; profile=3DQ112; 442 class=3Dformatted 444 Consult the ODA standard [ODA] for further information. 446 The Base64 content-transfer-encoding is appropriate for 447 carrying ODA. 449 7. Equivalence Definitions 451 7.1. IA5Text - text/plain 453 X.400 Body Part: IA5Text 454 MIME Content-type: text/plain; charset=3DUS-ASCII 455 Conversion Type: Byte copy 456 Comments: 458 When mapping from X.400 to MIME, the "repertoire" 459 parameter is ignored. 461 When mapping from MIME to X.400, the "repertoire" 462 parameter is set to IA5 (5). 464 NOTE: The MIME Content-type headers are omitted, when 465 mapping from X.400 to MIME, if and only if the IA5Text 466 body part is the only body part in the IPMS.Body sequence. 468 NOTE: IA5Text specifies the "currency" symbol in position 469 2/4. This is converted without comment to the "dollar" 470 symbol, since the author of this document has seen many 471 documents in which the position was intended to indicate 472 "dollar" while he has not yet seen one in which the 473 "currency" symbol is intended. 475 (For reference: The T.50 (1988) recommendation, which 476 defines IA5, talks about ISO registered set number 2, 477 while ASCII, using the "dollar" symbol, is ISO registered 478 set number 6. There are no other differences.) 480 draft X.400/MIME body equivalences July 95 482 7.2. GeneralText - text/plain (ISO-8859) 484 X.400 Body Part: GeneralText; CharacterSets in 485 6,100,101,109,110,126,127,138,144,148 486 MIME Content-Type: text/plain; charset=3DISO-8859-(1-9) 487 Conversion Type: Byte copy 488 Comments: 490 When mapping from X.400 to MIME, the character-set chosen 491 from table below according to the value of 492 Parameters.CharacterSets. 494 When mapping from MIME to X.400, GeneralText is an 495 Extended Body Part, hence it requires an OID. The OID for 496 the GeneralText body is defined in [MOTIS], part 8, annex 497 D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1 498 11 11}. 500 The Parameters.CharacterSets is set from table below 501 according to the value of "charset" 503 NOTE: The GeneralText body part is defined in ISO 10021-8 504 [MOTIS], and NOT in the corresponding CCITT 505 recommendation. Its parameters were heavily modified in a 506 defect report, and will be a SET OF INTEGER (indicating 507 the ISO registry numbers of all the used sets) in the next 508 version of the standard. 510 The following table lists the MIME character sets and the 511 corresponding ISO registry numbers. If no correspondence 512 is found, this conversion fails, and the generic body part 513 approach is used. 515 MIME charset ISO IR numbers Comment 516 ----------------------------------------------- 517 ISO-8859-1 6, 100 West European "8-bit ASCII" 518 ISO-8859-2 6, 101 East European 519 ISO-8859-3 6, 109 520 ISO-8859-4 6, 110 521 ISO-8859-5 6, 144 Cyrillic 522 ISO-8859-6 6, 127 Arabic 523 ISO-8859-7 6, 126 Greek 524 ISO-8859-8 6, 138 Hebrew 525 ISO-8859-9 6, 148 Other Latin-using languages 527 draft X.400/MIME body equivalences July 95 529 When converting from MIME to X.400, generate the correct 530 OIDs for use in the message envelope's Encoded Information 531 Types by looking up the ISO IR number in the above table, 532 and then appending it to the id-cs-eit-authority {1 0 533 10021 7 1 0} OID. 535 The escape sequences to designate and invoke the relevant 536 character sets in their proper positions must be added to 537 the front of the GeneralText character string. 539 7.3. BilaterallyDefined - application/octet-stream 541 X.400 Body Part: BilaterallyDefined 542 MIME Content-Type: Application/Octet-Stream (no parameters) 543 Conversion Type: Byte copy 544 Comments: 546 When mapping from MIME to X.400, if there are parameters 547 present in the Content-Type: header field, the conversion 548 fails since the BilaterallyDefined Body Part does not have 549 any corresponding ASN.1 parameters. 551 DISCUSSION: The parameters "name" "type" and "conversions" 552 are advisory, but may in some cases give vital hints on 553 the expected handling of the file. The parameter 554 "conversions" is not fully defined, but it is expected 555 that it will be useful, so we cannot drop it and expect 556 people to be satisfied. 558 The parameter "padding" changes the interpretation of the 559 last byte of the data, and so cannot be deleted. 561 An option is to prepend an IA5 body part that contains the 562 parameter text; this will aid unmodified readers, and can 563 probably be made reversible with suitable chicanery, but 564 is it worth it???? 566 Also, use of BilaterallyDefined Body Parts is specifically 567 deprecated in both 1988 and 1992 X.400. It is retained 568 solely for backward compatibility with 1984 systems. 1992 569 X.400 defines a File Transfer Body Part to solve this 570 problem (i.e. binary file transfer through email). The 571 standard and its regional profiles are not solid enough 572 yet to exploit as a solution for this problem. 574 draft X.400/MIME body equivalences July 95 576 7.4. ODA - application/oda 578 X.400 Body Part: ODA 579 MIME Content-Type: application/oda 580 Conversion Type: Byte copy 581 Comments: 583 The ODA body part is defined in the CCITT document T.411 584 [T.411], appendix E, section E.2, "ODA identification in 585 the P2 protocol of MHS" 587 An abbreviated version of its ASN.1 definition is: 589 oda-body-part EXTENDED-BODY-PART-TYPE 590 PARAMETERS OdaBodyPartParameters 591 DATA OdaData 592 ::=3D id-et-oda 594 OdaBodyPartParameters ::=3D SET { 595 document-application-profile [0] OBJECT IDENTIFIER 596 document-architecture-class [1] INTEGER { 597 formatted (0) 598 processable (1) 599 formatted-processable(2)}} 601 id-et-oda OBJECT IDENTIFIER ::=3D { 2 8 1 0 1 } 603 Mapping from X.400 to MIME, the following is done: 605 The Parameters.document-application-profile is mapped onto 606 the MIME parameter "profile" according to the table below. 608 Profile OBJECT IDENTIFIER 610 Q112 { iso (1) identified-organization (3) ewos (16) 611 eg (2) oda (6) profile (0) q112 (1) } 613 The Parameters.document-architecture-class is mapped onto 614 the MIME parameter "class" according to the table below 616 String Integer 618 formatted formatted(0) 619 processable processable(1) 621 draft X.400/MIME body equivalences July 95 623 formatted-processable formatted-processable(2) 625 NOTE: This parameter is not defined in RFC 1341. 627 The body of the MIME content-type is the Data part of the 628 ODA body part. 630 When mapping from MIME to X.400, the following steps are 631 done: 633 The Parameters.document-application-profile and 634 Parameters.document-architecture-class are set from the 635 tables above. If any of the parameters are missing, the 636 values for Q112 and formatted-processable are used. 638 It is an option for the gateway implementor to try to 639 access them from inside the document, where they are 640 defined as 642 document-profile.document-characteristics.document-architecture-class 644 document-profile.document-characteristics.document-application-profil= 645 e 647 Gateways are NOT required to do this, since the document- 648 characteristics are optional parameters. If a gateway 649 does not, it simply uses the defaulting rules defined 650 above. 652 The OBJECT IDENTIFIERs for the document application 653 profile and for ODA {2 8 0 0} must be added to the Encoded 654 Information Types parameter of the message envelope. 656 7.5. g3-facsimile - image/g3fax 658 X.400 Body part: g3-facsimile 659 MIME Content-Type: image/g3fax 660 Conversion Type: nearly Byte copy 661 Comments: 663 The Parameters of the X.400 G3Fax body part are mapped to 664 the corresponding Parameters on the MIME Image/G3Fax body 665 part and vice versa. Note that: 667 draft X.400/MIME body equivalences July 95 669 (1) If fineResolution is not specified, pixels will be 670 twice as tall as they are wide 672 (2) If any bit not corresponding to a specially named 673 option is set in the G3Fax NonBasicParameters, the 674 "DCS" parameter must be used. 676 (3) Interworking is not guaranteed if any bit apart 677 from those specially named are used in the 678 NonBasicParameters 680 From X.400 to G3Fax, the body is created in the following 681 way: 683 (1) Any trailing EOL markers on each bitstring is 684 removed. The bit order is changed to conform to the 685 most common Internet encoding (highest bit of first 686 byte =3D first bit of the G3Fax). The bitstring is 687 padded to a byte boundary. 689 (2) 6 consecutive EOL markers are appended to each 690 bitstring. 692 (3) The padded bitstrings are concatenated together 694 An EOL marker is the bit sequence 000000000001 (11 zeroes 695 and a one). 697 From G3Fax to X.400, the body is created in the following 698 way: 700 (1) The body is split into bitstrings at each 701 occurrence of 6 consecutive EOL markers. Trailing 702 EOLs must NOT be removed, since the X.400 703 Implementor Guide recommends that each page should 704 end with 6 consecutive EOLs. (This is a change 705 from RFC 1494). 707 (2) Each bitstring is made into an ASN.1 BITSTRING, 708 reversing the order of bits within each byte to 709 conforom to the X.400 Implementors Guide 710 recommendation for bit order in the G3Fax body 711 part. 713 draft X.400/MIME body equivalences July 95 715 (3) The bitstrings are made into an ASN.1 SEQUENCE, 716 which forms the body of the G3Fax body part. 718 7.6. Teletex - Text/Plain (Teletex) 719 X.400 Body Part: Teletex 720 MIME Content-Type: text/plain; charset=3DTeletex 721 Conversion Type: Text conversion 722 Comments: 724 The Teletex body part is frequently used in X.400(84) to 725 send around text with slightly extended character sets 726 beyond ASCII. 728 Its body consists of a series of "pages", separated by 729 ASN.1 representation. It is important to many people to 730 have this mapped into something that is readable to most 731 end-users; therefore, it is recommended to map this onto 732 Text/Plain; however, since this is not plain text, the 733 conversion must be specified. 735 From X.400 to RFC-822, the conversion shall take the bytes 736 of all the pages in the "data" part of the 737 TeletexBodyPart, add a FF character (0x0C, control-L) to 738 each part that does not already end in one, and 739 concatenate them together to form the body of the 740 Text/Plain. 742 The character set shall be "Teletex", which is especially 743 registered for this purpose. Its definition is shown in an 744 appendix. 746 The parameters are discarded. 748 From RFC-822 to X.400, the conversion shall split the 749 content at each occurence of the FF character (0x0C), 750 delete the character and construct the Teletex body part 751 as a SEQUENCE OF TeletexString, as described in X.420(88), 752 section 7.3.5 754 The TeletexParameters may, but need not, contain the 755 number-of-pages component. 757 NOTE: It is recommended, but not mandated, that the data 758 be converted into a more widespread character set like 760 draft X.400/MIME body equivalences July 95 762 ISO-8859-1 or ISO-2022-JP (if applicable) if possible. 763 This will result in the reverse translation giving a 764 GeneralText body part, which will have to be dealt with 765 appropriately at the X.400/88 to X.400/84 downgrading 766 boundary, if possible, but will give a much greater chance 767 that the MIME recipient can actually read the message. 769 7.7. application/postscript - postscript-body-part 771 X.400 Body Part: Extended Body Part, OID postscript-body-part 772 MIME Content-Type: application/postscript 773 Conversion Type: Byte Copy 775 7.8. image/jpeg - jpeg-body-part 777 X.400 Body Part: Extended Body Part, OID jpeg-body-part 778 MIME Content-Type: image/jpeg 779 Conversion Type: Byte Copy 781 7.9. image/gif - gif-body-part 783 X.400 Body Part: Extended Body Part, OID gif-body-part 784 MIME Content-Type: image/gif 785 Conversion Type: Byte Copy 787 draft X.400/MIME body equivalences July 95 789 8. OID Assignments 790 MIXER-MAPPINGS DEFINITIONS ::=3D BEGIN 791 EXPORTS -- everything --; 793 IMPORTS 794 experimental 795 FROM RFC1155-SMI; 796 mixer 797 FROM MIXER --Companion RFC--; 799 mixer-bp-data OBJECT IDENTIFIER ::=3D 800 { mixer-bodies 1}; 802 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 803 { mixer-bodies 2}; 805 mime-generic-data OBJECT IDENTIFIER ::=3D 806 { mixer-bp-data 1}; 808 mime-generic-parameters OBJECT IDENTIFIER ::=3D 809 { mixer-bp-parameter 1}; 811 mime-postscript-body OBJECT IDENTIFIER ::=3D 812 { mixer-bp-data 2}; 814 mime-jpeg-body OBJECT IDENTIFIER ::=3D 815 { mixer-bp-data 3}; 817 mime-gif-body OBJECT IDENTIFIER ::=3D 818 { mixer-bp-data 4}; 820 draft X.400/MIME body equivalences July 95 822 9. Registration information for the Teletex character 823 set 825 The Teletex character set is a character set in which the 826 ISO 2022 character set switching mechanism may be used to 827 switch between the following registered ISO character 828 sets: 830 ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set 831 ISO-IR-102 - a fairly standard US-ASCII variant 832 ISO-IR-103 - Latin characters using nonspacing accents 833 ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more. 834 ISO-IR-107 - Control characters for C1 use 836 Its intended use of this character set is to represent 837 data that comes from ISO protocols that use the ASN.1 838 construct "TeletexString" or "T61string" without 839 conversion. 841 The set of allowed character sets can be found in CCITT 842 recommendation X.208(1988), chapter 31.2 and Table 843 6/X.208. 845 The rules for encoding the datatype can be found in CCITT 846 recommendation X.209(1988), chapter 23. It states that at 847 the beginning of the string, G0 is always ISO-IR-102, C0 848 is ISO-IR-106, and C1 is ISO-IR-107. 850 The specification seems somehow to have missed the 851 implicit assumption that ISO-IR-103 is designated and 852 invoked as G1 and shifted into the upper half of the 853 character set which seems to be assumed at least by the 854 X.400 and X.500 software that uses TeletexStrings; 855 implementors should act as if the sequence ESC 2/9 7/6 856 LS1R is always present at the beginning of the data. 858 The rules for interpreting T.61 data are found (I believe) 859 in CCITT recommendations T.51, T.52 and T.53 (data from 860 the ITU WWW server): 862 T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93] 863 Latin based coded character sets for telematic services 864 T.52 (1993) [New] [88 pp.] [Publ.: Apr.94] 865 Non-latin coded character sets for telematic services 866 T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95] 868 draft X.400/MIME body equivalences July 95 870 Character coded control functions for telematic services 871 Note - C: 26/48/69 873 (The author has not yet obtained a copy of these, even 874 though they only cost SFR 70 from the ITU...) 876 The Teletex character set is closely related to (but not 877 identical with) that specified in ISO 6937. 879 No further restrictions are imposed by this registration; 880 in particular, character set switching can occur anywhere, 881 and there is no guarantee that the character sets will be 882 switched "back" at the end. 884 10. IANA Registration form for new mappings 886 To: IANA@isi.edu 887 Subject: Registration of new X.400/MIME content type mapping 889 MIME type name: 891 (this must have been registered previously with IANA) 893 X.400 body part: 895 X.400 Object Identifier for Data: 897 (If left empty, an OID will be assigned by IANA under 898 mixer-bp-data) 900 X.400 Object Identifier for Parameters: 902 (If left empty, an OID will be assigned by IANA under 903 mixer-bp-parameter. If it is not used, fill in the words 904 NOT USED.) 906 X.400 ASN.1 Syntax: 908 (must be an EXTENDED-BODY-PART-TYPE macro, or reference to 909 a Basic body part type) 911 Conversion algorithm: 913 (must be defined completely enough for independent 915 draft X.400/MIME body equivalences July 95 917 implementation. It may be defined by reference to RFCs). 919 Person & email address to contact for further information: 921 INFORMATION TO THE SUBMITTER: 923 The accepted registrations will be listed in the "Assigned 924 Numbers" series of RFCs. The information in the 925 registration form is freely distributable. 927 11. Changes from RFC 1494 929 The following changes have been made since the publication 930 of RFC 1494: 932 (1) The Teletex body part mapping was added 934 (2) The G3Fax body part had the order of bits in its 935 body defined. It turned out that 2 implementations 936 had done this in opposite directions. 938 12. References 940 [RFC-822] 941 D.H. Crocker, Standard for the Format of ARPA 942 Internet Text Messages. Request for Comments 822, 943 (August, 1982). 945 [MIME] 946 N. Borenstein, N. Freed, MIME: Mechanisms for 947 Specifying and Describing the Format of Internet 948 Message Bodies. Request for Comments 1341, (June, 949 1992). 951 [MIXER] 952 S.E. Hardcastle-Kille, Mapping between X.400(1988) / 953 ISO 10021 and RFC-822. (in preparation) 955 [T.4] 956 CCITT Recommendation T.4, Standardization of Group 3 957 Facsimile Apparatus for Document Transmission (1988) 959 [T.30] 960 CCITT Recommendation T.30, Procedures For Document 962 draft X.400/MIME body equivalences July 95 964 Facsimile Transmission in the General Switched 965 Telephone Network (1988) 967 [T.411] 968 CCITT Recommendation T.411 (1988), Open Document 969 Architecture (ODA) and Interchange Format, 970 Introduction and General Principles 972 [MOTIS] 973 ISO/IEC International Standard 10021, Information 974 technology - Text Communication - Message-Oriented 975 Text Interchange Systems (MOTIS) (Parts 1 to 8) 977 [X.400] 978 CCITT, Data Communication Networks - Message Handling 979 Systems - Recommendations X.400 - X.420 (1988 980 version) 982 [X.420] 983 CCITT Recommendation X.420 (1988), Interpersonal 984 Messaging System 986 [RFC-X400USE] 987 Harald Tveit Alvestrand, X.400 use of extended 988 Character Sets, Internet Draft, June 1992 990 draft X.400/MIME body equivalences July 95 992 Table of Contents 994 Status of this Memo ................................ 1 995 1 Introduction ...................................... 3 996 2 Equivalence Table Definition ...................... 4 997 3 Generic conversions ............................... 5 998 3.1 Byte copy ....................................... 5 999 3.2 Text Conversion ................................. 5 1000 3.3 Image Conversion ................................ 5 1001 4 Conversion Table for known X.400 and MIME Types 1002 ................................................ 6 1003 4.1 MIME to X.400 Table ............................. 6 1004 4.2 X.400 to MIME Table ............................. 6 1005 5 Newly defined X.400 Body Parts .................... 8 1006 5.1 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 8 1007 5.2 The PostScript body part ........................ 9 1008 5.3 The JPEG body part .............................. 9 1009 5.4 The GIF body part ............................... 10 1010 6 Newly defined MIME content-types .................. 11 1011 6.1 The image/g3fax content-type .................... 11 1012 6.1.1 G3Fax Parameters .............................. 11 1013 6.1.2 Content Encoding .............................. 13 1014 6.2 The Application/ODA content-type ................ 13 1015 7 Equivalence Definitions ........................... 14 1016 7.1 IA5Text - text/plain ............................ 14 1017 7.2 GeneralText - text/plain (ISO-8859) ............. 15 1018 7.3 BilaterallyDefined - application/octet-stream 1019 ................................................ 16 1020 7.4 ODA - application/oda ........................... 17 1021 7.5 g3-facsimile - image/g3fax ...................... 18 1022 7.6 Teletex - Text/Plain (Teletex) .................. 20 1023 7.7 application/postscript - postscript-body-part 1024 ................................................ 21 1025 7.8 image/jpeg - jpeg-body-part ..................... 21 1026 7.9 image/gif - gif-body-part ....................... 21 1027 8 OID Assignments ................................... 22 1028 9 Registration information for the Teletex charac=AD 1029 ter set ........................................ 23 1030 10 IANA Registration form for new mappings .......... 24 1031 11 Changes from RFC 1494 ............................ 25 1032 12 References ....................................... 25