idnits 2.17.1 draft-ietf-mixer-bodymap-03.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-03.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mixer-bodymap-03.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mixer-bodymap-03.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-03.txt.', but the file name used is 'draft-ietf-mixer-bodymap-03' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 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 9 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 143: '...e, but a conformant MIXER gateway MUST...' RFC 2119 keyword, line 400: '... A gateway MAY choose to support th...' RFC 2119 keyword, line 401: '... available, but MUST support this lim...' RFC 2119 keyword, line 567: '... implementations MUST place the MIME-v...' RFC 2119 keyword, line 569: '...s of the message MUST NOT be placed in...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 908 has weird spacing: '...-stream bila...' == Line 929 has weird spacing: '...teletex n.n...' == Line 932 has weird spacing: '...-stream n.n...' == Line 1298 has weird spacing: '...mapping is re...' == Line 1327 has weird spacing: '...part is mappe...' == (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? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1625 looks like a reference -- Missing reference section? '28' on line 223 looks like a reference -- Missing reference section? 'RFC 1806' on line 301 looks like a reference -- Missing reference section? 'MAWG' on line 1664 looks like a reference -- Missing reference section? '9' on line 489 looks like a reference -- Missing reference section? '0' on line 1019 looks like a reference -- Missing reference section? '1' on line 1020 looks like a reference -- Missing reference section? '2' on line 1021 looks like a reference -- Missing reference section? 'POSTSCRIPT' on line 941 looks like a reference -- Missing reference section? 'IMAGES' on line 946 looks like a reference -- Missing reference section? 'ODA' on line 940 looks like a reference -- Missing reference section? 'UNIVERSAL 8' on line 1014 looks like a reference -- Missing reference section? 'UNIVERSAL 7' on line 1023 looks like a reference -- Missing reference section? 'MOTIS' on line 1643 looks like a reference -- Missing reference section? 'RFC-822' on line 1614 looks like a reference -- Missing reference section? 'MIME' on line 1619 looks like a reference -- Missing reference section? 'RFC-X400USE' on line 1660 looks like a reference -- Missing reference section? '100' on line 1715 looks like a reference -- Missing reference section? 'New' on line 1875 looks like a reference Summary: 16 errors (**), 1 flaw (~~), 10 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft X.400/MIME body equivalences July 95 3 Equivalences between X.400 and RFC-822 Message Bodies 5 Wed Oct 11 15:27:45 MET 1995 7 Harald Tveit Alvestrand 8 UNINETT 9 Harald.T.Alvestrand@uninett.no 11 Status of this Memo 13 The name of this draft is draft-ietf-mixer-bodymap-03.txt. 15 The following text is required for all drafts: 17 This document is an Internet Draft. Internet Drafts 18 are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. 20 Note that other groups may also distribute working 21 documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a 24 maximum of six months. Internet Drafts may be 25 updated, replaced, or obsoleted by other documents at 26 any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other 28 than as a "working draft" or "work in progress." 30 Please check the I-D abstract listing contained in 31 each Internet Draft directory to learn the current 32 status of this or any other Internet Draft. 34 This document is an update to RFC 1494, and will obsolete 35 it once it is ready for publication. 37 Please send comments to the MIXER mailing list: 38 40 draft X.400/MIME body equivalences July 95 42 1. Introduction 44 This document is a companion to [MIXER], which defines the 45 principles and translation of headers for interworking 46 between MIME-based RFC-822 mail and X.400 mail. 48 This document defines how to map body parts of X.400 49 messages into MIME entities and vice versa, including the 50 handling of multipart messages and forwarded messages. 52 draft X.400/MIME body equivalences July 95 54 1.1. Glossary 56 The following terms are defined in this document: 58 Body part 59 Part of a message that has an unique type. This term 60 comes from X.400; the corresponding term in MIME (RFC 61 1521) is limited to use in parts of a multipart 62 message; the term "body" may correspond better. 64 Content-type 65 Type information indicating what the content of a 66 body part actually is. This term comes from MIME; the 67 corresponding X.400 term is "body part type". 69 Mapping 70 (noun): A description of how to transform an X.400 71 body part into a MIME body part, or how to transform 72 a MIME body part into an X.400 body part. 74 Equivalence 75 A set of two mappings that taken together provide a 76 lossless conversion between an X.400 body part and a 77 MIME body part 79 0 The process of encapsulating something from one of 80 the mail systems in such a way that it can be carried 81 inside the other mail system. When tunneling, it is 82 not expected that the other mail system can make 83 reasonable sense of the body part, but a gateway back 84 into the first system will always be able to convert 85 the body part without loss back to its original 86 format. 88 HARPOON mapping 89 The mapping of a MIME body part by putting it inside 90 an IA5 body with all headers and encoding intact. 91 First described in RFC 1496. 93 2. Basic rules for body part conversion 95 At the moment (Sept 1995) both the MIME and the X.400 96 worlds are in a state of flux with regards to carrying 97 stuff that is not text around. 98 In such a situation, there is little chance of defining a 100 draft X.400/MIME body equivalences July 95 102 mapping between them that is the best for all people, all 103 of the time. 104 For this reason, this specification allows a gateway 105 considerable latitude in deciding exactly what conversion 106 to apply. 108 The decision taken by the gateway may be based on various 109 information sources: 111 (1) If the gateway knows what body parts or content 112 types the recipient is able to handle, or has 113 registered a particular set of preferences for an 114 user, and knows how to convert the message 115 reasonably to those body parts, the gateway may 116 choose to convert body parts in the message to 117 those types only. 119 (2) If the gateway gets indications (via special 120 headers or heading-extensions defined for the 121 purpose) that the sender wanted a particular 122 representation on the "other side", and the gateway 123 is able to satisfy the request, it may do so. Such 124 a mechanism is defined in chapter 4 of this 125 document. 127 (3) If the gateway gets a message with bad typing 128 information (like an X.400 BP14 or FTAM "just a 129 file", it may apply heuristics like looking at 130 content or looking at filenames to figure out how 131 to deal with the message. 133 (4) If the gateway knows that the next hop for the 134 message has limited capabilities (like X.400/84), 135 it may choose to perform conversions appropriate 136 for that medium. 138 (5) Where no mapping is known by the gateway, it may 139 choose to drop the body part, reject the message, 140 or encapsulate the body part in a mechanism which 141 can be used for any extended body part (tunneling), 142 as described in chapter 3. The choice may be 143 configurable, but a conformant MIXER gateway MUST 144 be able to be configured for tunneling. 146 draft X.400/MIME body equivalences July 95 148 In many cases, a message that goes SMTP->X.400->SMTP will 149 arrive without loss of information. 150 In some cases, the reverse translation may not be 151 possible, or two gateways may choose to apply different 152 translations, based on the criteria above, leading to an 153 apparently inconsistent service. 154 In addition, service will vary because some gateways will 155 have implemented conversions not implemented by other 156 gateways. 157 This is believed to be unavoidable. 159 The conformance requirements in chapter 7 describe what 160 the minimum conformance for a MIXER gateway is with 161 respect to body part conversion. 163 2.1. Generating the IPM Body from MIME 165 If the header does not contain a 822.MIME-Version field, 166 then generate a IPMS.Body with a single IPMS.BodyPart of 167 type IPMS.IA5TextBodyPart with 168 IPMS.IA5TextBodyPart.parameters.repertoire set to the 169 default (IA5) containing the body of the RFC 822 message. 171 If 822.MIME-Version is present, the body is analyzed as a 172 MIME message and the body is converted according to the 173 mappings configured and implemented in the gateway. 175 2.2. Ground rules for generating the MIME Body from the 176 IPMS.Body 178 First, to support X.400(1984) mappings of Internet 179 Messages, the following procedure shall be followed. 181 If there is more than one body part, and the first body 182 part is IA5 starts with the string "RFC-822-Headers:" as 183 the first line, then the remainder of this body part shall 184 be appended to the RFC 822 header. This relies upon the 185 theory that this body part has been generated according to 186 Appendix B of MIXER. A gateway shall check the 187 consistency and syntax of this body part, to ensure that 188 the resulting message is conformant with RFC 822. 190 draft X.400/MIME body equivalences July 95 192 If the remaining IPMS.Body consists of a single 193 IPMS.Bodypart, there are three possibilities. 195 (1) If it is of type IPMS.IA5Text, and the first line 196 is "MIME-Version: 1.0", it is assumed to be a 197 HARPOON-mapped message. The complete body content 198 is then appended to the headers; the separating 199 blank line is inside the message. If an RFC 822 200 syntax error is discovered inside the message, it 201 may be mapped directly as described below instead. 203 (2) If it is of type IPMS.IA5Text, then this is mapped 204 directly and no MIME encoding is used. 206 (3) All other parts are mapped according to the 207 mappings configured and implemented in the gateway. 209 If the IPMS.Body contains multiple IPMS.Bodypart fields, 210 then a MIME message of content type multipart is 211 generated. If all of the body parts are messages, then 212 this is multipart/digest. Otherwise it is 213 multipart/mixed. The components of the multipart are 214 generated in the same order as in the IPMS.Body. 216 Each component is mapped according to the mappings 217 configured and implemented in the gateway; any IA5 body 218 parts are checked to see if they are HARPOON mappings. 220 2.3. Mapping the EMA FTBP parameters 222 EMA has defined a profile for use of the File Transfer 223 Body Part (FTBP). [28] 225 New mappings are expected to use this as the mechanism for 226 carrying body parts, and since it is important to have a 227 consistent mapping for the special FTBP parameters, these 228 are defined here. 230 The mapping of the body will depend on the content-type in 232 draft X.400/MIME body equivalences July 95 234 MIME and on the application-reference in FTBP, and is not 235 specified here. 237 The following new RFC-822 headers are defined to support 238 this mapping: 240 ftbp-field =3D "FTBP-Object-Size" ":" integer 241 / "FTBP-Creation-Date" ":" date-time 242 / "FTBP-Modification-Date" ":" date-time 243 "FTBP-Read-Date" ":" date-time 245 Some parameters of the EMA Profile are encoded as ASN.1 246 GraphicStrings, which are troublesome because they can 247 contain any ISO registered graphic character set. 248 To map these to ASCII for use in mail headers, the gateway 249 may either: 251 (1) Use the RFC 1522 encoding mechanism to create 252 appropriate encoded-words for the headers involved. 253 Note that in some cases, such as within Content- 254 Disposition filenames, the encoded-words must be in 255 quotes, which is not the normal usage of encoded- 256 words. 258 (2) Apply the normalization procedure given in Appendix 259 to identify the ASCII characters of the string, 260 and replace all non-ASCII characters with the 261 question mark (?). 263 Both procedures are valid for MIXER gateways; the 264 simplified procedure of ignoring escape sequences and bit- 265 stripping the result is NOT valid. 267 The following parameters are mapped in both directions: 269 Content-ID: 270 The mapping of this element is complex. 272 The Content-ID is encoded as an IPM.MessageIdentifier 273 and entered into the 274 FTBP.FileTransferParameters.related-stored-file. 275 file-identifier.cross-reference.message-reference. 277 FTBP.FileTransferParameters.related-stored-file. 279 draft X.400/MIME body equivalences July 95 281 relationship.descriptive-relationship is set to the 282 string "Internet MIME Body Part". 284 FTBP.FileTransferParameters.related-stored-file. 285 file-identifier.cross-reference.application- 286 crossreference is set to a null OCTET STRING. 288 The reverse mapping is only performed if the 289 FTBP.FileTransferParameters.related-stored-file. 290 relationship.descriptive-relationship has the string 291 value "Internet MIME Body Part". 293 Content-Description 295 This is mapped to and from the first string in 296 FTBP.FileTransferParameters.environment.user-visible- 297 string. 299 Content-Disposition 301 This field is defined in [RFC 1806]. 303 It is mapped to and from FileTransferParameters.file- 304 attributes.pathname. 306 The EBNF.disposition-type is ignored when creating 307 the FTBP pathname, and always set to "attachment" 308 when creating the Content-Disposition header. For 309 example: 311 Content-Disposition: attachment; filename=3D/var/joe= 312 /dodo.doc 314 If the filename starts with a leading "/" character, 315 it generates an FTBP complete-pathname. If it starts 316 with any other character, it generates an FTBP 317 incomplete-pathname. 319 It is expected that only the incomplete option will 320 be found, but the mapping is used for either variant. 321 The separator between multiple components is "/". 323 draft X.400/MIME body equivalences July 95 325 FTBP-Creation-Date: 327 Mapped to and from FileTransferParameters.file- 328 attributes.date-and-time-of-creation 330 FTBP-Modification-Date: 332 Mapped to and from FileTransferParameters.file- 333 attributes.date-and-time-of-last-modification 335 FTBP-Read-Date: 337 Mapped to and from FileTransferParameters.file- 338 attributes.date-and-time-of-last-read-access 340 FTBP-Object-Size: 342 Mapped to and from FileTransferParameters.file- 343 attributes.object-size. If the value is "no-value- 344 available", the header is NOT generated. 346 Other RFC-822 headers 348 Mapped to the second and subsequent elements of 349 FTBP.FileTransferParameters.environment.user-visible- 350 string. Headers are unfolded so that each header fits 351 within one user-visible-string component 352 (GraphicString does not allow CRLFs within the 353 string) 355 If no content-disposition header is present, the 356 first element is set to an empty string. 358 On reverse mapping, all headers that conform to the 359 RFC 822 grammar are mapped to headers in the 360 bodypart. 362 Editor's note 363 This is new. I think it is a simple thing to do, does 365 draft X.400/MIME body equivalences July 95 367 not cause damage, and preserves information. 368 Comments? 370 2.3.1. Summary of FTBP elements generated 372 This is a summary of the preceding section, and does not 373 add new information. 375 The following elements of the FTBP parameters are mapped 376 or used: 377 FileTransferParameters M/M 378 Related-Stored-File O/O 379 file-identifier 380 cross-reference 381 application-crossreference NULL 382 message-reference Content-ID 383 descriptive-relationship Used as marker 384 contents-type Must be unstructured-binary M/M 385 environment M/M 386 application-reference Selects mapping M/M 387 user-visible-string Content-description R/M 388 file-attributes 389 pathname Content-Disposition R/M 390 date-and-time-of-creation FTBP-Creation-Date O/O 391 date-and-time-of-last-modification FTBP-Modification-Date = 392 R/M 393 date-and-time-of-last-read-access FTBP-Read-Date O/O 394 object-size FTBP-Object-Size R/M 396 All other elements of the FTBP parameters are discarded. 398 NOTE: There is ongoing work on defining a more complete 399 mapping between FTBP headers and a set of RFC-822 headers. 400 A gateway MAY choose to support the larger set once it is 401 available, but MUST support this limited set. 403 2.4. Information that is lost when mapping 405 MIME defines fields which add information to MIME 406 contents. Two of these are "Content-ID", and "Content- 407 Description", but MIME allows new entities to be defined 408 at any time. 410 draft X.400/MIME body equivalences July 95 412 When mapping, this information must be discarded, unless 413 the specific body part 15 mapping allows it to be 414 retained. 416 3. Encapsulation of body parts 418 Where no mapping is possible, the gateway may choose any 419 of the following alternatives: 421 Discard the body part, leaving a "marker" saying what 422 happened 424 Reject the message 426 "Tunnel" the body part, by encapsulating it in a body 427 part defined for that purpose in the other mail 428 system 430 The choice to be made should be configurable in the 431 gateway, and may depend on both policy and knowledge of 432 the recipient's capabilities. 434 3.1. Encapsulation of MIME in X.400 436 Two body parts are defined here to tunnel MIME body parts 437 through X.400, one based on BP15 directly and the other 438 based on FTBP. 440 The BP15 body part is backwards compatible with RFC 1494. 441 The FTBP body part is compatible with the EMA MAWG 442 document [MAWG]. 444 3.1.1. BP15 tunneling body part 446 This section defines an extended body part, based on body 447 part 15, which may be used to hold any MIME content. 449 mime-body-part EXTENDED-BODY-PART-TYPE 450 PARAMETERS MimeParameters 451 IDENTIFIED BY id-mime-body-part-parameters 452 DATA OCTET STRING 453 ::=3D id-mime-body-part 455 draft X.400/MIME body equivalences July 95 457 MimeParameters ::=3D 458 SEQUENCE { 459 content-type IA5String, 460 content-parameters SEQUENCE OF 461 SEQUENCE { 462 parameter IA5String, 463 parameter-value IA5String 464 } 465 other-header-fields RFC822FieldList 466 } 468 The OBJECT IDENTIFIERS id-mime-body-part and id-mime-body- 469 part-parameters are defined in Appendix D. A MIME content 470 is mapped onto this body part. The MIME headers of the 471 body part are mapped as follows: 473 Content-Type: 474 The "type/subtype" string is mapped to 475 MimeParameters.content-type. 477 For each "parameter=3Dvalue" string create a 478 MimeParameters.content-parameters element. The 479 MimeParameters.content-Parameters.parameter field is 480 set to the parameter and the MimeParameters.content- 481 parameters.parameter-value field is set to the value. 483 Other 484 Take all other headers and create 485 MimeParameters.other-header-fields, by concatenating 486 them together. 488 Convert the MIME body part into its canonical form, as 489 specified in Appendix H of MIME [9]. This canonical form 490 is used to generate the mime-body-part.data octet string. 492 The Parameter mapping may be used independently of 493 the body part mapping (e.g., in order to use a different 494 encoding for a mapped MIME body part). 496 This body part contains all of the MIME information, 497 and so can be mapped back to MIME without loss of 498 information. 500 draft X.400/MIME body equivalences July 95 502 The OID id-mime-body-part is added to the Encoded 503 Information Types of the envelope. 505 This body part is completely compatible with RFC 1494. 507 3.1.2. FTBP tunneling body part 509 This body part utilizes the fundamental assumption in MIME 510 that all message content can be legally and completely 511 represented by a single octet stream, the "canonical 512 format". 514 The FTBP tunneling body part is defined by the 515 application-reference id-mime-ftbp-body; all headers are 516 mapped to the FTBP headers, including putting the 517 "Content-type:" header inside the UserVisibleString. 519 Translation from the MIME body part is done by: 521 Undoing the content-transfer-encoding 523 Setting the "FileTransferData.FTdata.value.octet- 524 aligned" to the resulting string of octets 526 Putting the appropriate parameters into the headers. 528 Reversing the translation is done by: 530 Extracting the headers 532 Applying an appropriate content-transfer-encoding to 533 the body. If this is for some reason different from 534 the content-transfer-encoding: header retrieved from 535 the headers, the old one must be deleted. 537 This mapping is lossless, and therefore counts as "no 538 conversion". 540 3.1.3. Tunneling using IA5 542 This approach is the one taken in RFC 1496 - HARPOON - for 543 tunneling any MIME body part through X.400/84 networks. It 545 draft X.400/MIME body equivalences July 95 547 has proven rather unhelpful for bringing information to 548 X.400 users, but preserves all the information of a MIME 549 body part. 551 The following IA5Text body part is made: 553 - Content =3D IA5String 555 - First bytes of content: (the description is in US 556 ASCII, with C escape sequences used to represent 557 control characters): 559 MIME-version: \r\n 560 Content-type: \r\n 561 Content-transfer-encoding: \r\n 562 563 \r\n 564 567 All implementations MUST place the MIME-version: header 568 first in the body part. Headers that are placed by [MIXER] 569 into other parts of the message MUST NOT be placed in the 570 MIME body part. 572 3.1.4. Tunneling using BP14 574 This is described in this section because it is at the 575 same conceptual level as tunneling. It is a lossy 576 transformation; it is impossible to reconstruct the MIME 577 type information from it. 579 Nevertheless, there is a demand for such functionality. 581 This tunneling simply strips off all headers, undoes the 582 content-transfer-encoding, and creates a 583 BilaterallyDefined body part (BP14) from the resulting 584 octet stream. 586 draft X.400/MIME body equivalences July 95 588 3.2. Tunneling X.400 Body Parts in MIME 590 This section specifies a generic mechanism to map X.400 591 body parts to a MIME content. This allows for the body 592 part to be tunneled through MIME. It may also be used 593 directly by an appropriately configured MIME UA. 595 This content-type is defined to carry any X.400 596 extended body part. The mapping of all standard X.400 597 body parts is defined in RFC1494bis. The content-type 598 field is "application/x400-bp". The parameter is defined 599 by the EBNF: 601 mime-parameter =3D "bp-type=3D" object-identifier 603 The EBNF.object-identifier is set to the OBJECT 604 IDENTIFIER from IPMS.body.externally-defined.data.direct- 605 reference . 607 For example, a Videotex body part will have 609 Content-type=3Dapplication/x400-bp; bp-type=3D2.6.1.4.5 611 The body contains the raw ASN.1 IPM.body octet 612 stream, including the initial tag octet. The content may 613 use a content- transfer-encoding of either base64 or 614 quoted-printable when carried in 7-bit MIME. It is 615 recommended to use the one which gives the more compact 616 encoding of the data. If this cannot be determined, 617 Base64 is recommended. No attempt is made to turn the 618 parameters of Extended Body Parts into MIME parameters, as 619 this cannot be done in a general manner. 621 Standard X.400 body parts may not be encoded directly 622 by this mechanism, but may be encoded indirectly by first 623 translating to the extended representation. 625 3.3. Tunneling FTBP body parts in MIME 627 The File Transfer Body Part is believed to be important in 628 the future as "the" means of carrying well-identified data 629 in X.400 networks. 631 They also share the property (at lest when limited to the 633 draft X.400/MIME body equivalences July 95 635 EMA MAWG functional profile) of having a well-defined data 636 part that is always representable as a sequence of bytes. 638 This conversion will have to fail, and the x400-bp 639 encapsulation used instead, if: 641 FileTransferData has more than one element 643 Contents-type is not unstructured-binary 645 Parameters that are not mappable, but important, are 646 present (like Compression, which EMA doesn't 647 recommend). 649 Otherwise, it can be encapsulated in X.400 by: 651 Creating the "content-type" value by forming the 652 string "application/x-ftbp." and appending the 653 numbers of the OID 655 Mapping all other parameters according to the 656 standard FTBP parameter mapping 658 Applying an appropriate content-transfer-encoding 660 The choice of the somewhat strange, and by necessity 661 unregistered, MIME type "application/x-ftbp.n.n.n.n" is 662 because for any concrete example of this usage, it will be 663 easy to configure any MIME reader to take advantage of the 664 identification. If the MIME type registration rules are 665 ever changed to allow the registration of a namespace, 666 rather than just of names, the "x-" can be deleted, and 667 the types can be "application/ftbp.n.n.n.n". 669 4. User control over the gateway choice 671 In some cases, the gateway may make an inappropriate 672 choice when deciding what to do about a particular body 673 part. 675 To allow an escape clause, the following defines a way in 676 which the user can signal the gateway what action it finds 678 draft X.400/MIME body equivalences July 95 680 most appropriate. 682 The headers given here override any "conversion 683 prohibited" and "conversion with loss prohibited" on the 684 message. 686 It is still the gateway's responsibility that the 687 generated messages conform to the destination domain's 688 syntax rules. 690 4.1. Conversion from MIME to X.400 692 This header field specifies explicit MIXER conversion. 693 Comments are allowed within the field according to the 694 usual RFC 822 convention. 696 If "x400-object-id" is omitted, "tunnel" is assumed. 698 mime-to-x400 =3D "Wanted-X400-Conversion" ":" 699 [ mime-from ] [ x400-object-id ] 700 "in" x400-encoding 702 x400-object-id =3D "to" ( object-identifier-2 / "tunnel" ) 703 x400-encoding =3D "bp14" / "bp15" / "ftbp" / "ia5" 704 mime-from =3D "from" mime-type 705 mime-type =3D word 707 There is no way to ask for a different conversion based on 708 MIME parameters or bodypart content. 710 Examples: 712 Wanted-X400-Conversion: from application/msword 713 to 1.2.840.113556.4.2 (Microsoft defined ms-word) 714 in ftbp 716 This uses the MAWG definitions, and leads to an FTBP encoding. 718 Wanted-X400-Conversion: from application/msword 719 to tunnel in bp14 721 This leads to a Body Part 14 encoding for all body parts of 722 application/msword. 724 draft X.400/MIME body equivalences July 95 726 Wanted-X400-Conversion: in bp14 728 This requests that this specific body part be encoded in Body Part 14. 730 This field may be used in two places: 732 (1) In the heading of an unstructured MIME body part. 733 In this case the EBNF.mime-from is omitted, and the 734 requested conversion applies to the body part. 736 (2) In a multipart. In this case, the body part type 737 to which the conversion applies is defined by 738 EBNF.mime-from, and the conversion applies to all 739 body parts of this MIME type contained in the 740 multipart, including those contained in nested 741 messages and multiparts. If a contained body part 742 has its own heading, this takes precedence. Note 743 that the "from" parameter is mandatory when used in 744 a multipart. 746 The EBNF.x400-object-id shall be present when "bp15" or 747 "ftbp" encoding is selected. 749 The value "tunnel" implies tunneling as defined in Chapter 750 3. 752 4.2. Conversion from X.400 to MIME 754 This IPM heading shall be present in the heading of a 755 message. It defines the mapping for all body parts of the 756 specified types, including those in nested messages. 758 wanted-MIME-conversion HEADING-EXTENSION 759 VALUE WantedMIMEConversions 760 ::=3D id-wanted-MIME-conversions 762 WantedMIMEConversions ::=3D SEQUENCE OF X400toMIMEConversion 764 draft X.400/MIME body equivalences July 95 766 X400toMIMEConversion ::=3D SEQUENCE { 767 x400-type X400Type, 768 mime-type MIMEType } 770 X400Type ::=3D CHOICE { 771 standard [0] INTEGER, -- standard body part 772 extended [1] OBJECT IDENTIFIER, -- BP 15 773 ftbp [2] OBJECT IDENTIFIER} -- FTBP application-refere= 774 nce 776 MIMEType ::=3D SEQUENCE { 777 type IA5String, -- type (e.g., application/ms-word) 778 encoding [1] IA5String OPTIONAl -- e.g. quoted-printable 779 parameters [2] IA5String OPTIONAL } -- MIME Parameters 781 The heading extension includes all requested conversions, 782 with explicit information as to how each body part type is 783 encoded in MIME. 785 FTBP is identified as a separate body part type, as there 786 will be a need for different encodings, dependent on what 787 is being carried. 789 Tunneling is requested by asking for "application/x400-bp" 790 or "application/ftbp" as the destination type. 792 For FTAM body parts, only the parameters where an explicit 793 mapping is defined will survive the gatewaying process. 794 For other body parts, there are three alternatives: 796 (1) The gateway knows a defined mapping for this 797 particular body part. It will be used, and 798 parameters mapped accordingly. 800 (2) The gateway knows how to extract an OCTET STRING 801 from the body part, and the destination is a simple 802 MIME body part. All information outside the OCTET 803 STRING is lost, but the basis survives. (This may 804 be the case for a BP14 that should end up in an 805 application/xyzzy, for instance). 807 (3) The gateway knows of no relevant mapping, and does 808 not know how to simplify the X.400 body part. The 809 gateway will then proceed as if the mapping control 810 field had not been present. 812 draft X.400/MIME body equivalences July 95 814 5. The equivalence registry 816 The following information MUST be supplied when describing 817 an equivalence: 819 MIME type name (which must be preregistered) 821 X.400 body part (often BP15 or FTAM Body Part) 823 If the BP15 is used, the following information must be 824 given: 826 (1) Object Identifier for X.400 BP15 Data 828 (2) Object Identifier for X.400 BP15 Parameters 830 (3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART- 831 TYPE macro) 833 If the FTBP is used, the following information must be 834 given: 836 (1) Object Identifier for the FTAM 837 Environment.application-reference 839 (2) Object Identifier for the FTAM Contents-type, if 840 unstructured-binary is not used 842 (3) Any other special considerations 844 In all cases, the following must be given: 846 Conversion algorithms. The expected effect of "Conversion 847 prohibited" and "Conversion with loss prohibited" should 848 be noted. 850 The conversion must be specified with enough detail to 851 permit independent implementation; literature references 852 are acceptable. 854 An equivalence can be registered with IANA using the form 856 draft X.400/MIME body equivalences July 95 858 at the end of this document. The purpose of the 859 registration is to achieve a greater uniformity among 860 gateways implementing the same translation; there is no 861 requirement that a gateway must support all of the 862 translations that are registered with IANA. Specific 863 conformance requirements for MIXER are given at the end of 864 this document. 866 5.1. Equivalence Table for known X.400 and MIME Types 868 This section itemizes the equivalences for all currently 869 known MIME content-types and X.400 body parts. 871 For each MIME content-type/X.400 body part pair, the 872 Equivalence Table will contain an entry with the following 873 sections: 875 X.400 Body Part 876 This section identifies the X.400 Body Part governed 877 by this Table entry. It includes any OBJECT 878 IDENTIFIERs or other parameters necessary to uniquely 879 identify the Body Part. 881 MIME Content-Type 882 This section identifies the MIME content-type 883 governed by this Table entry. The MIME content-type 884 named here must be registered with the IANA. 886 Section/document reference 887 Reference to section of this document, or to the 888 other document that describes this mapping. 890 The initial Equivalence Table entries in this document are 891 described using this convention. 893 Further registrations of equivalences should be submitted 894 to the IANA after a public review, using the example form 895 given at the end of this document. 897 draft X.400/MIME body equivalences July 95 899 5.2. MIME to X.400 Table 901 MIME content-type X.400 Body Part Section 902 ----------------- ------------------ ------- 903 text/plain 904 charset=3Dus-ascii ia5-text 7.1 905 charset=3DISO-8859-x EBP - GeneralText 7.2 906 text/richtext no mapping defined Tunnel 907 application/oda EBP - ODA 7.4 908 application/octet-stream bilaterally-defined 7.3 909 application/postscript EBP - mime-postscript-body [POSTSCRIPT] 910 image/g3fax g3-facsimile [IMAGES] 911 image/jpeg EBP - mime-jpeg-body [IMAGES] 912 image/gif EBP - mime-gif-body [IMAGES] 913 audio/basic no mapping defined Tunnel 914 video/mpeg no mapping defined Tunnel 915 message/RFC822 ForwardedIPMessage n.n 916 multipart/* ForwardedIPMessage n.n 918 Abbreviation: EBP - Extended Body Part 920 5.3. X.400 to MIME Table 921 Basic Body Parts 923 X.400 Basic Body Part MIME content-type Section 924 --------------------- -------------------- ------- 925 ia5-text text/plain;charset=3Dus-ascii 7.1 926 voice No Mapping Defined Tunnel 927 g3-facsimile image/g3fax [IMAGES] 928 g4-class1 no mapping defined Tunnel 929 teletex text/plain;charset=3Dteletex n.n 930 videotex no mapping defined Tunnel 931 encrypted no mapping defined Tunnel 932 bilaterally-defined application/octet-stream n.n 933 nationally-defined no mapping defined Tunnel 934 externally-defined See Extended Body Parts below 935 ForwardedIPMessage message/RFC822 or multipart n.n 937 X.400 Extended Body Part MIME content-type Section 938 ------------------------- -------------------- ------- 939 GeneralText text/plain;charset=3DISO-8859-x 7.2 940 ODA application/oda [ODA] 941 mime-postscript-body application/postscript [POSTSCRIPT] 942 mime-jpeg-body image/jpeg [IMAGES] 944 draft X.400/MIME body equivalences July 95 946 mime-gif-body image/gif [IMAGES] 948 draft X.400/MIME body equivalences July 95 950 5.4. Use of OBJECT IDENTIFIERs and ASN.1 MACROS 952 When one wants to define new BP15 body parts for use with 953 equivalences, it is important to know that X.420 dictates 954 that Extended Body Parts shall: 956 (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify 957 the contents, and 959 (2) be defined by using the ASN.1 Macro: 961 EXTENDED-BODY-PART-TYPE MACRO::=3D 962 BEGIN 963 TYPE NOTATION ::=3D Parameters Data 964 VALUE NOTATION ::=3D value (VALUE OBJECT IDENTIFIER) 966 Parameters ::=3D "PARAMETERS" type "IDENTIFIED" 967 "BY" value(OBJECT IDENTIFIER) 968 | empty; 969 Data ::=3D "DATA" type 970 END 972 To meet these requirements, this document uses the OID 974 mixer-bodies 976 defined in [MIXER], as the root OID for X.400 Extended 977 Body Parts defined for MIME interworking. 979 Each Extended Body Part contains Data and optional 980 Parameters, each being named by an OID. To this end, two 981 OID subtrees are defined under mixer-bodies, one for Data, 982 and the other for Parameters: 984 mixer-bp-data OBJECT IDENTIFIER ::=3D 985 { mixer-bodies 1 } 987 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 988 { mixer-bodies 2 } 990 All definitions of X.400 body parts submitted to the IANA 991 for registration must use the Extended Body Part Type 992 macro for the definition. See the next section for an 993 example. 995 draft X.400/MIME body equivalences July 95 997 Lastly, the IANA will use the mixer-bp-data and mixer-bp- 998 parameter OIDs as root OIDs for any new MIME content- 999 type/subtypes that aren't otherwise registered in the 1000 Equivalence Table. 1002 NOTE: The ASN.1 for an ExternallyDefinedBodyPart is 1004 ExternallyDefinedBodyPart ::=3D SEQUENCE { 1005 parameters [0] ExternallyDefinedParameters OPTIONAL, 1006 data ExternallyDefinedData } 1008 ExternallyDefinedParameters ::=3D EXTERNAL 1010 ExternallyDefinedData ::=3D EXTERNAL 1012 The ASN.1 for EXTERNAL is (from X.208): 1014 EXTERNAL ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE 1015 {direct-reference OBJECT IDENTIFIER OPTIONAL, 1016 indirect-reference INTEGER OPTIONAL, 1017 data-value-descriptor ObjectDescriptor OPTIONAL, 1018 encoding CHOICE 1019 {single-ASN1-type [0] ANY, 1020 octet-aligned [1] IMPLICIT OCTET STRING, 1021 arbitrary [2] IMPLICIT BIT STRING}} 1023 ObjectDescriptor ::=3D [UNIVERSAL 7] IMPLICIT GraphicString 1025 There are a bit too many choices here; the common X.400 1026 usage for BP15 encoding is to: 1028 (1) Always use direct-reference 1030 (2) Omit indirect-reference and data-value-descriptor 1032 (3) Use the single-ASN1-type encoding only 1034 Unfortunately, some implementations have chosen to use the 1035 octet-aligned choice when constructing values where the 1036 ASN.1 type is OCTET STRING, which of course caused 1037 interoperability problems. 1039 An attempt to specify that X.420 only allowed the single- 1040 ASN1-type choice in the 1996 versions is still (Sept 1995) 1041 being debated in ISO; the end result seems to be that all 1043 draft X.400/MIME body equivalences July 95 1045 agree in principle that single-ASN1-type should be used, 1046 but that one has to allow the generation of the octet- 1047 aligned choice as being conformant. 1049 6. Defined Equivalences 1051 6.1. IA5Text - text/plain 1053 X.400 Body Part: IA5Text 1054 MIME Content-type: text/plain; charset=3DUS-ASCII 1055 Conversion Type: Byte copy 1056 Comments: 1058 When mapping from X.400 to MIME, the "repertoire" 1059 parameter is ignored. 1061 When mapping from MIME to X.400, the "repertoire" 1062 parameter is set to IA5 (5). 1064 NOTE: The MIME Content-type headers are omitted, when 1065 mapping from X.400 to MIME, if and only if the IA5Text 1066 body part is the only body part in the IPMS.Body sequence. 1068 NOTE: IA5Text specifies the "currency" symbol in position 1069 2/4. This is converted without comment to the "dollar" 1070 symbol, since the author of this document has seen many 1071 documents in which the position was intended to indicate 1072 "dollar" while he has not yet seen one in which the 1073 "currency" symbol is intended. 1075 (For reference: The T.50 (1988) recommendation, which 1076 defines IA5, talks about ISO registered set number 2, 1077 while ASCII, using the "dollar" symbol, is ISO registered 1078 set number 6. There are no other differences.) 1080 NOTE: It is not uncommon, though it is a violation of the 1081 standard, to use 8-bit character sets inside an IA5 body 1082 part. Gateways that can expect to encounter this situation 1083 should consider implementing something like the guidance 1084 given in RFC 1428, "Transition of Internet Mail from just- 1085 send-8 to 8-bit SMTP/MIME", and generate appropriate 1086 charset parameters for the MIME messages they generate. 1088 draft X.400/MIME body equivalences July 95 1090 This behavior is not required for MIXER conformance, since 1091 it is only needed when the base standards are violated. 1093 6.2. GeneralText - text/plain (ISO-8859) 1095 X.400 Body Part: GeneralText; CharacterSets in 1096 6,100,101,109,110,126,127,138,144,148 1097 MIME Content-Type: text/plain; charset=3DISO-8859-(1-9) 1098 Conversion Type: Text conversion without character change 1099 Comments: 1101 The conversion of text is a problematic one, and one in 1102 which it is likely that gateways should be given wide 1103 latitude to make decisions based upon their knowledge of 1104 the user's preferences. The text given below is thought to 1105 give the best approximation to a gateway conforming to 1106 current and anticipated usage in the MIME and X.400 1107 worlds, and is the way recommended when no knowledge of 1108 the recipient capabilities exists. 1110 The changes, such as normalizing escape sequences, should 1111 not be done when "conversion-prohibited" is set. If 1112 "conversion-with-loss-prohibited" is set, translation to a 1113 character set that is not able to encode all characters 1114 cannot be done, and the message should be non-delivered 1115 with an appropriate non-delivery reason. 1117 When mapping from X.400 to MIME, the character-set is 1118 chosen from the table below according to the value of 1119 Parameters.CharacterSets. If no match is found, and the 1120 gateway does not support a conversion, the character set 1121 shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the 1122 numbers of the Parameters.CharacterSets, sorted in numeric 1123 order. 1125 When mapping from MIME to X.400, GeneralText is an 1126 Extended Body Part, hence it requires an OID. The OID for 1127 the GeneralText body is defined in [MOTIS], part 8, annex 1128 D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1 1129 11 11}. 1131 The Parameters.CharacterSets is set from table below 1132 according to the value of "charset" 1134 draft X.400/MIME body equivalences July 95 1136 The common use of character sets in MIME is somewhat 1137 different from the rules given by X.400; in particular, it 1138 is common in MIME to assume that the character sets follow 1139 strict rules. For the ISO-8859-x character sets, it is 1140 assumed that they are designated and invoked at the 1141 beginning of the text, and that no designation or 1142 invocation sequences occur within the body of the text. 1143 The rules for ISO-2022-JP are given in RFC 1468, and are 1144 even more particular, using a pure 7-bit encoding in which 1145 each line of text starts in ASCII. 1147 Therefore, the text must be "normalized" by going through 1148 the whole message, using a state machine or similar device 1149 to remove all escape and shift sequences. 1151 Appendix gives pseudocode for such a conversion. 1153 NOTE: In 1988, the GeneralText body part was defined in 1154 ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT 1155 recommendation; this was added later. Also, the 1156 parameters have been heavily modified; they should be a 1157 SET OF INTEGER in the currently valid text. Use the 1158 latest version of the standard that you can get hold of. 1160 The following table lists the MIME character sets and the 1161 corresponding ISO registry numbers. If no correspondence 1162 is found, this conversion fails, and the generic body part 1163 approach is used. 1165 MIME charset ISO IR numbers Comment 1166 ----------------------------------------------- 1167 ISO-8859-1 6, 100 West European "8-bit ASCII" 1168 ISO-8859-2 6, 101 East European 1169 ISO-8859-3 6, 109 1170 ISO-8859-4 6, 110 1171 ISO-8859-5 6, 144 Cyrillic 1172 ISO-8859-6 6, 127 Arabic 1173 ISO-8859-7 6, 126 Greek 1174 ISO-8859-8 6, 138 Hebrew 1175 ISO-8859-9 6, 148 Other Latin-using languages 1176 ISO-2022-JP 6, 14, 42, 87 Japanese 1178 When converting from MIME to X.400, generate the correct 1179 OIDs for use in the message envelope's Encoded Information 1180 Types by looking up the ISO IR number in the above table, 1182 draft X.400/MIME body equivalences July 95 1184 and then appending it to the id-cs-eit-authority {1 0 1185 10021 7 1 0} OID. 1187 The escape sequences to designate and invoke the relevant 1188 character sets in their proper positions must be added to 1189 the front of the GeneralText character string. 1191 For ISO 8859-1, the relevant escape sequence will be: 1193 ESC 28 42 1194 ASCII in G0 1196 ESC 2D 41 1197 ISO-IR-100 in G1 1199 ESC 21 41 1200 High control character set in C1 1202 ESC 7E 1203 Locking shift 1 Right 1205 6.3. BilaterallyDefined - application/octet-stream 1207 X.400 Body Part: BilaterallyDefined 1208 MIME Content-Type: Application/Octet-Stream (no parameters) 1209 Conversion Type: Byte copy 1210 Comments: 1212 When mapping from MIME to X.400, if there are parameters 1213 present in the Content-Type: header field, they are 1214 removed. 1216 DISCUSSION: 1217 The parameters "name" "type" and "conversions" are 1218 advisory; name and conversions are depreciated in RFC 1219 1521. 1221 The parameter "padding" changes the interpretation of 1222 the last byte of the data, but it is deemed better by 1223 the WG to delete this information than to non-deliver 1224 the body part. The "padding" parameter is rarely used 1225 with MIME. 1227 draft X.400/MIME body equivalences July 95 1229 Use of BilaterallyDefined Body Parts is specifically 1230 deprecated in both 1988 and 1992 X.400. It is retained 1231 solely for backward compatibility with 1984 systems, and 1232 because it is in common use. 1992 X.400 defines a File 1233 Transfer Body Part to solve this problem (i.e. binary file 1234 transfer through email). The standard and its regional 1235 profiles are not solid enough yet to exploit as a solution 1236 for this problem. 1238 6.4. FTBP EMA Unknown Attachment - 1239 application/octet-stream 1240 X.400 Body Part: FTBP EMA Unknown Attachment 1241 MIME Content-Type: Application/Octet-Stream 1242 Conversion Type: Byte copy 1243 NOTE: At the time of this writing (Sept 1995), support for 1244 BilaterallyDefined is MUCH more widespread than support 1245 for the FTBP body part, and definitely more widespread 1246 than support for the EMA FTBP Unknown Attachment. Gateways 1247 should only choose to generate this body part from 1248 Application/OctetStream when it is believed that the 1249 recipient is able to handle this body part. 1251 The OID for the Unknown Attachment is { iso(1) 1252 countries(2) usa(840) organization (1) ema (113694) 1253 objects(2) messaging(2) attachments(1) unknown (1)}, or 1254 1.2.840.1.113694.2.2.1 for short. 1256 The parameters for this type must be mapped according to 1257 chapter <<>>, with the following extensions for the 1258 parameters of the application/octet-stream: 1260 (1) If there is no Content-Disposition parameter with a 1261 filename, and there is a name parameter, the 1262 FTBP.FileTransferParameters.File- 1263 attributes.pathname is generated from this 1264 parameter. Note that RFC 1521 recommends not using 1265 the "name" parameter. 1267 The "type", "conversions" and "padding" attributes 1268 are ignored; "type" is for human consumption; 1269 "conversions" are discouraged in RFC 1521. 1271 Editor note: 1272 Does there exist a bit-aligned storage to be used 1274 draft X.400/MIME body equivalences July 95 1276 when the "padding" parameter is present? This is not 1277 recommended by EMA; do we want to have it? 1278 Should the "type" parameter be mapped into the FTBP 1279 FileTransferParameters.Environment.UserVisibleString? 1280 It seems to be more or less the same kind of thing, 1281 according to EMA. 1283 The body mapping is just copying the bytes in both 1284 directions. 1286 6.5. MessageBodyPart - message/RFC822 1288 X.400 body part: MessageBodyPart 1289 MIME Content-Type: message/RFC822 1290 Conversion Type: Special 1292 NOTE: If the headers of the X.400 MessageBodyPart contains the 1293 "multipart-message" heading extension with the isAMessage bit set 1294 (either explicitly or implicitly), the mapping should be to 1295 multipart/*. 1297 To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 1298 mapping is recursively applied, to generate an RFC 822 Message. 1299 If present, the IPMS.MessageBodyPart.parameters.delivery-envelope 1300 is used for the MTS Abstract Service Mappings. If present, the 1301 IPMS.MessageBodyPart.parameters.delivery-time is mapped to the 1302 extended RFC 822 field "Delivery-Date:". 1304 When a message/RFC822 is contained within a MIME message, it is 1305 mapped to an IPMS.MessageBodyPart according to MIXER. 1306 specification. Any mappings that would have been made to the MTS 1307 Abstract Service are placed in 1308 IPMS.MessageBodyPart.parameters.delivery-envelope. 1310 6.6. MessageBodyPart - multipart/* 1312 X.400 body part: MessageBodyPart 1313 MIME Content-Type: multipart/* 1314 Conversion Type: Special 1316 NOTE: If the headers of the X.400 MessageBodyPart do not contain the 1317 "multipart-message" heading extension with the "isAMessage" flag FALSE= 1318 , 1319 the mapping should be to message/RFC822. 1321 draft X.400/MIME body equivalences July 95 1323 A MIME multipart is a set of content-types and not a message with 1324 a set of content types. When the multipart is at the outermost 1325 MIME header and is either multipart/digest or multipart/mixed, 1326 elements of the multipart are mapped directly onto IPMS.Bodypart. 1327 In other cases, a MIME multipart is mapped to an 1328 IPMS.MessageBodyPart containing an IPMS.Bodypart for each element 1329 of the multipart. 1331 When a nested IPMS.Message is generated from a multipart, an 1332 IPMS.heading shall always be generated. The only mandatory field 1333 is the IPMS.Heading.this-IPM message id, which shall be generated 1334 by the gateway. An IPMS.Heading.subject field shall also be 1335 generated, in order to provide useful information to non-MIME 1336 capable X.400(88) UAs and to all X.400(84) UAs. The subject 1337 field is set as follows according to the multipart subtype: 1339 mixed: 1340 "Multipart Message" 1342 alternative: 1343 "Alternative Body Parts containing the same 1344 information" 1346 digest: 1347 "Message Digest" 1349 parallel: 1350 "Body Parts interpreted in parallel" 1352 other: 1353 "Multipart Message ()" 1355 For other types of multipart, the multipart subtype shall 1356 be included in the subject line. 1358 For each multipart, the following IPMS.HeadingExtension 1359 shall be generated, with the value set according to the 1360 subtype: 1362 multipart-message HEADING-EXTENSION 1363 VALUE MultipartType 1364 ::=3D id-hex-multipart-message 1366 MultipartType ::=3D SEQUENCE { 1368 draft X.400/MIME body equivalences July 95 1370 subtype IA5String, 1371 isAMessage BOOLEAN DEFAULT TRUE } 1373 The MultipartType contains the subtype, for example 1374 "digest". If this heading is present when mapping from 1375 X.400 to MIME, the appropriate multipart may be generated. 1377 The isAMessage flag is needed because of the case where a 1378 message contains a ForwardedIPMessage, which itself was 1379 generated from a MIME message that was a Multipart; it is 1380 set whenever the multipart is the outermost level of 1381 nesting inside a Message/RFC822. 1383 6.7. Teletex - Text/Plain (Teletex) 1384 X.400 Body Part: Teletex 1385 MIME Content-Type: text/plain; charset=3DTeletex 1386 Conversion Type: Text conversion 1387 Comments: 1389 The Teletex body part is frequently used in X.400(84) to 1390 send around text with slightly extended character sets 1391 beyond ASCII. 1393 Its body consists of a series of "pages", separated by 1394 ASN.1 representation. It is important to many people to 1395 have this mapped into something that is readable to most 1396 end-users; therefore, it is recommended to map this onto 1397 Text/Plain; however, since this is not plain text, the 1398 conversion must be specified. 1400 From X.400 to RFC-822, the conversion shall take the bytes 1401 of all the pages in the "data" part of the 1402 TeletexBodyPart, add a FF character (0x0C, control-L) to 1403 each part that does not already end in one, and 1404 concatenate them together to form the body of the 1405 Text/Plain. 1407 The character set shall be "Teletex", which is especially 1408 registered for this purpose. Its definition is shown in an 1409 appendix. 1411 The parameters are discarded. 1413 draft X.400/MIME body equivalences July 95 1415 From RFC-822 to X.400, the conversion shall split the 1416 content at each occurrence of the FF character (0x0C), 1417 delete the character and construct the Teletex body part 1418 as a SEQUENCE OF TeletexString, as described in X.420(88), 1419 section 7.3.5 1421 The TeletexParameters may, but need not, contain the 1422 number-of-pages component. 1424 NOTE: It is recommended, but not mandated, that the data 1425 be converted into a more widespread character set like 1426 ISO-8859-1 or ISO-2022-JP (if applicable) if possible. 1427 This will result in the reverse translation giving a 1428 GeneralText body part, which will have to be dealt with 1429 appropriately at the X.400/88 to X.400/84 downgrading 1430 boundary, if possible, but will give a much greater chance 1431 that the MIME recipient can actually read the message. 1433 draft X.400/MIME body equivalences July 95 1435 7. Body parts where tunneling is recommended 1437 Some body parts are MIME constructs, and their 1438 functionality will be severely damaged if they are coerced 1439 into an X.400 framework. 1441 Special care needs to be taken with these; they are 1442 described below. 1444 7.1. message/external-body 1446 X.400 body part: ia5 MIME Content-Type: message/external- 1447 body Conversion Type: Special 1449 The message/external-body part points to an object that 1450 can be retrieved using Internet protocols. 1452 There are three cases to consider for the recipient's 1453 capabilities: 1455 (1) The user has no Internet access. In this case, the 1456 user might be grateful if the gateway fetches the 1457 body part and inserts it into the message. If the 1458 body part is large or dynamic, it might not be 1459 appropriate. 1461 (2) The user has Internet access, but no UA support for 1462 fetching external-body objects. 1464 (3) The user has Internet access and UA support for 1465 fetching external-body objects, based on an 1466 understanding of this document. 1468 Some access-types, like anonymous FTP, are easy to 1469 resolve. Others, like the Mailserver access-type, are 1470 almost impossible to resolve at a gateway. 1472 To support the second case above, the tunneling method 1473 chosen is the HARPOON encapsulation described in section 1474 3.1.3, using an IA5 body part, inserting the string "MIME- 1475 Version: 1.0 (generated by gateway)" at the beginning of 1476 the body part. (The part in parentheses can be changed at 1478 draft X.400/MIME body equivalences July 95 1480 will). 1482 This will: 1484 (1) Maximize the chance that the user will see the 1485 message 1487 (2) Give the user hints that will enable him to fetch 1488 the message using other Internet tools 1490 (3) Identify the message as a MIME object in a reliable 1491 fashion, allowing UAs to support the fetching of 1492 the object if the UA implementor desires. 1494 The gateway MAY support a configuration option to 1495 retrieve; it MUST support the HARPOON tunneling when 1496 retrieval is not desired or not possible. 1498 7.2. message/partial 1500 This represents part of a larger message, where it is only 1501 possible to parse the complete message after getting all 1502 the pieces. 1504 The gateway's choices are: 1506 (1) Wait until all the pieces arrive at the gateway, 1507 reassemble the message, and use normal processing 1509 (2) Encapsulate the message, using any encapsulation 1510 method 1512 The choice of what to do, and which encapsulation 1513 to use, is left up to the gateway, but it MUST be 1514 possible to configure it to do encapsulation, 1515 possibly after a configurable wait. 1517 draft X.400/MIME body equivalences July 95 1519 7.3. multipart/signed 1521 Gatewaying security is a problem. The gateway can 1522 basically take three approaches: 1524 - Strip the multipart/signed, leaving the bare body 1525 part unsecured, possibly with a comment that the 1526 signature was stripped 1528 - Attempt to check the signature and re-signing the 1529 message using X.400 security functions, then 1530 stripping as above 1532 - Encapsulate the message. This is the only approach 1533 that allows end to end security, but requires MIME 1534 functionality at the recipient. 1536 All these are valid options for a MIXER gateway. The 1537 gateway MUST implement the third alternative. The 1538 encapsulation shall be done using HARPOON style 1539 encapsulation: Prefixing the data with "MIME-version: 1.0" 1540 and putting the whole multipart/signed, headers and all, 1541 into an IA5 body part. 1543 7.4. multipart/encrypted 1545 There are two basic cases for a gateway: 1547 - The gateway is trusted with the user's keys. In this 1548 case, the gateway can decrypt the message, possibly 1549 add a note that it has done so, and gateway the 1550 unencrypted form. This does nothing to protect the 1551 transfer from gateway to recipient, unless suitable 1552 X.400-native security is applied. 1554 - The gateway is not trusted with the recipient's keys. 1555 In this case, tunneling is the only approach that 1556 preserves any information at all. 1558 draft X.400/MIME body equivalences July 95 1560 The valid options for a MIXER gateway are therefore: 1562 - Decrypt the body part 1564 - Tunnel the body part 1566 - Drop the body part 1568 A MIXER compliant gateway MUST implement the second 1569 option, using an IA5 tunnel in the HARPOON style. 1571 8. Conformance requirements 1573 In order to be called MIXER conformant, a gateway must 1574 implement: 1576 - Encapsulation of MIME content in the FTBP tunneling 1577 body part 1579 - Encapsulation of X.400 body parts in the x400-bp body 1580 part 1582 - Encapsulation of FTBP body parts in the 1583 application/x-oid.n.n.n body part 1585 - Text/plain <-> IA5Text 1587 - Text/plain; charset=3Diso-8859-* <-> GeneralText 1589 - Multipart/* <-> ForwardedIPMessage 1591 - message/RFC822 <-> ForwardedIPMessage 1593 - application/octet-stream <-> FTBP unknown 1595 - application/octet-stream <-> BilaterallyDefined 1597 - A configuration choice of which application/octet- 1598 stream translation to use 1600 draft X.400/MIME body equivalences July 95 1602 All other parts of this specification MAY be implemented 1603 by the gateway. If they are implemented at all, they MUST 1604 be implemented conformant to this specification. 1606 In this context, a feature is "implemented" in a product 1607 if it is possible to configure the product in such a way 1608 that this feature is used. This specification does not 1609 restrict the product to only be configured in such a 1610 fashion. 1612 References 1614 [RFC-822] 1615 D.H. Crocker, Standard for the Format of ARPA 1616 Internet Text Messages. Request for Comments 822, 1617 (August, 1982). 1619 [MIME] 1620 N. Borenstein, N. Freed, MIME: Mechanisms for 1621 Specifying and Describing the Format of Internet 1622 Message Bodies. Request for Comments 1341, (June, 1623 1992). 1625 [MIXER] 1626 S.E. Hardcastle-Kille, Mapping between X.400(1988) / 1627 ISO 10021 and RFC-822. (in preparation) 1629 [T.4] 1630 CCITT Recommendation T.4, Standardization of Group 3 1631 Facsimile Apparatus for Document Transmission (1988) 1633 [T.30] 1634 CCITT Recommendation T.30, Procedures For Document 1635 Facsimile Transmission in the General Switched 1636 Telephone Network (1988) 1638 [T.411] 1639 CCITT Recommendation T.411 (1988), Open Document 1640 Architecture (ODA) and Interchange Format, 1641 Introduction and General Principles 1643 [MOTIS] 1644 ISO/IEC International Standard 10021, Information 1645 technology - Text Communication - Message-Oriented 1647 draft X.400/MIME body equivalences July 95 1649 Text Interchange Systems (MOTIS) (Parts 1 to 8) 1651 [X.400] 1652 CCITT, Data Communication Networks - Message Handling 1653 Systems - Recommendations X.400 - X.420 (1988 1654 version) 1656 [X.420] 1657 CCITT Recommendation X.420 (1988), Interpersonal 1658 Messaging System 1660 [RFC-X400USE] 1661 Harald Tveit Alvestrand, X.400 use of extended 1662 Character Sets, Internet Draft, June 1992 1664 [MAWG] 1665 Electronic Messaging Association Message Attachment 1666 Working Group (MAWG): File Transfer Body Part 1667 Feasibility Project Guide - version 1.5 - September 1668 1995 1670 9. Authors' address 1672 Harald Tveit Alvestrand 1673 UNINETT 1674 P.O.box 6883 Elgeseter 1675 N-7002 Trondheim 1676 NORWAY 1678 Harald.T.Alvestrand@uninett.no 1680 APPENDIXES 1682 Appendix A: Escape code normalization 1684 The algorithm given here in pseudocode will reduce a 1685 GeneralString ISO-2022 unlimited use of shifts sequence to 1686 a pure 8-bit sequence that does not use shift sequences, 1687 if possible. 1689 Some error conditions, like EOF, are not tested for. It 1690 crashes if asked to do something it cannot. Control 1692 draft X.400/MIME body equivalences July 95 1694 character set switching is missing. 1696 A similar routine, albeit more complex, can be written for 1697 normalizing to the ISO-2022-JP character set. 1699 BEGIN: (from X.209) 1700 g0 =3D 6 (should be 2, but ignore the difference) 1701 g1 =3D NULL 1702 g2 =3D NULL 1703 g3 =3D NULL 1704 c0 =3D 1 (ASCII control) 1705 c1 =3D NULL 1706 leftset =3D &g0 (current input set, low) 1707 rightset =3D &g1 (current input set, high) 1708 lowset =3D 6 (output set, low) 1709 highset =3D NULL (output set, high) 1710 charset =3D US-ASCII 1712 (Init for the set tables) 1713 chartoid[{2D,2E,2F}, 41] =3D 100 1714 ..... 1715 idtoname[100] =3D "ISO-8859-1" 1716 ..... 1718 WHILE (more data) 1719 CASE head of input 1720 {These are the locking shift sequences} 1721 INCASE "00/14": (LS0, SO) 1722 leftset =3D &g0; 1723 INCASE "00/15": (LS1, SI) 1724 leftset =3D &g 1725 INCASE "ESC 07/14": (LS1R) 1726 rightset =3D &g1; 1727 INCASE "ESC 07/13": (LS2R) 1728 rightset =3D &g2; 1729 INCASE "ESC 07/12": (LS3R) 1730 rightset =3D &g3; 1731 {There is missing code for handling the single shift function} 1732 {These are the changes of graphic character sets} 1733 {Note that G0 can contain only 94-character charsets} 1734 INCASE "ESC 28" 1735 g0 =3D chartoid[lastchar, next character] 1736 sethiset(g0) 1737 INCASE "ESC 2D", "ESC 29" 1738 g1 =3D chartoid[lastchar, next character] 1740 draft X.400/MIME body equivalences July 95 1742 sethiset(g1) 1743 INCASE "ESC 2E", "ESC 2A" 1744 g2 =3D chartoid[lastchar, next character] 1745 sethiset(g2) 1746 INCASE "ESC 2F", "ESC 2B" 1747 g3 =3D chartoid[lastchar, next character] 1748 sethiset(g3) 1749 {control characters. There is missing code for changing these} 1750 INCASE 00/00-01/15 {normal control} 1751 write(char) 1752 INCASE 08/00-09/15 {upper control} 1753 write(char) 1754 {Normal characters} 1755 INCASE 02/00-07/15 (Left) 1756 IF (*leftset =3D=3D lowset) 1757 write(char) 1758 ELSIF (*leftset =3D=3D highset) 1759 write(char+80) 1760 ELSE 1761 ERROR "Shift error" 1762 ENDIF 1763 INCASE 10/00-15/15 1764 IF (*rightset =3D=3D highset) 1765 write(char) 1766 ELSIF (*rightset =3D=3D lowset) 1767 write(char-80) 1768 ELSE 1769 ERROR "Shift error" 1770 ENDIF 1771 ENDCASE 1772 ENDWHILE 1774 SUBROUTINE sethighset(g1) 1776 IF (highset =3D=3D NULL) 1777 charset =3D idtoname[g1] 1778 highset =3D g1 1779 ELSIF (highset =3D=3D g1) 1780 (it's OK) 1781 ELSE 1782 ERROR "Too many charsets encountered" 1783 ENDIF 1785 ENDROUTINE 1787 draft X.400/MIME body equivalences July 95 1789 Appendix B: OID Assignments 1790 MIXER-MAPPINGS DEFINITIONS ::=3D BEGIN 1791 EXPORTS -- everything --; 1793 IMPORTS 1794 experimental 1795 FROM RFC1155-SMI; 1796 mixer 1797 FROM MIXER --Companion RFC--; 1799 mixer-bp-data OBJECT IDENTIFIER ::=3D 1800 { mixer-bodies 1}; 1802 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 1803 { mixer-bodies 2}; 1805 id-mime-bp-data OBJECT IDENTIFIER ::=3D 1806 { mixer-bp-data 1}; 1808 id-mime-bp-parameters OBJECT IDENTIFIER ::=3D 1809 { mixer-bp-parameter 1}; 1811 -- the following assignments were done in RFC 1494, using 1812 -- slightly different names, but the same numbers. 1813 -- their defining text is now is now in other documents 1814 id-mime-postscript-body OBJECT IDENTIFIER ::=3D 1815 { mixer-bp-data 2} 1817 id-mime-jpeg-body OBJECT IDENTIFIER ::=3D 1818 { mixer-bp-data 3} 1820 id-mime-gif-body OBJECT IDENTIFIER ::=3D 1821 { mixer-bp-data 4}; 1823 -- This is a new definition, and defines an FTAM application reference= 1824 , 1825 -- not a BP15 data OID. 1826 id-mime-ftbp-data OBJECT IDENTIFIER ::=3D 1827 { mixer-bp-data 5 } 1829 draft X.400/MIME body equivalences July 95 1831 Appendix C: Registration information for the Teletex 1832 character set 1834 The Teletex character set is a character set in which the 1835 ISO 2022 character set switching mechanism may be used to 1836 switch between the following registered ISO character 1837 sets: 1839 ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set 1840 ISO-IR-102 - a fairly standard US-ASCII variant 1841 ISO-IR-103 - Latin characters using non-spacing accents 1842 ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more. 1843 ISO-IR-107 - Control characters for C1 use 1845 Its intended use of this character set is to represent 1846 data that comes from ISO protocols that use the ASN.1 1847 construct "TeletexString" or "T61string" without 1848 conversion. 1850 The set of allowed character sets can be found in CCITT 1851 recommendation X.208(1988), chapter 31.2 and Table 1852 6/X.208. 1854 The rules for encoding the data type can be found in CCITT 1855 recommendation X.209(1988), chapter 23. It states that at 1856 the beginning of the string, G0 is always ISO-IR-102, C0 1857 is ISO-IR-106, and C1 is ISO-IR-107. 1859 The specification seems somehow to have missed the 1860 implicit assumption that ISO-IR-103 is designated and 1861 invoked as G1 and shifted into the upper half of the 1862 character set which seems to be assumed at least by the 1863 X.400 and X.500 software that uses TeletexStrings; 1864 implementors should act as if the sequence ESC 2/9 7/6 1865 LS1R is always present at the beginning of the data. 1867 The rules for interpreting T.61 data are found (I believe) 1868 in CCITT recommendations T.51, T.52 and T.53 (data from 1869 the ITU WWW server): 1871 T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93] 1872 Latin based coded character sets for telematic services 1873 T.52 (1993) [New] [88 pp.] [Publ.: Apr.94] 1874 Non-Latin coded character sets for telematic services 1875 T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95] 1877 draft X.400/MIME body equivalences July 95 1879 Character coded control functions for telematic services 1880 Note - C: 26/48/69 1882 (The author has not yet obtained a copy of these, even 1883 though they only cost SFR 70 from the ITU...) 1885 The Teletex character set is closely related to (but not 1886 identical with) that specified in ISO 6937. 1888 No further restrictions are imposed by this registration; 1889 in particular, character set switching can occur anywhere, 1890 and there is no guarantee that the character sets will be 1891 switched "back" at the end. 1893 Appendix D: IANA Registration form for new mappings 1895 To: IANA@isi.edu 1896 Subject: Registration of new X.400/MIME content type mapping 1898 MIME type name: 1900 (this must have been registered previously with IANA) 1902 X.400 body part: 1904 X.400 Object Identifier for Data: 1906 (If left empty, an OID will be assigned by IANA under 1907 mixer-bp-data) 1909 X.400 Object Identifier for Parameters: 1911 (If left empty, an OID will be assigned by IANA under 1912 mixer-bp-parameter. If it is not used, fill in the words 1913 NOT USED.) 1915 X.400 ASN.1 Syntax: 1917 (must be an EXTENDED-BODY-PART-TYPE macro, or reference to 1918 a Basic body part type) 1920 Conversion algorithm: 1922 (must be defined completely enough for independent 1924 draft X.400/MIME body equivalences July 95 1926 implementation. It may be defined by reference to RFCs). 1928 Person & email address to contact for further information: 1930 INFORMATION TO THE SUBMITTER: 1932 The accepted registrations will be listed in the "Assigned 1933 Numbers" series of RFCs. The information in the 1934 registration form is freely distributable. 1936 draft X.400/MIME body equivalences July 95 1938 Table of Contents 1940 Status of this Memo ................................ 1 1941 1 Introduction ...................................... 2 1942 1.1 Glossary ........................................ 3 1943 2 Basic rules for body part conversion .............. 3 1944 2.1 Generating the IPM Body from MIME ............... 5 1945 2.2 Ground rules for generating the MIME Body from 1946 the IPMS.Body .................................. 5 1947 2.3 Mapping the EMA FTBP parameters ................. 6 1948 2.3.1 Summary of FTBP elements generated ............ 10 1949 2.4 Information that is lost when mapping ........... 10 1950 3 Encapsulation of body parts ....................... 11 1951 3.1 Encapsulation of MIME in X.400 .................. 11 1952 3.1.1 BP15 tunneling body part ...................... 11 1953 3.1.2 FTBP tunneling body part ...................... 13 1954 3.1.3 Tunneling using IA5 ........................... 13 1955 3.1.4 Tunneling using BP14 .......................... 14 1956 3.2 Tunneling X.400 Body Parts in MIME .............. 15 1957 3.3 Tunneling FTBP body parts in MIME ............... 15 1958 4 User control over the gateway choice .............. 16 1959 4.1 Conversion from MIME to X.400 ................... 17 1960 4.2 Conversion from X.400 to MIME ................... 18 1961 5 The equivalence registry .......................... 20 1962 5.1 Equivalence Table for known X.400 and MIME 1963 Types .......................................... 21 1964 5.2 MIME to X.400 Table ............................. 22 1965 5.3 X.400 to MIME Table ............................. 22 1966 5.4 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 24 1967 6 Defined Equivalences .............................. 26 1968 6.1 IA5Text - text/plain ............................ 26 1969 6.2 GeneralText - text/plain (ISO-8859) ............. 27 1970 6.3 BilaterallyDefined - application/octet-stream 1971 ................................................ 29 1972 6.4 FTBP EMA Unknown Attachment - applica=AD 1973 tion/octet-stream .............................. 30 1974 6.5 MessageBodyPart - message/RFC822 ................ 31 1975 6.6 MessageBodyPart - multipart/* ................... 31 1976 6.7 Teletex - Text/Plain (Teletex) .................. 33 1977 7 Body parts where tunneling is recommended ......... 35 1978 7.1 message/external-body ........................... 35 1979 7.2 message/partial ................................. 36 1980 7.3 multipart/signed ................................ 37 1981 7.4 multipart/encrypted ............................. 37 1983 draft X.400/MIME body equivalences July 95 1985 8 Conformance requirements .......................... 38 1986 References ......................................... 39 1987 9 Authors' address .................................. 40 1988 APPENDIXES ......................................... 40 1989 Appendix A: Escape code normalization .............. 40 1990 Appendix B: OID Assignments ........................ 43 1991 Appendix C: Registration information for the 1992 Teletex character set .......................... 44 1993 Appendix D: IANA Registration form for new map=AD 1994 pings .......................................... 45