idnits 2.17.1 draft-ietf-mixer-bodymap-04.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-19) 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-04.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mixer-bodymap-04.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mixer-bodymap-04.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-04.txt.', but the file name used is 'draft-ietf-mixer-bodymap-04' ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 11) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 51 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 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 2 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 183: '...rmant MIXER gateway MUST be able to be...' RFC 2119 keyword, line 448: '...sible-string, it MAY choose to omit th...' RFC 2119 keyword, line 450: '... MAY choose to encapsulate using a ...' RFC 2119 keyword, line 497: '... A gateway MAY choose to support th...' RFC 2119 keyword, line 498: '... available, but MUST support this lim...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 357 has weird spacing: '...s; the handl...' == Line 1089 has weird spacing: '...-stream bila...' == Line 1469 has weird spacing: '...mapping is re...' == Line 1496 has weird spacing: '...part is mappe...' == Line 2172 has weird spacing: '... (If left ...' == (5 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 739377 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) -- Looks like a reference, but probably isn't: '0' on line 1206 -- Looks like a reference, but probably isn't: '1' on line 1207 -- Looks like a reference, but probably isn't: '2' on line 1208 == Missing Reference: 'UNIVERSAL 8' is mentioned on line 1201, but not defined == Missing Reference: 'UNIVERSAL 7' is mentioned on line 1210, but not defined -- Looks like a reference, but probably isn't: '100' on line 1964 == Missing Reference: 'New' is mentioned on line 2133, but not defined == Unused Reference: 'RFC-822' is defined on line 1842, but no explicit reference was found in the text == Unused Reference: 'RFC-X400USE' is defined on line 1888, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1341 (ref. 'MIME') (Obsoleted by RFC 1521) -- Duplicate reference: RFC822, mentioned in 'MIXER', was also mentioned in 'RFC-822'. ** Obsolete normative reference: RFC 822 (ref. 'MIXER') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'MOTIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-X400USE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MAWG' ** Obsolete normative reference: RFC 1806 (ref. 'CDISP') (Obsoleted by RFC 2183) ** Downref: Normative reference to an Experimental draft: draft-ietf-mixer-oda (ref. 'ODA') Summary: 22 errors (**), 1 flaw (~~), 16 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft X.400/MIME body mapping Feb 96 3 Mapping between X.400 and RFC-822/MIME Message Bodies 5 Tue Feb 20 14:12:47 MET 1996 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-04.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 describes the translation of message body 35 parts between X.400 and MIME. 37 Please send comments to the MIXER mailing list: 38 40 =0C 41 draft X.400/MIME body mapping Feb 96 43 1. Introduction 45 This document is a companion to [MIXER], which defines the 46 principles and translation of headers for interworking 47 between MIME-based RFC-822 mail and X.400 mail. 49 This document defines how to map body parts of X.400 50 messages into MIME entities and vice versa, including the 51 handling of multipart messages and forwarded messages. 53 A table of contents that should be quite useful for 54 locating specific sections is given in the back of the 55 document. 57 1.1. Glossary 59 The following terms are defined in this document: 61 Body part 62 Part of a message that has a unique type. This term 63 comes from X.400; the corresponding term in MIME (RFC 64 1521) is limited to use in parts of a multipart 65 message; the term "body" may correspond better. 67 Content-type 68 Type information indicating what the content of a 69 body part actually is. This term comes from MIME; the 70 corresponding X.400 term is "body part type". 72 Mapping 73 (noun): A description of how to transform an X.400 74 body part into a MIME body part, or how to transform 75 a MIME body part into an X.400 body part. 77 Equivalence 78 A set of two mappings that taken together provide a 79 lossless conversion between an X.400 body part and a 80 MIME body part 82 Encapsulation 83 The process of wrapping something from one of the 84 mail systems in such a way that it can be carried 85 inside the other mail system. When encapsulating, it 86 is not expected that the other mail system can make 88 =0C 89 draft X.400/MIME body mapping Feb 96 91 reasonable sense of the body part, but a gateway back 92 into the first system will always be able to convert 93 the body part without loss back to its original 94 format. 96 HARPOON encapsulation 97 The encapsulating of a MIME body part by putting it 98 inside an IA5 body with all headers and encoding 99 intact. First described in RFC 1496 (HARPOON). 101 Tunneling 102 What happens when one gateway encapsulates a message 103 and sends it to another gateway that decapsulates it. 104 The hope is that this will cause minimal damage to 105 the message in transit. 107 DISCUSSION 108 At many points in this document, the author has found 109 it useful to include material that explains part of 110 the reasoning behind the specification. These 111 sections all start with DISCUSSION: and continue to 112 the next numbered section heading; they do not 113 dictate any additional requirements on a gateway. 115 2. Basic rules for body part conversion 117 The basic approach for translating body parts is described 118 in section 2.1 and 2.2. 120 Chapter 3 gives details on "encapsulation", which allows 121 you to be certain that no information is lost even when 122 unknown types are encountered. 124 Chapter 6 gives the core mappings for various body parts. 126 The conformance requirements in chapter 8 describe what 127 the minimum conformance for a MIXER gateway is with 128 respect to body part conversion. 130 DISCUSSION: 132 At the moment (Sept 1995) both the MIME and the X.400 133 worlds are in a state of flux with regards to carrying 134 around stuff that is not text. 136 =0C 137 draft X.400/MIME body mapping Feb 96 139 In such a situation, there is little chance of defining a 140 mapping between them that is the best for all people, all 141 of the time. 142 For this reason, this specification allows a gateway 143 considerable latitude in deciding exactly what conversion 144 to apply. 146 The decision taken by the gateway may be based on various 147 information sources: 149 (1) If the gateway knows what body parts or content 150 types the recipient is able to handle, or has 151 registered a particular set of preferences for a 152 user, and knows how to convert the message 153 reasonably to those body parts, the gateway may 154 choose to convert body parts in the message to 155 those types only. 157 (2) If the gateway gets indications (via special 158 headers or heading-extensions defined for the 159 purpose) that the sender wanted a particular 160 representation on the "other side", and the gateway 161 is able to satisfy the request, it may do so. Such 162 a mechanism is defined in chapter 4 of this 163 document. 165 (3) If the gateway gets a message that might be 166 appropriate to send as one out of several types, 167 but where the typing information does not tell you 168 which one to use (like an X.400 BP14, FTAM "just a 169 file", or MIME application/octet-stream), it may 170 apply heuristics like looking at content or looking 171 at filenames to figure out how to deal with the 172 message. 174 (4) If the gateway knows that the next hop for the 175 message has limited capabilities (like X.400/84), 176 it may choose to perform conversions appropriate 177 for that medium. 179 (5) Where no mapping is known by the gateway, it may 180 choose to drop the body part, reject the message, 181 or encapsulate the body part as described in 182 chapter 3. The choice may be configurable, but a 183 conformant MIXER gateway MUST be able to be 185 =0C 186 draft X.400/MIME body mapping Feb 96 188 configured for encapsulation. 190 In many cases, a message that goes SMTP->X.400->SMTP will 191 arrive without loss of information. 193 In some cases, the reverse translation may not be 194 possible, or two gateways may choose to apply different 195 translations, based on the criteria above, leading to an 196 apparently inconsistent service. 198 In addition, service will vary because some gateways will 199 have implemented conversions not implemented by other 200 gateways. 202 This is believed to be unavoidable. 204 2.1. Generating the IPM Body from MIME 206 When converting the body of a message from MIME to X.400, 207 the following steps are taken: 209 If the header does not contain a 822.MIME-Version field, 210 then generate a IPMS.Body with a single IPMS.BodyPart of 211 type IPMS.IA5TextBodyPart with 212 IPMS.IA5TextBodyPart.parameters.repertoire set to the 213 default (IA5) containing the body of the RFC 822 message. 215 If 822.MIME-Version is present, the body is analyzed as a 216 MIME message and the body is converted according to the 217 mappings configured and implemented in the gateway. 219 2.2. Generating the MIME Body from the IPMS.Body 221 When converting the body of a message from X.400 to MIME, 222 the following steps are taken: 224 First, to support X.400(1984) mappings of Internet 225 Messages, the following procedure shall be followed. 227 If there is more than one body part, and the first body 228 part is IA5 starts with the string "RFC-822-Headers:" as 229 the first line, then the remainder of this body part shall 230 be appended to the RFC 822 header. This relies upon the 232 =0C 233 draft X.400/MIME body mapping Feb 96 235 theory that this body part has been generated according to 236 Appendix B of MIXER. A gateway shall check the 237 consistency and syntax of this body part, to ensure that 238 the resulting message is conformant with RFC 822. 240 If the remaining IPMS.Body consists of a single 241 IPMS.Bodypart, there are three possibilities. 243 (1) If it is of type IPMS.IA5Text, and the first line 244 is "MIME-Version: 1.0", it is assumed to be a 245 HARPOON-encapsulated message. The complete body 246 content is then appended to the headers; the 247 separating blank line is inside the message. If an 248 RFC 822 syntax error is discovered inside the 249 message, it may be mapped directly as described 250 below instead. 252 (2) If it is of type IPMS.IA5Text, then this is mapped 253 directly and no MIME encoding is used. 255 (3) All other types are mapped according to the 256 mappings configured and implemented in the gateway. 258 If the IPMS.Body contains multiple IPMS.Bodypart fields, 259 then a MIME message of content type multipart is 260 generated. If all of the body parts are messages, then 261 this is multipart/digest. Otherwise it is 262 multipart/mixed. The components of the multipart are 263 generated in the same order as in the IPMS.Body. 265 Each component is mapped according to the mappings 266 configured and implemented in the gateway; any IA5 body 267 parts are checked to see if they are HARPOON mappings. 269 =0C 270 draft X.400/MIME body mapping Feb 96 272 2.3. Mapping the EMA FTBP parameters 274 DISCUSSION: 276 EMA has defined a profile for use of the File Transfer 277 Body Part (FTBP). [MAWG] 279 New mappings are expected to use this as the mechanism for 280 carrying body parts, and since it is important to have a 281 consistent mapping for the special FTBP parameters, these 282 are defined here. 284 The mapping of the body will depend on the content-type in 285 MIME and on the application-reference in FTBP, and is not 286 specified here. 288 However, in many cases, we expect that the translation 289 will involve simply copying the octets from one format to 290 the other; that is, "no conversion". 292 2.3.1. Mapping GraphicStrings 294 Some parameters of the EMA Profile are encoded as ASN.1 295 GraphicStrings, which are troublesome because they can 296 contain any ISO registered graphic character set. 297 To map these to ASCII for use in mail headers, the gateway 298 may either: 300 (1) Use the RFC 1522 encoding mechanism to create 301 appropriate encoded-words for the headers involved. 302 Note that in some cases, such as within Content- 303 Disposition filenames, the encoded-words must be in 304 quotes, which is not the normal usage of encoded- 305 words. 307 (2) Apply the normalization procedure given in Appendix 308 A to identify the ASCII characters of the string, 309 and replace all non-ASCII characters with the 310 question mark (?). 312 =0C 313 draft X.400/MIME body mapping Feb 96 315 Both procedures are valid for MIXER gateways; the 316 simplified procedure of ignoring escape sequences and bit- 317 stripping the result is NOT valid. 319 2.3.2. Mapping specific parameters 321 The following parameters are mapped in both directions: 323 Content-ID 325 The mapping of this element is complex. 327 The Content-ID is encoded as an IPM.MessageIdentifier 328 and entered into the 329 FTBP.FileTransferParameters.related-stored-file. 330 file-identifier.cross-reference.message-reference. 332 FTBP.FileTransferParameters.related-stored-file. 333 relationship.descriptive-relationship is set to the 334 string "Internet MIME Body Part". 336 FTBP.FileTransferParameters.related-stored-file. 337 file-identifier.cross-reference.application- 338 crossreference is set to a null OCTET STRING. 340 The reverse mapping is only performed if the 341 FTBP.FileTransferParameters.related-stored-file. 342 relationship.descriptive-relationship has the string 343 value "Internet MIME Body Part". 345 Content-Description 347 This is mapped to and from the first string in 348 FTBP.FileTransferParameters.environment.user-visible- 349 string. 351 =0C 352 draft X.400/MIME body mapping Feb 96 354 Content-Disposition 356 This field is defined in [CDISP]. It has multiple 357 components; the handling of each component is 358 given below. 360 The "disposition" component is ignored on MIME -> 361 X.400 mapping, and is always "attachment" on X.400 -> 362 MIME mapping. 364 NOTE: RFC 1806 gives only the "filename" component. 365 The other components are expected to be added to the 366 next version of 1806. 368 C-D: filename 370 The filename component of the C-D header is mapped to 371 and from FileTransferParameters.file- 372 attributes.pathname. 374 The EBNF.disposition-type is ignored when creating 375 the FTBP pathname, and always set to "attachment" 376 when creating the Content-Disposition header. For 377 example: 379 Content-Disposition: attachment; filename=3D/var/joe/dodo.doc 381 The filename will be carried as a single incomplete- 382 pathname string. No special significance is assumed 383 for the chacracters "/" and "\". 385 This is done to be conformant with the EMA Profile. 387 C-D: Creation-date 389 Mapped to and from FileTransferParameters.file- 390 attributes.date-and-time-of-creation 392 C-D: Modification-date 394 =0C 395 draft X.400/MIME body mapping Feb 96 397 Mapped to and from FileTransferParameters.file- 398 attributes.date-and-time-of-last-modification 400 C-D: Read-date 402 Mapped to and from FileTransferParameters.file- 403 attributes.date-and-time-of-last-read-access 405 C-D: Size 407 Mapped to and from FileTransferParameters.file- 408 attributes.object-size. If the value is "no-value- 409 available", the component is NOT generated. 411 Other RFC-822 headers 413 Mapped to the second and subsequent elements of 414 FTBP.FileTransferParameters.environment.user-visible- 415 string. Headers are unfolded so that each header fits 416 within one user-visible-string component 417 (GraphicString does not allow CRLFs within the 418 string) 420 If no content-disposition header is present, the 421 first element is set to an empty string. 423 On reverse mapping, all components that conform to 424 the RFC 822 grammar are mapped to headers in the 425 bodypart. All other components are prefixed with one 426 or more blanks and added to the content-disposition 427 header, effectively making content-disposition a 428 multiline header. 430 EMA NOTE 432 The EMA profile, version 1.5, specifies that there 433 may only be a single component of 434 FTBP.FileTransferParameters.environment.user-visible- 435 string. 437 =0C 438 draft X.400/MIME body mapping Feb 96 440 The IETF MIXER group suggests that EMA reconsiders 441 this decision, and allows multiple strings in the 442 next version of its profile, since this will allow a 443 needed extension mechanism to function in the 444 presence of profile-only APIs. 446 If a gateway suspects that a recipient is behind a gateway 447 that is not able to process multiple components of the 448 user-visible-string, it MAY choose to omit the extra 449 headers. This will lead to a lossy conversion; the gateway 450 MAY choose to encapsulate using a non-FTBP mechanism 451 instead. 453 2.3.3. Summary of FTBP elements generated 455 This is a summary of the preceding section, and does not 456 add new information. 458 The following elements of the FTBP parameters are mapped 459 or used: 461 FileTransferParameters M/= 462 M 463 Related-Stored-File O/= 464 O 465 file-identifier 466 cross-reference 467 application-crossreference NULL 468 message-reference Content-ID 469 descriptive-relationship Used as marker 470 contents-type Must be unstructured-binary M/= 471 M 472 environment M/= 473 M 474 application-reference Selects mapping M/= 475 M 476 user-visible-string Content-description R/= 477 M 478 file-attributes 479 pathname C-D: Filename R/= 480 M 481 date-and-time-of-creation C-D: Creation-Date O/= 482 O 483 date-and-time-of-last-modification C-D: Modification-Date R/= 484 M 485 date-and-time-of-last-read-access C-D: Read-Date O/= 486 O 487 object-size C-D: Size R/= 488 M 490 All other elements of the FTBP parameters are discarded. 492 =0C 493 draft X.400/MIME body mapping Feb 96 495 NOTE: There is ongoing work on defining a more complete 496 mapping between FTBP headers and a set of RFC-822 headers. 497 A gateway MAY choose to support the larger set once it is 498 available, but MUST support this limited set. 500 2.4. Information that is lost when mapping 502 MIME defines fields which add information to MIME 503 contents. Two of these are "Content-ID", and "Content- 504 Description", but MIME allows new entities to be defined 505 at any time. 507 The possibilities are limited about what one can do with 508 this information: 510 (1) When using encapsulation, the information can be 511 preserved 513 (2) When using mapping to FTBP, the information can be 514 preserved in the environment.user-visible-string 516 (3) When mapping to a single-body message, the 517 information can be preserved as P22 header 518 extensions 520 (4) When mapping to other body part types, the 521 information must be discarded. 523 3. Encapsulation of body parts 525 Where no mapping is possible, the gateway may choose any 526 of the following alternatives: 528 - Discard the body part, leaving a "marker" saying what 529 happened 531 - Reject the message 533 - "Encapsulate" the body part, by wrapping it in a body 534 part defined for that purpose in the other mail 535 system 537 =0C 538 draft X.400/MIME body mapping Feb 96 540 The choice to be made should be configurable in the 541 gateway, and may depend on both policy and knowledge of 542 the recipient's capabilities. 544 3.1. Encapsulation of MIME in X.400 546 Four body parts are defined here to encapsulate MIME body 547 parts in X.400. 549 The BP15 body part is backwards compatible with RFC 1494. 550 The FTBP body part is compatible with the EMA MAWG 551 document [MAWG], version 1.5, apart from the issue on 552 user-visible-string noted above. 554 The imagined scenarios for each body part are: 556 BP15 For use when tunnelling MIME to a MIME UA through an 557 X.400(88) network, or to UAs that have been written 558 to RFC 1494 560 FTBP For use when sending to recipients that can handle 561 generic FTBP, and for tunnelling MIME to a MIME UA 563 IA5 For use when tunneling MIME to a MIME UA through an 564 X.400 network, where some of the links may involve 565 X.400(84). 567 BP14 For use when the recipient may be an X.400(84) UA 568 with BP14 handling capability, and the loss of 569 information in headers is not regarded as important. 571 but the gateway is free to use any method it finds 572 appropriate in any situation. 574 3.1.1. BP15 encapsulating body part 576 This section defines an extended body part, based on body 577 part 15, which may be used to hold any MIME content. 579 mime-body-part EXTENDED-BODY-PART-TYPE 580 PARAMETERS MimeParameters 581 IDENTIFIED BY id-mime-bp-parameters 583 =0C 584 draft X.400/MIME body mapping Feb 96 586 DATA OCTET STRING 587 ::=3D id-mime-bp-data 589 MimeParameters ::=3D 590 SEQUENCE { 591 content-type IA5String, 592 content-parameters SEQUENCE OF 593 SEQUENCE { 594 parameter IA5String,= 596 parameter-value IA5String 597 } 598 other-header-fields RFC822FieldList 599 } 601 The OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime- 602 bp-data are defined in Appendix B. A MIME content is 603 mapped onto this body part. The MIME headers of the body 604 part are mapped as follows: 606 Content-Type: 607 The "type/subtype" string is mapped to 608 MimeParameters.content-type. 610 For each "parameter=3Dvalue" string create a 611 MimeParameters.content-parameters element. The 612 MimeParameters.content-Parameters.parameter field is 613 set to the parameter and the MimeParameters.content- 614 parameters.parameter-value field is set to the value. 616 Other 617 Take all other headers and create 618 MimeParameters.other-header-fields, by concatenating 619 them together. 621 The body is mapped as follows: 623 Convert the MIME body part into its canonical form, as 624 specified in Appendix H of MIME [MIME]. This canonical 625 form is used to generate the mime-body-part.data octet 626 string. 628 The Parameter mapping may be used independently of the 630 =0C 631 draft X.400/MIME body mapping Feb 96 633 body part mapping (e.g., in order to use a different 634 encoding for a mapped MIME body part). 636 This body part contains all of the MIME information, and 637 so can be mapped back to MIME without loss of information. 639 The OID id-mime-bp-data is added to the Encoded 640 Information Types of the envelope. 642 This body part is completely compatible with RFC 1494. 644 3.1.2. FTBP encapsulating body part 646 This body part utilizes the fundamental assumption in MIME 647 that all message content can be legally and completely 648 represented by a single octet stream, the "canonical 649 format". 651 The FTBP encapsulating body part is defined by the 652 application-reference id-mime-ftbp-data; all headers are 653 mapped to the FTBP headers, including putting the 654 "Content-type:" header inside the UserVisibleString. 656 Translation from the MIME body part is done by: 658 - Undoing the content-transfer-encoding 660 - Setting the "FileTransferData.FTdata.value.octet- 661 aligned" to the resulting string of octets 663 - Putting the appropriate parameters into the headers. 665 Reversing the translation is done by: 667 - Extracting the headers 669 - Applying an appropriate content-transfer-encoding to 670 the body. If this is for some reason different from 671 the content-transfer-encoding: header retrieved from 672 the headers, the old one must be deleted. 674 This mapping is lossless, and therefore counts as "no 675 conversion". 677 =0C 678 draft X.400/MIME body mapping Feb 96 680 3.1.3. Encapsulation using IA5 (HARPOON) 682 This approach is the one taken in RFC 1496 - HARPOON - for 683 tunneling any MIME body part through X.400/84 networks. It 684 has proven rather unhelpful for bringing information to 685 X.400 users, but preserves all the information of a MIME 686 body part. 688 The following IA5Text body part is made: 690 - Content =3D IA5String 692 - First bytes of content: (the description is in US 693 ASCII, with C escape sequences used to represent 694 control characters): 696 MIME-version: \r\n 697 Content-type: \r\n 698 Content-transfer-encoding: \r\n 699 700 \r\n 701 704 All implementations MUST place the MIME-version: header 705 first in the body part. Headers that are placed by [MIXER] 706 into other parts of the message MUST NOT be placed in the 707 MIME body part. 709 3.1.4. Content passing using BP14 711 This is described in this section because it is at the 712 same conceptual level as encapsulation. It is a lossy 713 transformation; it is impossible to reconstruct the MIME 714 type information from it. 716 Nevertheless, there is a demand for such functionality. 718 This "encapsulation" simply strips off all headers, undoes 719 the content-transfer-encoding, and creates a 720 BilaterallyDefined body part (BP14) from the resulting 721 octet stream. 723 =0C 724 draft X.400/MIME body mapping Feb 96 726 No reverse translation is defined; when a BP14 arrives at 727 a MIXER gateway, it will be turned into an 728 application/octet-stream according to chap. 6.3 730 3.2. Encapsulating X.400 Body Parts in MIME 732 This section specifies a generic mechanism to map X.400 733 body parts to a MIME content. This allows for the body 734 part to be tunneled through MIME. It may also be used 735 directly by an appropriately configured MIME UA. 737 This content-type is defined to carry any X.400 extended 738 body part. The mapping of all standard X.400 body parts 739 is defined in RFC1494bis. The content-type field is 740 "application/x400-bp". The parameter is defined by the 741 EBNF: 743 mime-parameter =3D "bp-type=3D" object-identifier 745 The EBNF.object-identifier is set to the OBJECT IDENTIFIER 746 from IPMS.body.externally-defined.data.direct-reference. 748 For example, a Videotex body part will have 750 Content-type=3Dapplication/x400-bp; bp-type=3D2.6.1.4.5 752 The body contains the raw ASN.1 IPM.body octet stream, 753 including the initial tag octet. The content may use a 754 content- transfer-encoding of either base64 or quoted- 755 printable when carried in 7-bit MIME. It is recommended 756 to use the one which gives the more compact encoding of 757 the data. If this cannot be determined, Base64 is 758 recommended. No attempt is made to turn the parameters of 759 Extended Body Parts into MIME parameters, as this cannot 760 be done in a general manner. 762 Standard X.400 body parts may not be encoded directly by 763 this mechanism, but may be encoded indirectly by first 764 translating to the extended representation. 766 =0C 767 draft X.400/MIME body mapping Feb 96 769 3.3. Encapsulating FTBP body parts in MIME 771 The File Transfer Body Part is believed to be important in 772 the future as "the" means of carrying well-identified data 773 in X.400 networks. 775 They also share the property (at lest when limited to the 776 EMA MAWG functional profile) of having a well-defined data 777 part that is always representable as a sequence of bytes. 779 This conversion will have to fail, and the x400-bp 780 encapsulation used instead, if: 782 - FileTransferData has more than one element 784 - Contents-type is not unstructured-binary 786 - Parameters that are not mappable, but important, are 787 present (like Compression, which EMA doesn't 788 recommend). 790 Otherwise, it can be encapsulated in X.400 by: 792 - Creating the "content-type" value by forming the 793 string "application/x-ftbp." and appending the 794 numbers of the OID 796 - Mapping all other parameters according to the 797 standard FTBP parameter mapping 799 - Applying an appropriate content-transfer-encoding 801 DISCUSSION: 803 The choice of the somewhat strange, and by necessity 804 unregistered, MIME type "application/x-ftbp.n.n.n.n" is 805 because for any concrete example of this usage, it will be 806 easy to configure any MIME reader to take advantage of the 807 identification. If the MIME type registration rules are 808 ever changed to allow the registration of a namespace, 809 rather than just of names, the "x-" can be deleted, and 810 the types can be "application/ftbp.n.n.n.n". 812 =0C 813 draft X.400/MIME body mapping Feb 96 815 4. User control over the gateway choice 817 In some cases, the gateway may make an inappropriate 818 choice when deciding what to do about a particular body 819 part. 821 To allow an escape clause, this chapter defines a way in 822 which the user can signal the gateway what action it finds 823 most appropriate. 825 The headers given here override any "conversion 826 prohibited" and "conversion with loss prohibited" on the 827 message. 829 It is still the gateway's responsibility that the 830 generated messages conform to the destination domain's 831 syntax rules. 833 DISCUSSION: 835 The intent of this mechanism is to allow the sender to 836 efficiently get a message through to a single recipient 837 when the sender has information about the recipient that 838 the gateway does not have. 840 It is not a part of the minimum functionality listed in 841 chapter 8; a gateway does not have to implement this spec 842 to be MIXER conformant, but if implemented, it should be 843 done like this. 845 The additional complexity, both in user interface and in 846 protocol, of making this field selectable per recipient 847 was not thought worthwhile; 849 4.1. Conversion from MIME to X.400 851 The header field described below specifies explicit MIXER 852 conversion. Comments are allowed within the field 853 according to the usual RFC 822 convention. 855 If "x400-object-id" is omitted, "tunnel" is assumed. 857 mime-to-x400 =3D "Wanted-X400-Conversion" ":" 859 =0C 860 draft X.400/MIME body mapping Feb 96 862 [ mime-from ] [ x400-object-id ] 863 "in" x400-encoding 865 x400-object-id =3D "to" ( object-identifier-2 / "tunnel" ) 866 x400-encoding =3D "bp14" / "bp15" / "ftbp" / "ia5" 867 mime-from =3D "from" mime-type 868 mime-type =3D word 870 There is no way to ask for a different conversion based on 871 MIME parameters or bodypart content. 873 Examples: 875 Wanted-X400-Conversion: from application/msword 876 to 1.2.840.113556.4.2 (Microsoft defined ms-word) 877 in ftbp 879 This uses the MAWG definitions, and leads to an FTBP encoding. 881 Wanted-X400-Conversion: from application/msword 882 to tunnel in bp14 884 This leads to a Body Part 14 encoding for all body parts of type 885 application/msword. 887 Wanted-X400-Conversion: in bp14 889 This requests that this specific body part be encoded in Body Part 14= 890 =2E 892 This field may be used in two places: 894 (1) In the heading of an unstructured MIME body part. 895 In this case the EBNF.mime-from is omitted, and the 896 requested conversion applies to the body part. 898 (2) In a multipart. In this case, the body part type to 899 which the conversion applies is defined by 900 EBNF.mime-from, and the conversion applies to all 901 body parts of this MIME type contained in the 902 multipart, including those contained in nested 903 messages and multiparts. If a contained body part 904 has its own heading, this takes precedence. Note 906 =0C 907 draft X.400/MIME body mapping Feb 96 909 that the "from" parameter is mandatory when used in 910 a multipart. 912 The EBNF.x400-object-id shall be present when "bp15" or 913 "ftbp" encoding is selected. 915 The value "tunnel" implies encapsulation as defined in 916 Chapter 3. 918 The "object identifier" used below is: 920 - For BP 15, it is the value of the EXTENDED-BODY-PART- 921 TYPE macro that defines the body part, which is found 922 in ExternallyDefinedBodyPart.data.direct-reference. 924 - For FTBP, it is the value of the 925 Environment.application-reference. 927 4.2. Conversion from X.400 to MIME 929 The IPM heading defined here shall be present in the 930 heading of a message. It defines the mapping for all body 931 parts of the specified types, including those in nested 932 messages. 934 wanted-MIME-conversion HEADING-EXTENSION 935 VALUE WantedMIMEConversions 936 ::=3D id-wanted-MIME-conversions 938 WantedMIMEConversions ::=3D SEQUENCE OF X400toMIMEConversion 940 X400toMIMEConversion ::=3D SEQUENCE { 941 x400-type X400Type, 942 mime-type MIMEType } 944 X400Type ::=3D CHOICE { 945 standard [0] INTEGER, -- standard body part 946 extended [1] OBJECT IDENTIFIER, -- BP 15 947 ftbp [2] OBJECT IDENTIFIER} -- FTBP application-refer= 948 ence 950 =0C 951 draft X.400/MIME body mapping Feb 96 953 MIMEType ::=3D SEQUENCE { 954 type IA5String, -- type (e.g., application/ms-word) 955 encoding [1] IA5String OPTIONAl -- e.g. quoted-printable 956 parameters [2] IA5String OPTIONAL } -- MIME Parameters 958 The heading extension includes all requested conversions, 959 with explicit information as to how each body part type is 960 encoded in MIME. 962 FTBP is identified as a separate body part type, as there 963 will be a need for different encodings, dependent on what 964 is being carried. 966 Encapsulation is requested by asking for 967 "application/x400-bp" or "application/ftbp" as the 968 destination type. 970 For FTAM body parts, the parameters will survive the 971 gatewaying process. For other body parts, there are three 972 alternatives: 974 (1) The gateway knows a defined mapping for this 975 particular body part and destination type. It will 976 be used, and parameters mapped accordingly. 978 (2) The gateway knows how to extract an OCTET STRING 979 from the body part, and the destination is a simple 980 MIME body part. All information outside the OCTET 981 STRING is lost. (This may be the case for a BP14 982 that should end up in an application/xyzzy, for 983 instance). 985 (3) The gateway knows of no relevant mapping, and does 986 not know how to simplify the X.400 body part. The 987 gateway will then proceed as if the mapping control 988 field had not been present. 990 5. The equivalence registry 992 5.1. What information one must give about a mapping 994 The following information MUST be supplied when describing 995 an equivalence or a mapping: 997 =0C 998 draft X.400/MIME body mapping Feb 96 1000 MIME type name (which must be preregistered) 1002 X.400 body part (often BP15 or FTAM Body Part) 1004 If BP15 is used, the following information must be given: 1006 (1) Object Identifier for X.400 BP15 Data 1008 (2) Object Identifier for X.400 BP15 Parameters 1010 (3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART- 1011 TYPE macro) 1013 If FTBP is used, the following information must be given: 1015 (1) Object Identifier for the FTAM 1016 Environment.application-reference 1018 (2) Object Identifier for the FTAM Contents-type, if 1019 unstructured-binary is not used 1021 (3) Any other special considerations 1023 In all cases, the following must be given: 1025 Conversion algorithms. The expected effect of "Conversion 1026 prohibited" and "Conversion with loss prohibited" should 1027 be noted. 1029 The conversion must be specified with enough detail to 1030 permit independent implementation; literature references 1031 are acceptable. 1033 An equivalence can be registered with IANA using the form 1034 at the end of this document. The purpose of the 1035 registration is to achieve a greater uniformity among 1036 gateways implementing the same translation; there is no 1037 requirement that a gateway must support all of the 1038 translations that are registered with IANA. Specific 1039 conformance requirements for MIXER are given at the end of 1040 this document. 1042 =0C 1043 draft X.400/MIME body mapping Feb 96 1045 5.2. Equivalence summary for known X.400 and MIME Types 1047 This section itemizes the equivalences for all currently 1048 known MIME content-types and X.400 body parts. 1050 For each MIME content-type/X.400 body part pair, the 1051 equivalence table contains an entry with the following 1052 sections: 1054 X.400 Body Part 1055 This section identifies the X.400 Body Part governed 1056 by this Table entry. It includes any OBJECT 1057 IDENTIFIERs or other parameters necessary to uniquely 1058 identify the Body Part. 1060 MIME Content-Type 1061 This section identifies the MIME content-type 1062 governed by this Table entry. The MIME content-type 1063 named here must be registered with the IANA. 1065 Section/document reference 1066 Reference to section of this document, or to the 1067 other document that describes this mapping. 1069 The initial Equivalence Table entries in this document are 1070 described using this convention. 1072 Further registrations of equivalences should be submitted 1073 to the IANA after a public review, using the example form 1074 given at the end of this document. 1076 5.3. MIME to X.400 Table 1078 MIME content-type X.400 Body Part Section 1079 ----------------- ------------------ ------- 1080 text/plain 1081 charset=3Dus-ascii ia5-text 6.1 1082 charset=3DISO-8859-x EBP - GeneralText 6.2 1083 text/richtext no mapping defined Encap 1084 application/oda EBP - ODA [ODA] 1086 =0C 1087 draft X.400/MIME body mapping Feb 96 1089 application/octet-stream bilaterally-defined or 6.3 1090 FTBP unknown attachment 6.4 1091 application/postscript EBP - mime-postscript-body [POSTSCRIPT] 1092 image/g3fax g3-facsimile [IMAGES] 1093 image/jpeg EBP - mime-jpeg-body [IMAGES] 1094 image/gif EBP - mime-gif-body [IMAGES] 1095 audio/basic no mapping defined Encap 1096 video/mpeg no mapping defined Encap 1097 message/RFC822 ForwardedIPMessage 6.5 1098 multipart/* ForwardedIPMessage 6.6 1100 Abbreviation: EBP - Extended Body Part 1102 5.4. X.400 to MIME Table 1103 Basic Body Parts 1105 X.400 Basic Body Part MIME content-type Section 1106 --------------------- -------------------- ------- 1107 ia5-text text/plain;charset=3Dus-ascii 6.1 1108 voice No Mapping Defined Encap 1109 g3-facsimile image/g3fax [IMAGES] 1110 g4-class1 no mapping defined Encap 1111 teletex text/plain;charset=3Dteletex 6.7 1112 videotex no mapping defined Encap 1113 encrypted no mapping defined Encap 1114 bilaterally-defined application/octet-stream 6.3 1115 nationally-defined no mapping defined Encap 1116 externally-defined See Extended Body Parts below 1117 ForwardedIPMessage message/RFC822 or multipart 6.5,6.6 1119 X.400 Extended Body Part MIME content-type Section 1120 ------------------------- -------------------- ------- 1121 GeneralText text/plain;charset=3DISO-8859-x 6.2 1122 ODA application/oda [ODA] 1123 mime-postscript-body application/postscript [POSTSCRIPT= 1124 ] 1125 mime-jpeg-body image/jpeg [IMAGES] 1126 mime-gif-body image/gif [IMAGES] 1127 FTAM various 2.3,6.4 1129 FTAM application ID MIME content type Section 1130 ------------------- ----------------- ------- 1131 ema-unknown-attachment application/octet-stream 6.4 1133 =0C 1134 draft X.400/MIME body mapping Feb 96 1136 5.5. Use of OBJECT IDENTIFIERs and ASN.1 MACROS 1138 When one wants to define new BP15 body parts for use with 1139 equivalences, it is important to know that X.420 dictates 1140 that Extended Body Parts shall: 1142 (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify 1143 the contents, and 1145 (2) be defined by using the ASN.1 Macro: 1147 EXTENDED-BODY-PART-TYPE MACRO::=3D 1148 BEGIN 1149 TYPE NOTATION ::=3D Parameters Data 1150 VALUE NOTATION ::=3D value (VALUE OBJECT IDENTIFIER) 1152 Parameters ::=3D "PARAMETERS" type "IDENTIFIED" 1153 "BY" value(OBJECT IDENTIFIER) 1154 | empty; 1155 Data ::=3D "DATA" type 1156 END 1158 To meet these requirements, this document uses the OID 1160 mixer 1162 defined in [MIXER], as the root OID for X.400 Extended 1163 Body Parts defined for MIME interworking. 1165 Each Extended Body Part contains Data and optional 1166 Parameters, each being named by an OID. To this end, two 1167 OID subtrees are defined under mixer-bodies, one for Data, 1168 and the other for Parameters: 1170 mixer-bp-data OBJECT IDENTIFIER ::=3D 1171 { mixer 1 } 1173 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 1174 { mixer 2 } 1176 All definitions of extended X.400 body parts submitted to 1177 the IANA for registration with a mapping must use the 1178 Extended Body Part Type macro for the definition. See 1179 [IMAGES] for an example. 1181 =0C 1182 draft X.400/MIME body mapping Feb 96 1184 Lastly, the IANA will use the mixer-bp-data and mixer-bp- 1185 parameter OIDs as root OIDs for any new MIME content- 1186 type/subtypes that aren't otherwise registered in the 1187 Equivalence Table. 1189 NOTE: The ASN.1 for an ExternallyDefinedBodyPart is 1191 ExternallyDefinedBodyPart ::=3D SEQUENCE { 1192 parameters [0] ExternallyDefinedParameters OPTIONAL, 1193 data ExternallyDefinedData } 1195 ExternallyDefinedParameters ::=3D EXTERNAL 1197 ExternallyDefinedData ::=3D EXTERNAL 1199 The ASN.1 for EXTERNAL is (from X.208): 1201 EXTERNAL ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE 1202 {direct-reference OBJECT IDENTIFIER OPTIONAL, 1203 indirect-reference INTEGER OPTIONAL, 1204 data-value-descriptor ObjectDescriptor OPTIONAL, 1205 encoding CHOICE 1206 {single-ASN1-type [0] ANY, 1207 octet-aligned [1] IMPLICIT OCTET STRING, 1208 arbitrary [2] IMPLICIT BIT STRING}} 1210 ObjectDescriptor ::=3D [UNIVERSAL 7] IMPLICIT GraphicString 1212 There are a bit too many choices here; the common X.400 1213 usage for BP15 encoding is to: 1215 (1) Always use direct-reference 1217 (2) Omit indirect-reference and data-value-descriptor 1219 (3) Use the single-ASN1-type encoding only 1221 Unfortunately, some implementations have chosen to use the 1222 octet-aligned choice when constructing values where the 1223 ASN.1 type is OCTET STRING, which of course caused 1224 interoperability problems. 1226 An attempt to specify that X.420 only allowed the single- 1227 ASN1-type choice in the 1996 versions is still (Sept 1995) 1228 being debated in ISO; the end result seems to be that all 1230 =0C 1231 draft X.400/MIME body mapping Feb 96 1233 agree in principle that single-ASN1-type should be used, 1234 but that one has to allow the generation of the octet- 1235 aligned choice as being conformant. 1237 6. Defined Equivalences 1239 6.1. IA5Text - text/plain 1241 X.400 Body Part: IA5Text 1242 MIME Content-type: text/plain; charset=3DUS-ASCII 1243 Conversion Type: No conversion 1244 Comments: 1246 When mapping from X.400 to MIME, the "repertoire" 1247 parameter is ignored. 1249 When mapping from MIME to X.400, the "repertoire" 1250 parameter is set to IA5 (5). 1252 NOTE: The MIME Content-type headers are omitted, when 1253 mapping from X.400 to MIME, if and only if the IA5Text 1254 body part is the only body part in the IPMS.Body sequence. 1256 NOTE: IA5Text specifies the "currency" symbol in position 1257 2/4. This is converted without comment to the "dollar" 1258 symbol, since the author of this document has seen many 1259 documents in which the position was intended to indicate 1260 "dollar" while he has not yet seen one in which the 1261 "currency" symbol is intended. 1263 (For reference: The T.50 (1988) recommendation, which 1264 defines IA5, talks about ISO registered set number 2, 1265 while ASCII, using the "dollar" symbol, is ISO registered 1266 set number 6. There are no other differences.) 1268 NOTE: It is not uncommon, though it is a violation of the 1269 standard, to use 8-bit character sets inside an IA5 body 1270 part. Gateways that can expect to encounter this situation 1271 should consider implementing something like the guidance 1272 given in RFC 1428, "Transition of Internet Mail from just- 1273 send-8 to 8-bit SMTP/MIME", and generate appropriate 1274 charset parameters for the MIME messages they generate. 1276 =0C 1277 draft X.400/MIME body mapping Feb 96 1279 This behavior is not required for MIXER conformance, since 1280 it is only needed when the base standards are violated. 1282 6.2. GeneralText - text/plain (ISO-8859) 1284 X.400 Body Part: GeneralText; CharacterSets in 1285 6,100,101,109,110,126,127,138,144,148 1286 MIME Content-Type: text/plain; charset=3DISO-8859-(1-9) 1287 Conversion Type: Text conversion without character change 1288 When mapping from X.400 to MIME, the character-set is 1289 chosen from the table below according to the value of 1290 Parameters.CharacterSets. If no match is found, and the 1291 gateway does not support a conversion, the character set 1292 shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the 1293 numbers of the Parameters.CharacterSets, sorted in numeric 1294 order. 1296 When mapping from MIME to X.400, GeneralText is an 1297 Extended Body Part, hence it requires an OID. The OID for 1298 the GeneralText body is defined in [MOTIS], part 8, annex 1299 D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1 1300 11 11}. 1302 The Parameters.CharacterSets is set from table below 1303 according to the value of "charset" 1305 The following table lists the MIME character sets and the 1306 corresponding ISO registry numbers. If no correspondence 1307 is found, this conversion fails, and the generic body part 1308 approach is used. 1310 MIME charset ISO IR numbers Comment 1311 ----------------------------------------------- 1312 ISO-8859-1 6, 100 West European "8-bit ASCII" 1313 ISO-8859-2 6, 101 East European 1314 ISO-8859-3 6, 109 1315 ISO-8859-4 6, 110 1316 ISO-8859-5 6, 144 Cyrillic 1317 ISO-8859-6 6, 127 Arabic 1318 ISO-8859-7 6, 126 Greek 1319 ISO-8859-8 6, 138 Hebrew 1320 ISO-8859-9 6, 148 Other Latin-using languages 1321 ISO-2022-JP 6, 14, 42, 87 Japanese 1323 =0C 1324 draft X.400/MIME body mapping Feb 96 1326 When converting from MIME to X.400, generate the correct 1327 OIDs for use in the message envelope's Encoded Information 1328 Types by looking up the ISO IR number in the above table, 1329 and then appending it to the id-cs-eit-authority {1 0 1330 10021 7 1 0} OID. 1332 The escape sequences to designate and invoke the relevant 1333 character sets in their proper positions must be added to 1334 the front of the GeneralText character string. 1336 For ISO 8859-1, the relevant escape sequence will be: 1338 ESC 28 42 1339 ASCII in G0 1341 ESC 2D 41 1342 ISO-IR-100 in G1 1344 ESC 21 41 1345 High control character set in C1 1347 ESC 7E 1348 Locking shift 1 Right 1350 DISCUSSION: 1352 The conversion of text is a problematic one, and one in 1353 which it is likely that gateways should be given wide 1354 latitude to make decisions based upon their knowledge of 1355 the user's preferences. The text given below is thought to 1356 give the best approximation to a gateway conforming to 1357 current and anticipated usage in the MIME and X.400 1358 worlds, and is the way recommended when no knowledge of 1359 the recipient's capabilities exists. 1361 The changes, such as normalizing escape sequences, should 1362 not be done when "conversion-prohibited" is set. If 1363 "conversion-with-loss-prohibited" is set, translation to a 1364 character set that is not able to encode all characters 1365 cannot be done, and the message should be non-delivered 1366 with an appropriate non-delivery reason. 1368 The common use of character sets in MIME is somewhat 1369 different from the rules given by X.400; in particular, it 1371 =0C 1372 draft X.400/MIME body mapping Feb 96 1374 is common in MIME to assume that the character sets follow 1375 strict rules. For the ISO-8859-x character sets, it is 1376 assumed that they are designated and invoked at the 1377 beginning of the text, and that no designation or 1378 invocation sequences occur within the body of the text. 1379 The rules for ISO-2022-JP are given in RFC 1468, and are 1380 even more particular, using a pure 7-bit encoding in which 1381 each line of text starts in ASCII. 1383 Therefore, the text must be "normalized" by going through 1384 the whole message, using a state machine or similar device 1385 to remove all escape and shift sequences. 1387 Appendix A gives pseudocode for such a conversion. 1389 NOTE: In 1988, the GeneralText body part was defined in 1390 ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT 1391 recommendation; this was added later. Also, the 1392 parameters have been heavily modified; they should be a 1393 SET OF INTEGER in the currently valid text. Use the 1394 latest version of the standard that you can get hold of. 1396 6.3. BilaterallyDefined - application/octet-stream 1398 X.400 Body Part: BilaterallyDefined 1399 MIME Content-Type: Application/Octet-Stream (no parameters) 1400 Conversion Type: No conversion 1402 When mapping from MIME to X.400, if there are parameters 1403 present in the Content-Type: header field, they are 1404 removed. 1406 DISCUSSION: 1408 The parameters "name" "type" and "conversions" are 1409 advisory; name and conversions are depreciated in RFC 1410 1521. 1412 The parameter "padding" changes the interpretation of the 1413 last byte of the data, but it is deemed better by the WG 1414 to delete this information than to non-deliver the body 1415 part. The "padding" parameter is rarely used with MIME. 1417 =0C 1418 draft X.400/MIME body mapping Feb 96 1420 Use of BilaterallyDefined Body Parts is specifically 1421 deprecated in both 1988 and 1992 X.400. It is retained 1422 solely for backward compatibility with 1984 systems, and 1423 because it is in common use. 1425 6.4. FTBP EMA Unknown Attachment - 1426 application/octet-stream 1427 X.400 Body Part: FTBP EMA Unknown Attachment 1428 MIME Content-Type: Application/Octet-Stream 1429 Conversion Type: No conversion 1431 The OID for the Unknown Attachment is { iso(1) 1432 countries(2) usa(840) organization (1) ema (113694) 1433 objects(2) messaging(2) attachments(1) unknown (1)}, or 1434 1.2.840.1.113694.2.2.1 for short. 1436 The parameters for this type must be mapped according to 1437 chapter 2.3, with the following extensions for the 1438 parameters of the application/octet-stream: 1440 If there is no Content-Disposition parameter with a 1441 filename, and there is a name parameter, the 1442 FTBP.FileTransferParameters.File-attributes.pathname 1443 is generated from this parameter. Note that RFC 1521 1444 recommends not using the "name" parameter. 1446 The "type", "conversions" and "padding" attributes are 1447 ignored; "type" is for human consumption; "conversions" 1448 are discouraged in RFC 1521. 1450 The body mapping is just copying the bytes in both 1451 directions. 1453 6.5. MessageBodyPart - message/RFC822 1455 X.400 body part: MessageBodyPart 1456 MIME Content-Type: message/RFC822 1457 Conversion Type: Special 1459 NOTE: If the headers of the X.400 MessageBodyPart contains the 1460 "multipart-message" heading extension with the isAMessage bit set 1461 (either explicitly or implicitly), the mapping should be to 1463 =0C 1464 draft X.400/MIME body mapping Feb 96 1466 multipart/* according to section 6.6, below. 1468 To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 1469 mapping is recursively applied, to generate an RFC 822 Message. 1470 If present, the IPMS.MessageBodyPart.parameters.delivery-envelope 1471 is used for the MTS Abstract Service Mappings. If present, the 1472 IPMS.MessageBodyPart.parameters.delivery-time is mapped to the 1473 extended RFC 822 field "Delivery-Date:". 1475 When a message/RFC822 is contained within a MIME message, it is 1476 mapped to an IPMS.MessageBodyPart according to MIXER. 1477 specification. Any mappings that would have been made to the MTS 1478 Abstract Service are placed in 1479 IPMS.MessageBodyPart.parameters.delivery-envelope. 1481 6.6. MessageBodyPart - multipart/* 1483 X.400 body part: MessageBodyPart 1484 MIME Content-Type: multipart/* 1485 Conversion Type: Special 1487 NOTE: If the headers of the X.400 MessageBodyPart do not contain the 1488 "multipart-message" heading extension with the "isAMessage" flag FALS= 1489 E, 1490 the mapping should be to message/RFC822. 1492 A MIME multipart is a set of content-types and not a message with 1493 a set of content types. When the multipart is at the outermost 1494 MIME header and is either multipart/digest or multipart/mixed, 1495 elements of the multipart are mapped directly onto IPMS.Bodypart. 1496 In other cases, a MIME multipart is mapped to an 1497 IPMS.MessageBodyPart containing an IPMS.Bodypart for each element 1498 of the multipart. 1500 When a nested IPMS.Message is generated from a multipart, an 1501 IPMS.heading shall always be generated. The only mandatory field 1502 is the IPMS.Heading.this-IPM message id, which shall be generated 1503 by the gateway. An IPMS.Heading.subject field shall also be 1504 generated, in order to provide useful information to non-MIME 1505 capable X.400(88) UAs and to all X.400(84) UAs. The subject 1506 field is set as follows according to the multipart subtype: 1508 mixed: 1509 "Multipart Message" 1511 =0C 1512 draft X.400/MIME body mapping Feb 96 1514 alternative: 1515 "Alternative Body Parts containing the same 1516 information" 1518 digest: 1519 "Message Digest" 1521 parallel: 1522 "Body Parts interpreted in parallel" 1524 other: 1525 "Multipart Message ()" 1527 For other types of multipart, the multipart subtype shall 1528 be included in the subject line. 1530 For each multipart, the following IPMS.HeadingExtension 1531 shall be generated, with the value set according to the 1532 subtype: 1534 multipart-message HEADING-EXTENSION 1535 VALUE MultipartType 1536 ::=3D id-hex-multipart-message 1538 MultipartType ::=3D SEQUENCE { 1539 subtype IA5String, 1540 isAMessage BOOLEAN DEFAULT TRUE } 1542 The MultipartType contains the subtype, for example 1543 "digest". If this heading is present when mapping from 1544 X.400 to MIME, the appropriate multipart may be generated. 1546 The isAMessage flag is needed because of the case where a 1547 message contains a ForwardedIPMessage, which itself was 1548 generated from a MIME message that was a Multipart; it is 1549 set whenever the multipart is the outermost level of 1550 nesting inside a Message/RFC822. 1552 6.7. Teletex - Text/Plain (Teletex) 1554 X.400 Body Part: Teletex 1555 MIME Content-Type: text/plain; charset=3DTeletex 1557 =0C 1558 draft X.400/MIME body mapping Feb 96 1560 Conversion Type: Text conversion 1561 From X.400 to RFC-822, the conversion shall take the bytes 1562 of all the pages in the "data" part of the 1563 TeletexBodyPart, add a FF character (0x0C, control-L) to 1564 each part that does not already end in one, and 1565 concatenate them together to form the body of the 1566 Text/Plain. 1568 The character set shall be "Teletex", which is especially 1569 registered for this purpose. Its definition is shown in an 1570 appendix. 1572 The parameters are discarded. 1574 From RFC-822 to X.400, the conversion shall split the 1575 content at each occurrence of the FF character (0x0C), 1576 delete the character and construct the Teletex body part 1577 as a SEQUENCE OF TeletexString, as described in X.420(88), 1578 section 7.3.5 1580 The TeletexParameters may, but need not, contain the 1581 number-of-pages component. 1583 NOTE: It is recommended, but not mandated, that the data 1584 be converted into a more widespread character set like 1585 ISO-8859-1 or ISO-2022-JP (if applicable) if possible. 1586 This will result in the reverse translation giving a 1587 GeneralText body part, which will have to be dealt with 1588 appropriately at the X.400/88 to X.400/84 downgrading 1589 boundary, if possible, but will give a much greater chance 1590 that the MIME recipient can actually read the message. 1592 DISCUSSION: 1594 The Teletex body part is frequently used in X.400(84) to 1595 send around text with slightly extended character sets 1596 beyond ASCII. 1598 Its body consists of a series of "pages", separated by 1599 ASN.1 representation. It is important to many people to 1600 have this mapped into something that is readable to most 1601 end-users; therefore, it is recommended to map this onto 1602 Text/Plain; however, since this is not plain text, the 1603 conversion must be specified. 1605 =0C 1606 draft X.400/MIME body mapping Feb 96 1608 7. Body parts where encapsulation is recommended 1610 Some body parts are MIME constructs, and their 1611 functionality will be severely damaged if they are coerced 1612 into an X.400 framework. 1614 Special care needs to be taken with these; they are 1615 described below. 1617 7.1. message/external-body 1619 The gateway MUST support the encapsulation of this body 1620 part using the HARPOON encapsulation (IA5). 1622 It MAY support some kind of retrieval of the referred 1623 object. 1625 DISCUSSION: 1627 The message/external-body part points to an object that 1628 can be retrieved using Internet protocols. 1630 There are three cases to consider for the recipient's 1631 capabilities: 1633 (1) The user has no Internet access. In this case, the 1634 user might be grateful if the gateway fetches the 1635 body part and inserts it into the message. If the 1636 body part is large or dynamic, it might not be 1637 appropriate. 1639 (2) The user has Internet access, but no UA support for 1640 fetching external-body objects. 1642 (3) The user has Internet access and UA support for 1643 fetching external-body objects, based on an 1644 understanding of this document. 1646 Some access-types, like anonymous FTP, are easy to 1647 resolve. Others, like the Mailserver access-type, are 1648 almost impossible to resolve at a gateway. 1650 =0C 1651 draft X.400/MIME body mapping Feb 96 1653 To support the second case above, the tunneling method 1654 chosen is the HARPOON encapsulation described in section 1655 3.1.3, using an IA5 body part, inserting the string "MIME- 1656 Version: 1.0 (generated by gateway)" at the beginning of 1657 the body part. (The part in parentheses can be changed at 1658 will). 1660 This will: 1662 (1) Maximize the chance that the user will see the 1663 message 1665 (2) Give the user hints that will enable him to fetch 1666 the message using other Internet tools 1668 (3) Identify the message as a MIME object in a reliable 1669 fashion, allowing UAs to support the fetching of 1670 the object if the UA implementor desires. 1672 7.2. message/partial 1674 This represents part of a larger message, where it is only 1675 possible to parse the complete message after getting all 1676 the pieces. 1678 The gateway MUST support the encapsulation of this body 1679 part. 1681 It MAY implement transparent reassembly of the message, 1682 but in this case, it MUST support a configurable timeout 1683 for the reassembly, defaulting back to encapsulation. 1685 DISCUSSION: 1687 The gateway's choices are: 1689 (1) Wait until all the pieces arrive at the gateway, 1690 reassemble the message, and use normal processing 1692 (2) Encapsulate the message, using any encapsulation 1693 method 1695 =0C 1696 draft X.400/MIME body mapping Feb 96 1698 In some cases, not all pieces will arrive at the gateway; 1699 some may have been transferred through other gateways due 1700 to route changes or machine outages; some may have been 1701 lost in transit. 1703 7.3. multipart/signed 1705 A gateway MUST implement encapsulation of multipart/signed 1706 using HARPOON. 1708 The gateway MAY be configured to do other processing, as 1709 outlined in the discussion below. This is outside the 1710 scope of the standard. 1712 DISCUSSION: 1714 Gatewaying security is a problem. The gateway can 1715 basically take three approaches: 1717 - Strip the multipart/signed, leaving the bare body 1718 part unsecured, possibly with a comment that the 1719 signature was stripped 1721 - Attempt to check the signature and re-signing the 1722 message using X.400 security functions, then 1723 stripping as above 1725 - Encapsulate the message. This is the only approach 1726 that allows end to end security, but requires MIME 1727 functionality at the recipient. 1729 - Replace the message content with multiple body parts, 1730 containing first an unsecured body part and then the 1731 encapsulated multipart/signed. 1733 All these are valid options for a MIXER gateway. 1735 Note that the encapsulation must use HARPOON, as the 1736 signature is computed on the ENCODED body part, not on the 1737 canonical representation, and HARPOON is the only 1738 encapsulation that preserves the content transfer encoding 1739 of the message. 1741 =0C 1742 draft X.400/MIME body mapping Feb 96 1744 Note also that all methods except for encapsulation break 1745 end-to-end security; the recipient can place no more trust 1746 in the integrity of the message than he can place in the 1747 security of the gateway. 1749 7.4. multipart/encrypted 1751 A gateway MUST implement encapsulation of 1752 multipart/encrypted using HARPOON. 1754 If the implementor chooses to allow other processing at 1755 the gateway, as outlined below, he/she is advised that 1756 there are grave security concerns with such a solution, 1757 since it violates the general rule of keeping decryption 1758 keys as close to the user as possible. 1760 DISCUSSION: 1762 There are two basic cases for a gateway: 1764 - The gateway is trusted with the user's keys. In this 1765 case, the gateway can decrypt the message, possibly 1766 add a note that it has done so, and gateway the 1767 unencrypted form, possibly applying X.400 security 1768 functions, and possibly attaching a copy of the 1769 original, encrypted material for reference. 1770 This does nothing to protect the transfer from 1771 gateway to recipient, unless suitable X.400-native 1772 security is applied. It also means that the gateway 1773 must be part of the user's trusted environment. 1775 - The gateway is not trusted with the recipient's keys. 1776 In this case, encapsulation is the only approach that 1777 preserves any information at all. 1779 The valid options for a MIXER gateway are therefore: 1781 - Decrypt the body part 1783 - Encapsulate the body part 1785 =0C 1786 draft X.400/MIME body mapping Feb 96 1788 - Drop the body part 1790 The MIXER WG has shown strong preference for the 1791 encapsulation alternative, and urges anyone who thinks of 1792 buying or implementing gateway decryption to carefully 1793 evaluate this choice in light of the company's general 1794 security policy. 1796 8. Conformance requirements 1798 In order to be called MIXER conformant, a gateway must 1799 implement: 1801 - Encapsulation of MIME content in the FTBP body part 1803 - Encapsulation of X.400 body parts in the x400-bp body 1804 part 1806 - Encapsulation of FTBP body parts in the 1807 application/x-oid.n.n.n body part 1809 - Encapsulation of security multiparts using HARPOON 1811 - Text/plain <-> IA5Text 1813 - Text/plain; charset=3Diso-8859-* <-> GeneralText 1815 - Multipart/* <-> ForwardedIPMessage 1817 - message/RFC822 <-> ForwardedIPMessage 1819 - application/octet-stream <-> FTBP unknown 1821 - application/octet-stream <-> BilaterallyDefined 1823 - A configuration choice of which application/octet- 1824 stream translation to use 1826 All other parts of this specification MAY be implemented 1827 by the gateway. If they are implemented at all, they MUST 1829 =0C 1830 draft X.400/MIME body mapping Feb 96 1832 be implemented conformant to this specification. 1834 In this context, a feature is "implemented" in a product 1835 if it is possible to configure the product in such a way 1836 that this feature is used. This specification does not 1837 restrict the product to only be configured in such a 1838 fashion. 1840 References 1842 [RFC-822] 1843 D.H. Crocker, Standard for the Format of ARPA 1844 Internet Text Messages. Request for Comments 822, 1845 (August, 1982). 1847 [MIME] 1848 N. Borenstein, N. Freed, MIME: Mechanisms for 1849 Specifying and Describing the Format of Internet 1850 Message Bodies. Request for Comments 1341, (June, 1851 1992). 1853 [MIXER] 1854 S.E. Kille, Mapping between X.400(1988) / ISO 10021 1855 and RFC-822. (in preparation) 1857 [T.4] 1858 CCITT Recommendation T.4, Standardization of Group 3 1859 Facsimile Apparatus for Document Transmission (1988) 1861 [T.30] 1862 CCITT Recommendation T.30, Procedures For Document 1863 Facsimile Transmission in the General Switched 1864 Telephone Network (1988) 1866 [T.411] 1867 CCITT Recommendation T.411 (1988), Open Document 1868 Architecture (ODA) and Interchange Format, 1869 Introduction and General Principles 1871 [MOTIS] 1872 ISO/IEC International Standard 10021, Information 1873 technology - Text Communication - Message-Oriented 1874 Text Interchange Systems (MOTIS) (Parts 1 to 8) 1876 =0C 1877 draft X.400/MIME body mapping Feb 96 1879 [X.400] 1880 CCITT, Data Communication Networks - Message Handling 1881 Systems - Recommendations X.400 - X.420 (1988 1882 version) 1884 [X.420] 1885 CCITT Recommendation X.420 (1988), Interpersonal 1886 Messaging System 1888 [RFC-X400USE] 1889 Harald Tveit Alvestrand, X.400 use of extended 1890 Character Sets, Internet Draft, June 1992 1892 [MAWG] 1893 Electronic Messaging Association Message Attachment 1894 Working Group (MAWG): File Transfer Body Part 1895 Feasibility Project Guide - version 1.5 - September 1896 1995 1898 [CDISP] 1899 Dorner & Troost, The Content-Disposition header - RFC 1900 1806 1902 [POSTSCRIPT] 1903 Harald Tveit Alvestrand, Carrying PostScript in X.400 1904 and MIME, Work In Progress (draft-ietf-mixer- 1905 postscript-00.txt) 1907 [IMAGES] 1908 Harald Tveit Alvestrand, X.400 image body parts, Work 1909 In Progress (draft-ietf-mixer-images-00.txt) 1911 [ODA] 1912 Harald Tveit Alvestrand, A MIME body part for ODA, 1913 Work in Progress (draft-ietf-mixer-oda-00.txt) 1915 =0C 1916 draft X.400/MIME body mapping Feb 96 1918 9. Authors' address 1920 Harald Tveit Alvestrand 1921 UNINETT 1922 P.O.box 6883 Elgeseter 1923 N-7002 Trondheim 1924 NORWAY 1926 Harald.T.Alvestrand@uninett.no 1928 APPENDIXES 1930 Appendix A: Escape code normalization 1932 The algorithm given here in pseudocode will reduce a 1933 GeneralString ISO-2022 unlimited use of shifts sequence to 1934 a pure 8-bit sequence that does not use shift sequences, 1935 if possible. 1937 Some error conditions, like EOF, are not tested for. It 1938 crashes if asked to do something it cannot. Control 1939 character set switching is missing. 1941 A similar routine, albeit more complex, can be written for 1942 normalizing to the ISO-2022-JP character set. 1944 BEGIN: (from X.209) 1945 g0 =3D 6 (should be 2, but ignore the difference) 1946 g1 =3D NULL 1947 g2 =3D NULL 1948 g3 =3D NULL 1949 c0 =3D 1 (ASCII control) 1950 c1 =3D NULL 1951 leftset =3D &g0 (current input set, low) 1952 rightset =3D &g1 (current input set, high) 1953 lowset =3D 6 (output set, low) 1954 highset =3D NULL (output set, high) 1955 charset =3D US-ASCII 1957 (Init for the set tables) 1958 chartoid[{2D,2E,2F}, 41] =3D 100 1960 =0C 1961 draft X.400/MIME body mapping Feb 96 1963 ..... 1964 idtoname[100] =3D "ISO-8859-1" 1965 ..... 1967 WHILE (more data) 1968 CASE head of input 1969 {These are the locking shift sequences} 1970 INCASE "00/14": (LS0, SO) 1971 leftset =3D &g0; 1972 INCASE "00/15": (LS1, SI) 1973 leftset =3D &g 1974 INCASE "ESC 07/14": (LS1R) 1975 rightset =3D &g1; 1976 INCASE "ESC 07/13": (LS2R) 1977 rightset =3D &g2; 1978 INCASE "ESC 07/12": (LS3R) 1979 rightset =3D &g3; 1980 {There is missing code for handling the single shift function} 1981 {These are the changes of graphic character sets} 1982 {Note that G0 can contain only 94-character charsets} 1983 INCASE "ESC 28" 1984 g0 =3D chartoid[lastchar, next character] 1985 sethiset(g0) 1986 INCASE "ESC 2D", "ESC 29" 1987 g1 =3D chartoid[lastchar, next character] 1988 sethiset(g1) 1989 INCASE "ESC 2E", "ESC 2A" 1990 g2 =3D chartoid[lastchar, next character] 1991 sethiset(g2) 1992 INCASE "ESC 2F", "ESC 2B" 1993 g3 =3D chartoid[lastchar, next character] 1994 sethiset(g3) 1995 {control characters. There is missing code for changing these} 1996 INCASE 00/00-01/15 {normal control} 1997 write(char) 1998 INCASE 08/00-09/15 {upper control} 1999 write(char) 2000 {Normal characters} 2001 INCASE 02/00-07/15 (Left) 2002 IF (*leftset =3D=3D lowset) 2003 write(char) 2004 ELSIF (*leftset =3D=3D highset) 2005 write(char+80) 2006 ELSE 2007 ERROR "Shift error" 2009 =0C 2010 draft X.400/MIME body mapping Feb 96 2012 ENDIF 2013 INCASE 10/00-15/15 2014 IF (*rightset =3D=3D highset) 2015 write(char) 2016 ELSIF (*rightset =3D=3D lowset) 2017 write(char-80) 2018 ELSE 2019 ERROR "Shift error" 2020 ENDIF 2021 ENDCASE 2022 ENDWHILE 2024 SUBROUTINE sethighset(g1) 2026 IF (highset =3D=3D NULL) 2027 charset =3D idtoname[g1] 2028 highset =3D g1 2029 ELSIF (highset =3D=3D g1) 2030 (it's OK) 2031 ELSE 2032 ERROR "Too many charsets encountered" 2033 ENDIF 2035 ENDROUTINE 2037 Appendix B: OID Assignments 2038 MIXER-MAPPINGS DEFINITIONS ::=3D BEGIN 2039 EXPORTS -- everything --; 2041 IMPORTS 2042 experimental 2043 FROM RFC1155-SMI; 2044 mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) } 2045 FROM MIXER --Companion RFC--; 2047 mixer-bp-data OBJECT IDENTIFIER ::=3D 2048 { mixer 1 }; 2050 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 2051 { mixer 2 }; 2053 -- mixer-core is defined as { mixer core(3) } in [MIXER] 2054 mixer-bp-heading OBJECT IDENTIFIER ::=3D 2056 =0C 2057 draft X.400/MIME body mapping Feb 96 2059 { mixer 4 } 2061 id-mime-bp-data OBJECT IDENTIFIER ::=3D 2062 { mixer-bp-data 1}; 2064 id-mime-bp-parameters OBJECT IDENTIFIER ::=3D 2065 { mixer-bp-parameter 1}; 2067 -- the following assignments were done in RFC 1494, using 2068 -- slightly different names, but the same numbers. 2069 -- their defining text is now is now in other documents 2070 id-mime-postscript-body OBJECT IDENTIFIER ::=3D 2071 { mixer-bp-data 2} 2073 id-mime-jpeg-body OBJECT IDENTIFIER ::=3D 2074 { mixer-bp-data 3} 2076 id-mime-gif-body OBJECT IDENTIFIER ::=3D 2077 { mixer-bp-data 4}; 2079 -- This is a new definition, and defines an FTAM application referenc= 2080 e, 2081 -- not a BP15 data OID. 2082 id-mime-ftbp-data OBJECT IDENTIFIER ::=3D 2083 { mixer-bp-data 5 } 2085 =0C 2086 draft X.400/MIME body mapping Feb 96 2088 Appendix C: Registration information for the Teletex 2089 character set 2091 The Teletex character set is a character set in which the 2092 ISO 2022 character set switching mechanism may be used to 2093 switch between the following registered ISO character 2094 sets: 2096 ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set 2097 ISO-IR-102 - a fairly standard US-ASCII variant 2098 ISO-IR-103 - Latin characters using non-spacing accents 2099 ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more= 2100 =2E 2101 ISO-IR-107 - Control characters for C1 use 2103 Its intended use of this character set is to represent 2104 data that comes from ISO protocols that use the ASN.1 2105 construct "TeletexString" or "T61string" without 2106 conversion. 2108 The set of allowed character sets can be found in CCITT 2109 recommendation X.208(1988), chapter 31.2 and Table 2110 6/X.208. 2112 The rules for encoding the data type can be found in CCITT 2113 recommendation X.209(1988), chapter 23. It states that at 2114 the beginning of the string, G0 is always ISO-IR-102, C0 2115 is ISO-IR-106, and C1 is ISO-IR-107. 2117 The specification seems somehow to have missed the 2118 implicit assumption that ISO-IR-103 is designated and 2119 invoked as G1 and shifted into the upper half of the 2120 character set which seems to be assumed at least by the 2121 X.400 and X.500 software that uses TeletexStrings; 2122 implementors should act as if the sequence ESC 2/9 7/6 2123 LS1R is always present at the beginning of the data. 2125 The rules for interpreting T.61 data are found (I believe) 2126 in CCITT recommendations T.51, T.52 and T.53 (data from 2127 the ITU WWW server): 2129 T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93] 2130 Latin based coded character sets for telematic services 2131 T.52 (1993) [New] [88 pp.] [Publ.: Apr.94] 2132 Non-Latin coded character sets for telematic services 2133 T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95] 2135 =0C 2136 draft X.400/MIME body mapping Feb 96 2138 Character coded control functions for telematic services 2140 (The author has not yet obtained a copy of these, even 2141 though they only cost SFR 70 from the ITU...) 2143 The Teletex character set is closely related to (but not 2144 identical with) that specified in ISO 6937. 2146 No further restrictions are imposed by this registration; 2147 in particular, character set switching can occur anywhere, 2148 and there is no guarantee that the character sets will be 2149 switched "back" at the end. 2151 =0C 2152 draft X.400/MIME body mapping Feb 96 2154 Appendix D: IANA Registration form for new mappings 2156 To: IANA@isi.edu 2157 Subject: Registration of new X.400/MIME content type mapping 2159 MIME type name: 2161 (this must have been registered previously with IANA) 2163 X.400 body part: 2165 X.400 Object Identifier for Data: 2167 (If left empty, an OID will be assigned by IANA under 2168 mixer-bp-data) 2170 X.400 Object Identifier for Parameters: 2172 (If left empty, an OID will be assigned by IANA under 2173 mixer-bp-parameter. If it is not used, fill in the 2174 words NOT USED.) 2176 X.400 ASN.1 Syntax: 2178 (must be an EXTENDED-BODY-PART-TYPE macro, or refer=AD 2179 ence to a Basic body part type) 2181 Conversion algorithm: 2183 (must be defined completely enough for independent im=AD 2184 plementation. It may be defined by reference to RFCs). 2186 Person & email address to contact for further informa=AD 2187 tion: 2189 INFORMATION TO THE SUBMITTER: 2191 The accepted registrations will be listed in the "As=AD 2192 signed Numbers" series of RFCs. The information in 2193 the registration form is freely distributable. 2195 =0C 2196 draft X.400/MIME body mapping Feb 96 2198 Table of Contents 2200 Status of this Memo ................................ 1 2201 1 Introduction ...................................... 2 2202 1.1 Glossary ........................................ 2 2203 2 Basic rules for body part conversion .............. 3 2204 2.1 Generating the IPM Body from MIME ............... 5 2205 2.2 Generating the MIME Body from the IPMS.Body ..... 5 2206 2.3 Mapping the EMA FTBP parameters ................. 7 2207 2.3.1 Mapping GraphicStrings ........................ 7 2208 2.3.2 Mapping specific parameters ................... 8 2209 2.3.3 Summary of FTBP elements generated ............ 11 2210 2.4 Information that is lost when mapping ........... 12 2211 3 Encapsulation of body parts ....................... 12 2212 3.1 Encapsulation of MIME in X.400 .................. 13 2213 3.1.1 BP15 encapsulating body part .................. 13 2214 3.1.2 FTBP encapsulating body part .................. 15 2215 3.1.3 Encapsulation using IA5 (HARPOON) ............. 16 2216 3.1.4 Content passing using BP14 .................... 16 2217 3.2 Encapsulating X.400 Body Parts in MIME .......... 17 2218 3.3 Encapsulating FTBP body parts in MIME ........... 18 2219 4 User control over the gateway choice .............. 19 2220 4.1 Conversion from MIME to X.400 ................... 19 2221 4.2 Conversion from X.400 to MIME ................... 21 2222 5 The equivalence registry .......................... 22 2223 5.1 What information one must give about a mapping 2224 ................................................ 22 2225 5.2 Equivalence summary for known X.400 and MIME 2226 Types .......................................... 24 2227 5.3 MIME to X.400 Table ............................. 24 2228 5.4 X.400 to MIME Table ............................. 25 2229 5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 26 2230 6 Defined Equivalences .............................. 28 2231 6.1 IA5Text - text/plain ............................ 28 2232 6.2 GeneralText - text/plain (ISO-8859) ............. 29 2233 6.3 BilaterallyDefined - application/octet-stream 2234 ................................................ 31 2235 6.4 FTBP EMA Unknown Attachment - applica=AD 2236 tion/octet-stream .............................. 32 2237 6.5 MessageBodyPart - message/RFC822 ................ 32 2238 6.6 MessageBodyPart - multipart/* ................... 33 2239 6.7 Teletex - Text/Plain (Teletex) .................. 34 2240 7 Body parts where encapsulation is recommended ..... 36 2241 7.1 message/external-body ........................... 36 2243 =0C 2244 draft X.400/MIME body mapping Feb 96 2246 7.2 message/partial ................................. 37 2247 7.3 multipart/signed ................................ 38 2248 7.4 multipart/encrypted ............................. 39 2249 8 Conformance requirements .......................... 40 2250 References ......................................... 41 2251 9 Authors' address .................................. 43 2252 APPENDIXES ......................................... 43 2253 Appendix A: Escape code normalization .............. 43 2254 Appendix B: OID Assignments ........................ 45 2255 Appendix C: Registration information for the 2256 Teletex character set .......................... 47 2257 Appendix D: IANA Registration form for new map=AD 2258 pings .......................................... 49 2259 Table of Contents .................................. 50 2261 =0C