idnits 2.17.1 draft-ietf-mixer-bodymap-06.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-06.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mixer-bodymap-06.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mixer-bodymap-06.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-06.txt.', but the file name used is 'draft-ietf-mixer-bodymap-06' ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security considerations' ) ** 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 21 instances of too long lines in the document, the longest one being 5 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 182: '..., but a conformant MIXER gateway MUST...' RFC 2119 keyword, line 377: '...rity precautions MUST be taken in usin...' RFC 2119 keyword, line 422: '... with "content-" SHOULD be put into th...' RFC 2119 keyword, line 485: '... A gateway MAY choose to support th...' RFC 2119 keyword, line 486: '... available, but MUST support this lim...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 178 has weird spacing: '... Where no m...' == Line 179 has weird spacing: '...he body part,...' == Line 180 has weird spacing: '...ge, or encap...' == Line 181 has weird spacing: '...ice may be c...' == Line 346 has weird spacing: '...s; the handl...' == (9 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) -- Looks like a reference, but probably isn't: '0' on line 1229 -- Looks like a reference, but probably isn't: '1' on line 1230 -- Looks like a reference, but probably isn't: '2' on line 1231 == Missing Reference: 'UNIVERSAL 8' is mentioned on line 1224, but not defined == Missing Reference: 'UNIVERSAL 7' is mentioned on line 1233, but not defined -- Looks like a reference, but probably isn't: '100' on line 2029 == Missing Reference: 'New' is mentioned on line 2196, but not defined == Unused Reference: 'RFC-822' is defined on line 1923, but no explicit reference was found in the text == Unused Reference: 'RFC-X400USE' is defined on line 1968, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (ref. 'MIME') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- 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 (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft X.400/MIME body mapping May 96 3 Mapping between X.400 and RFC-822/MIME Message Bodies 5 Thu Aug 15 14:51:04 MET DST 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-06.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 draft X.400/MIME body mapping May 96 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 A table of contents that should be quite useful for 53 locating specific sections is given in the back of the 54 document. 56 1.1. Glossary 58 The following terms are defined in this document: 60 Body part 61 Part of a message that has a unique type. This term 62 comes from X.400; the corresponding term in MIME (RFC 63 1521) is limited to use in parts of a multipart 64 message; the term "body" may correspond better. 66 Content-type 67 Type information indicating what the content of a 68 body part actually is. This term comes from MIME; the 69 corresponding X.400 term is "body part type". 71 Mapping 72 (noun): A description of how to transform an X.400 73 body part into a MIME body part, or how to transform 74 a MIME body part into an X.400 body part. 76 Equivalence 77 A set of two mappings that taken together provide a 78 lossless conversion between an X.400 body part and a 79 MIME body part 81 Encapsulation 82 The process of wrapping something from one of the 83 mail systems in such a way that it can be carried 84 inside the other mail system. When encapsulating, it 85 is not expected that the other mail system can make 87 draft X.400/MIME body mapping May 96 89 reasonable sense of the body part, but a gateway back 90 into the first system will always be able to convert 91 the body part without loss back to its original 92 format. 94 HARPOON encapsulation 95 The encapsulating of a MIME body part by putting it 96 inside an IA5 body with all headers and encoding 97 intact. First described in RFC 1496 (HARPOON). 99 Tunneling 100 What happens when one gateway encapsulates a message 101 and sends it to another gateway that decapsulates it. 102 The hope is that this will cause minimal damage to 103 the message in transit. 105 DISCUSSION 106 At many points in this document, the author has found 107 it useful to include material that explains part of 108 the reasoning behind the specification. These 109 sections all start with DISCUSSION: and continue to 110 the next numbered section heading; they do not 111 dictate any additional requirements on a gateway. 113 2. Basic rules for body part conversion 115 The basic approach for translating body parts is described 116 in section 2.1 and 2.2. 118 Chapter 3 gives details on "encapsulation", which allows 119 you to be certain that no information is lost even when 120 unknown types are encountered. 122 Chapter 6 gives the core mappings for various body parts. 124 The conformance requirements in chapter 8 describe what 125 the minimum conformance for a MIXER gateway is with 126 respect to body part conversion. 128 DISCUSSION: 130 At the moment (Sept 1995) both the MIME and the X.400 131 worlds are in a state of flux with regards to carrying 132 around stuff that is not text. 134 draft X.400/MIME body mapping May 96 136 In such a situation, there is little chance of defining a 137 mapping between them that is the best for all people, all 138 of the time. 139 For this reason, this specification allows a gateway 140 considerable latitude in deciding exactly what conversion 141 to apply. 143 The decision taken by the gateway may be based on various 144 information sources: 146 (1) If the gateway knows what body parts or content 147 types the recipient is able to handle, or has 148 registered a particular set of preferences for a 149 user, and knows how to convert the message 150 reasonably to those body parts, the gateway may 151 choose to convert body parts in the message to 152 those types only. 154 (2) If the gateway gets indications (via special 155 headers or heading-extensions defined for the 156 purpose) that the sender wanted a particular 157 representation on the "other side", and the gateway 158 is able to satisfy the request, it may do so. Such 159 a mechanism is defined in chapter 4 of this 160 document. 162 (3) If the gateway gets a message that might be 163 appropriate to send as one out of several types, 164 but where the typing information does not tell you 165 which one to use (like an X.400 BP14, FTAM "just a 166 file", or MIME application/octet-stream), it may 167 apply heuristics like looking at content or looking 168 at filenames to figure out how to deal with the 169 message. 171 (4) If the gateway knows that the next hop for the 172 message has limited capabilities (like X.400/84), 173 it may choose to perform conversions appropriate 174 for that medium. 176 draft X.400/MIME body mapping May 96 178 (5) Where no mapping is known by the gateway, it 179 may choose to drop the body part, reject the 180 message, or encapsulate the body part as de� 181 scribed in chapter 3. The choice may be con� 182 figurable, but a conformant MIXER gateway MUST 183 be able to be configured for encapsulation. 185 In many cases, a message that goes SMTP->X.400->SMTP will 186 arrive without loss of information. 188 In some cases, the reverse translation may not be 189 possible, or two gateways may choose to apply different 190 translations, based on the criteria above, leading to an 191 apparently inconsistent service. 193 In addition, service will vary because some gateways will 194 have implemented conversions not implemented by other 195 gateways. 197 This is believed to be unavoidable. 199 2.1. Generating the IPM Body from MIME 201 When converting the body of a message from MIME to X.400, 202 the following steps are taken: 204 If the header does not contain a 822.MIME-Version field, 205 then generate an IPMS.Body with a single IPMS.BodyPart of 206 type IPMS.IA5TextBodyPart containing the body of the RFC 207 822 message with 208 IPMS.IA5TextBodyPart.parameters.repertoire set to the 209 default (IA5). 211 If 822.MIME-Version is present, the body is analyzed as a 212 MIME message and the body is converted according to the 213 mappings configured and implemented in the gateway. 215 2.2. Generating the MIME Body from the IPMS.Body 217 When converting the body of a message from X.400 to MIME, 218 the following steps are taken: 220 draft X.400/MIME body mapping May 96 222 If there is more than one body part, and the first body 223 part is IA5 and starts with the string "RFC-822-Headers:" 224 as the first line, then the remainder of this body part 225 shall be appended to the RFC 822 header. This relies upon 226 the theory that this body part has been generated 227 according to Appendix B of MIXER. A gateway shall check 228 the consistency and syntax of this body part, to ensure 229 that the resulting message is conformant with RFC 822. 231 If the remaining IPMS.Body consists of a single 232 IPMS.Bodypart, there are three possibilities. 234 (1) If it is of type IPMS.IA5Text, and the first line 235 is "MIME-Version: 1.0", it is assumed to be a 236 HARPOON-encapsulated body part. The complete body 237 content is then appended to the headers; the 238 separating blank line is inside the message. If an 239 RFC 822 syntax error is discovered inside the 240 message, it may be mapped directly as described 241 below instead. 243 (2) If it is of type IPMS.IA5Text, then this is mapped 244 directly and no MIME encoding is used. 246 (3) All other types are mapped according to the 247 mappings configured and implemented in the gateway. 249 If the IPMS.Body contains multiple IPMS.Bodypart fields, 250 then a MIME message of content type multipart is 251 generated. If all of the body parts are messages, then 252 this is multipart/digest. Otherwise it is 253 multipart/mixed. The components of the multipart are 254 generated in the same order as in the IPMS.Body. 256 Each component is mapped according to the mappings 257 configured and implemented in the gateway; any IA5 body 258 parts are checked to see if they are HARPOON mappings. 260 draft X.400/MIME body mapping May 96 262 2.3. Mapping the EMA FTBP parameters 264 DISCUSSION: 266 EMA has defined a profile for use of the File Transfer 267 Body Part (FTBP). [MAWG] 269 New mappings are expected to use this as the mechanism for 270 carrying body parts, and since it is important to have a 271 consistent mapping for the special FTBP parameters, these 272 are defined here. 274 The mapping of the body will depend on the content-type in 275 MIME and on the application-reference in FTBP, and is not 276 specified here. 278 However, in many cases, we expect that the translation 279 will involve simply copying the octets from one format to 280 the other; that is, "no conversion". 282 2.3.1. Mapping GraphicStrings 284 Some parameters of the EMA Profile are encoded as ASN.1 285 GraphicStrings, which are troublesome because they can 286 contain any ISO registered graphic character set. 287 To map these to ASCII for use in mail headers, the gateway 288 may either: 290 (1) Use the RFC 1522 encoding mechanism to create 291 appropriate encoded-words for the headers involved. 292 Note that in some cases, such as within Content- 293 Disposition filenames, the encoded-words must be in 294 quotes, which is not the normal usage of encoded- 295 words. 297 (2) Apply the normalization procedure given in Appendix 298 A to identify the ASCII characters of the string, 299 and replace all non-ASCII characters with the 300 question mark (?). 302 draft X.400/MIME body mapping May 96 304 Both procedures are valid for MIXER gateways; the 305 simplified procedure of ignoring escape sequences and bit- 306 stripping the result is NOT valid. 308 2.3.2. Mapping specific parameters 310 The following parameters are mapped in both directions: 312 Content-ID 314 The mapping of this element is complex. 316 The Content-ID is encoded as an IPM.MessageIdentifier 317 and entered into the 318 FTBP.FileTransferParameters.related-stored-file. 319 file-identifier.cross-reference.message-reference. 321 FTBP.FileTransferParameters.related-stored-file. 322 relationship.descriptive-relationship is set to the 323 string "Internet MIME Body Part". 325 FTBP.FileTransferParameters.related-stored-file. 326 file-identifier.cross-reference.application- 327 crossreference is set to a null OCTET STRING. 329 The reverse mapping is only performed if the 330 FTBP.FileTransferParameters.related-stored-file. 331 relationship.descriptive-relationship has the string 332 value "Internet MIME Body Part". 334 Content-Description 336 The value of this field is mapped to and from the 337 first string in 338 FTBP.FileTransferParameters.environment.user-visible- 339 string. 341 draft X.400/MIME body mapping May 96 343 Content-Disposition 345 This field is defined in [CDISP]. It has multiple 346 components; the handling of each component is 347 given below. 349 The "disposition" component is ignored on MIME -> 350 X.400 mapping, and is always "attachment" on X.400 -> 351 MIME mapping. 353 NOTE: RFC 1806 gives only the "filename" component. 354 The other components are expected to be added to the 355 next version of RFC 1806. 357 C-D: filename 359 The filename component of the C-D header is mapped to 360 and from FileTransferParameters.file- 361 attributes.pathname. 363 The EBNF.disposition-type is ignored when creating 364 the FTBP pathname, and always set to "attachment" 365 when creating the Content-Disposition header. For 366 example: 368 Content-Disposition: attachment; filename=dodo.doc 370 or 372 Content-Disposition: attachment; filename=/etc/passwd 374 The filename will be carried as a single incomplete- 375 pathname string. No special significance is assumed 376 for the characters "/" and "\". Note that normal 377 security precautions MUST be taken in using a 378 filename on a local file system; this should be 379 obvious from the second example. 381 This is done to be conformant with the EMA Profile. 383 draft X.400/MIME body mapping May 96 385 C-D: Creation-date 387 Mapped to and from FileTransferParameters.file- 388 attributes.date-and-time-of-creation 390 For this and all other date fields, the RFC-822 date 391 format is used (822.date-time). Note that the 392 parameter syntax of RFC 1806 requires that all dates 393 be quoted! 395 C-D: Modification-date 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 extension in 414 FTBP.FileTransferParameters.extensions using the 415 rfc-822-field HEADING-EXTENSION from [MIXER]. 417 NOTE: 418 The set of headers that are mapped will depend on the 419 placement of the body part (single body part or 420 multipart). 421 When it is the only body of a message, headers 422 starting with "content-" SHOULD be put into the FTAM 423 extension, and all other headers should be put into 425 draft X.400/MIME body mapping May 96 427 the IPMS extension for the message. 428 When it is a single bodypart of a multipart, ALL 429 headers on the body part are included, since there is 430 nowhere else to put them. Note that only headers that 431 start with "content-" have defined semantics in this 432 case. 434 EMA NOTE 436 The EMA profile, version 1.5, specifies that handling 437 of extensions is Optional for reception. This means 438 that some non-MIXER gateways may not implement 439 handling of this field, and some UAs may not have the 440 possibility of showing the content of this field to 441 the user. 443 An alternative approach using 444 FTBP.FileTransferParameters.environment.user-visible- 445 string was suggested to EMA, and the EMA MAWG 446 recommended in its April 1996 conference that the 447 IETF MIXER group should rather choose this approach. 449 2.3.3. Summary of FTBP elements generated 451 This is a summary of the preceding section, and does not 452 add new information. 454 The following elements of the FTBP parameters are mapped 455 or used (the rightmost column gives their status in the 456 EMA profile; M=Mandatory, O=Optional, R=Recommended for 457 Origination/Receipt): 459 FileTransferParameters M/M 460 Related-Stored-File O/O 461 file-identifier 462 cross-reference 463 application-crossreference NULL 464 message-reference Content-ID 465 descriptive-relationship Used as marker 466 contents-type Must be unstructured-binary M/M 467 environment M/M 468 application-reference Selects mapping M/M 469 user-visible-string Content-description R/M 471 draft X.400/MIME body mapping May 96 473 file-attributes 474 pathname C-D: Filename R/M 475 date-and-time-of-creation C-D: Creation-Date O/O 476 date-and-time-of-last-modification C-D: Modification-Date R/M 477 date-and-time-of-last-read-access C-D: Read-Date O/O 478 object-size C-D: Size R/M 479 extensions Other headers O/O 481 All other elements of the FTBP parameters are discarded. 483 NOTE: There is ongoing work on defining a more complete 484 mapping between FTBP headers and a set of RFC-822 headers. 485 A gateway MAY choose to support the larger set once it is 486 available, but MUST support this limited set. 488 2.4. Information that is lost when mapping 490 MIME defines fields which add information to MIME 491 contents. Two of these are "Content-ID", and "Content- 492 Description", which have special rules here, but MIME 493 allows new fields to be defined at any time. 495 The possibilities are limited about what one can do with 496 this information: 498 (1) When using encapsulation, the information can be 499 preserved 501 (2) When using mapping to FTBP, the information can be 502 preserved in the FileTransferParameters.extensions 503 defined for that purpose. 505 (3) When mapping to a single-body message, the 506 information can be preserved as P22 header 507 extensions 509 (4) When mapping to other body part types, the 510 information must be discarded. 512 draft X.400/MIME body mapping May 96 514 3. Encapsulation of body parts 516 Where no mapping is possible, the gateway may choose any 517 of the following alternatives: 519 - Discard the body part, leaving a "marker" saying what 520 happened 522 - Reject the message 524 - "Encapsulate" the body part, by wrapping it in a body 525 part defined for that purpose in the other mail 526 system 528 The choice to be made should be configurable in the 529 gateway, and may depend on both policy and knowledge of 530 the recipient's capabilities. 532 3.1. Encapsulation of MIME in X.400 534 Four body parts are defined here to encapsulate MIME body 535 parts in X.400. 537 The BP15 body part is backwards compatible with RFC 1494. 538 The FTBP body part is compatible with the EMA MAWG 539 document [MAWG], version 1.5, but has some extensions, in 540 particular the one for extra headers. 542 The imagined scenarios for each body part are: 544 FTBP For use when sending to recipients that can handle 545 generic FTBP, and for tunnelling MIME to a MIME UA 547 BP15 For use when tunnelling MIME to a MIME UA through an 548 X.400(88) network, or to UAs that have been written 549 to RFC 1494 551 IA5 For use when tunneling MIME to a MIME UA through an 552 X.400 network, where some of the links may involve 553 X.400(84). 555 BP14 For use when the recipient may be an X.400(84) UA 556 with BP14 handling capability, and the loss of 557 information in headers is not regarded as important. 559 draft X.400/MIME body mapping May 96 561 but the gateway is free to use any method it finds 562 appropriate in any situation. 564 FTBP is expected to be the most useful body part in 565 sending to X.400(92) systems, while the BP14 content 566 passing is primarily useful for sending to X.400(84) 567 systems. 569 3.1.1. FTBP encapsulating body part 571 This body part utilizes the fundamental assumption in MIME 572 that all message content can be legally and completely 573 represented by a single octet stream, the "canonical 574 format". 576 The FTBP encapsulating body part is defined by the 577 application-reference id-mime-ftbp-data; all headers are 578 mapped to the FTBP headers, including putting the 579 "Content-type:" header inside the FTBP ExtensionsField. 581 Translation from the MIME body part is done by: 583 - Undoing the content-transfer-encoding 585 - Setting the "FileTransferData.FTdata.value.octet- 586 aligned" to the resulting string of octets 588 - Putting the appropriate parameters into the headers. 590 Reversing the translation is done by: 592 - Extracting the headers 594 - Applying an appropriate content-transfer-encoding to 595 the body. If this is for some reason different from 596 the content-transfer-encoding: header retrieved from 597 the headers, the old one must be deleted. 599 This mapping is lossless, and therefore counts as "no 600 conversion". 602 draft X.400/MIME body mapping May 96 604 3.1.2. BP15 encapsulating body part 606 This section defines an extended body part, based on body 607 part 15, which may be used to hold any MIME content. 609 mime-body-part EXTENDED-BODY-PART-TYPE 610 PARAMETERS MimeParameters 611 IDENTIFIED BY id-mime-bp-parameters 612 DATA OCTET STRING 613 ::= id-mime-bp-data 615 MimeParameters ::= 616 SEQUENCE { 617 content-type IA5String, 618 content-parameters SEQUENCE OF 619 SEQUENCE { 620 parameter IA5String, 621 parameter-value IA5String 622 } 623 other-header-fields RFC822FieldList 624 } 626 The OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime- 627 bp-data are defined in Appendix B. A MIME content is 628 mapped onto this body part. The MIME headers of the body 629 part are mapped as follows: 631 RFC822FieldList is defined in Appendix L of [MIXER]. 633 Content-Type: 634 The "type/subtype" string is mapped to 635 MimeParameters.content-type. 637 For each "parameter=value" string create a 638 MimeParameters.content-parameters element. The 639 MimeParameters.content-Parameters.parameter field is 640 set to the parameter and the MimeParameters.content- 641 parameters.parameter-value field is set to the value. 643 Quoting is preserved in the parameter-value. 645 draft X.400/MIME body mapping May 96 647 Other 648 Take all other headers and create 649 MimeParameters.other-header-fields. 651 The MIME-version, content-type and content-transfer- 652 encoding fields are NOT copied. 654 NOTE: 655 The set of headers that are mapped will depend on the 656 placement of the body part (single body part or 657 multipart). 658 When it is the only body of a message, headers 659 starting with "content-" SHOULD be put into the 660 other-header-fields, and all other headers should be 661 put into the IPMS extension for the message. 662 When it is a single bodypart of a multipart, ALL 663 headers on the body part are included, since there is 664 nowhere else to put them. Note that only headers that 665 start with "content-" have defined semantics in this 666 case. 668 The body is mapped as follows: 670 Convert the MIME body part into its canonical form, as 671 specified in Appendix H of MIME [MIME]. This canonical 672 form is used to generate the mime-body-part.data octet 673 string. 675 The Parameter mapping may be used independently of the 676 body part mapping (e.g., in order to use a different 677 encoding for a mapped MIME body part). 679 This body part contains all of the MIME information, and 680 so can be mapped back to MIME without loss of information. 682 The OID id-mime-bp-data is added to the Encoded 683 Information Types of the envelope. 685 This body part is completely compatible with RFC 1494. 687 When converting back to a MIME body part, the gateway is 688 responsible for: 690 draft X.400/MIME body mapping May 96 692 (1) Selecting an appropriate content-transfer-encoding, 693 and deleting any content-transfer-encoding header 694 from the other-header-fields 696 (2) Adding quotes to any parameters that need them (but 697 not adding quotes to parameters that are already 698 quoted) 700 (3) Removing any content-type field that is left in the 701 RFC822FieldList of the message that is redundant or 702 conflicting with the one from the mime-body-part 704 (4) Make sure that on multipart messages, the boundary 705 string actually used is reflected in the boundary= 706 parameter of the content-type header, and does not 707 occur within the body of the message. 709 3.1.3. Encapsulation using IA5 (HARPOON) 711 This approach is the one taken in RFC 1496 - HARPOON - for 712 tunneling any MIME body part through X.400/84 networks. It 713 has proven rather unhelpful for bringing information to 714 X.400 users, but preserves all the information of a MIME 715 body part. 717 The following IA5Text body part is made: 719 - Content = IA5String 721 - First bytes of content: (the description is in US 722 ASCII, with C escape sequences used to represent 723 control characters): 725 MIME-version: \r\n 726 Content-type: \r\n 727 Content-transfer-encoding: <7bit, quoted-printable or base64>\r\n 728 729 \r\n 730 733 draft X.400/MIME body mapping May 96 735 All implementations MUST place the MIME-version: header 736 first in the body part. Headers that are placed by [MIXER] 737 into other parts of the message MUST NOT be placed in the 738 MIME body part. 740 3.1.4. Content passing using BP14 742 This is described in this section because it is at the 743 same conceptual level as encapsulation. It is a lossy 744 transformation; it is impossible to reconstruct the MIME 745 type information from it. 747 Nevertheless, there is a demand for such functionality. 749 This "encapsulation" simply strips off all headers, undoes 750 the content-transfer-encoding, and creates a 751 BilaterallyDefined body part (BP14) from the resulting 752 octet stream. 754 No reverse translation is defined; when a BP14 arrives at 755 a MIXER gateway, it will be turned into an 756 application/octet-stream according to chap. 6.3 758 3.2. Encapsulating X.400 Body Parts in MIME 760 This section specifies a generic mechanism to map X.400 761 body parts to a MIME content. This allows for the body 762 part to be tunneled through MIME. It may also be used 763 directly by an appropriately configured MIME UA. 765 This content-type is defined to carry any X.400 extended 766 body part. The mapping of all standard X.400 body parts 767 is defined in RFC1494bis. The content-type field is 768 "application/x400-bp". The parameter is defined by the 769 EBNF: 771 mime-parameter = "bp-type=" object-identifier 773 The EBNF.object-identifier is set to the OBJECT IDENTIFIER 774 from IPMS.body.externally-defined.data.direct-reference. 776 For example, a Videotex body part will have 778 draft X.400/MIME body mapping May 96 780 Content-type=application/x400-bp; bp-type=2.6.1.4.5 782 The body contains the raw ASN.1 IPM body octet stream, 783 that is, the BER encoding of the IPM.Body.BodyPart, 784 including the initial tag octet. The content may use a 785 content-transfer-encoding of either base64 or quoted- 786 printable when carried in 7-bit MIME. It is recommended 787 to use the one which gives the more compact encoding of 788 the data. If this cannot be determined, Base64 is 789 recommended. No attempt is made to turn the parameters of 790 Extended Body Parts into MIME parameters, as this cannot 791 be done in a general manner. 793 Standard X.400 body parts may not be encoded directly by 794 this mechanism, but may be encoded indirectly by first 795 translating to the extended representation. 797 NOTE: RFC 1494 defined a bp-type= for encoding 798 standard X.400 body parts. If such body parts are 799 encountered, RFC 1494 section 6.1 should be consulted. 801 3.3. Encapsulating FTBP body parts in MIME 803 The File Transfer Body Part is believed to be important in 804 the future as "the" means of carrying well-identified data 805 in X.400 networks. 807 They also share the property (at lest when limited to the 808 EMA MAWG functional profile) of having a well-defined data 809 part that is always representable as a sequence of bytes. 811 This conversion will have to fail, and the x400-bp 812 encapsulation used instead, if: 814 - FileTransferData has more than one element 816 - Contents-type is not unstructured-binary 818 - Parameters that are not mappable, but important, are 819 present (like Compression, which EMA doesn't 820 recommend). 822 Otherwise, it can be encapsulated in MIME by: 824 draft X.400/MIME body mapping May 96 826 - Creating the "content-type" value by forming the 827 string "application/x-ftbp." and appending the 828 numbers of the OID 830 - Mapping all other parameters according to the 831 standard FTBP parameter mapping 833 - Applying an appropriate content-transfer-encoding 835 DISCUSSION: 837 The choice of the somewhat strange, and by necessity 838 unregistered, MIME type "application/x-ftbp.n.n.n.n" is 839 because for any concrete example of this usage, it will be 840 easy to configure any MIME reader to take advantage of the 841 identification. If the MIME type registration rules are 842 ever changed to allow the registration of a namespace, 843 rather than just of names, the "x-" can be deleted, and 844 the types can be "application/ftbp.n.n.n.n". 846 4. User control over the gateway choice 848 In some cases, the gateway may make an inappropriate 849 choice when deciding what to do about a particular body 850 part. 852 To allow an escape clause, this chapter defines a way in 853 which the user can signal the gateway what action it finds 854 most appropriate. 856 The headers given here override any "conversion 857 prohibited" and "conversion with loss prohibited" on the 858 message. 860 It is still the gateway's responsibility that the 861 generated messages conform to the destination domain's 862 syntax rules. 864 DISCUSSION: 866 The intent of this mechanism is to allow the sender to 867 efficiently get a message through to a single recipient 869 draft X.400/MIME body mapping May 96 871 when the sender has information about the recipient that 872 the gateway does not have. 874 It is not a part of the minimum functionality listed in 875 chapter 8; a gateway does not have to implement this spec 876 to be MIXER conformant, but if implemented, it should be 877 done like this. 879 The additional complexity, both in user interface and in 880 protocol, of making this field selectable per recipient 881 was not thought worthwhile; 883 4.1. Conversion from MIME to X.400 885 The header field described below specifies explicit MIXER 886 conversion. Comments are allowed within the field 887 according to the usual RFC 822 convention. 889 If "x400-object-id" is omitted, "tunnel" is assumed. 891 mime-to-x400 = "Wanted-X400-Conversion" ":" 892 [ mime-from ] [ x400-object-id ] 893 "in" x400-encoding 895 x400-object-id = "to" ( object-identifier-2 / "tunnel" ) 896 x400-encoding = "bp14" / "bp15" / "ftbp" / "ia5" 897 mime-from = "from" mime-type 898 mime-type = word 900 There is no way to ask for a different conversion based on 901 MIME parameters or bodypart content. 903 Examples: 905 Wanted-X400-Conversion: from application/msword 906 to 1.2.840.113556.4.2 (Microsoft defined ms-word) 907 in ftbp 909 This uses the MAWG definitions, and leads to an FTBP encoding. 911 Wanted-X400-Conversion: from application/msword 912 to tunnel in bp14 914 draft X.400/MIME body mapping May 96 916 This leads to a Body Part 14 encoding for all body parts of type 917 application/msword. 919 Wanted-X400-Conversion: in bp14 921 This requests that this specific body part be encoded in Body Part 14. 923 This field may be used in two places: 925 (1) In the heading of an unstructured MIME body part. 926 In this case the EBNF.mime-from is omitted, and the 927 requested conversion applies to the body part. 929 (2) In a multipart. In this case, the body part type to 930 which the conversion applies is defined by 931 EBNF.mime-from, and the conversion applies to all 932 body parts of this MIME type contained in the 933 multipart, including those contained in nested 934 messages and multiparts. If a contained body part 935 has its own heading, this takes precedence. Note 936 that the "from" parameter is mandatory when used in 937 a multipart. 939 The EBNF.x400-object-id shall be present when "bp15" or 940 "ftbp" encoding is selected. 942 The value "tunnel" implies encapsulation as defined in 943 Chapter 3. 945 The "object identifier" used below is: 947 - For BP 15, it is the value of the EXTENDED-BODY-PART- 948 TYPE macro that defines the body part, which is found 949 in ExternallyDefinedBodyPart.data.direct-reference. 951 - For FTBP, it is the value of the 952 Environment.application-reference. 954 draft X.400/MIME body mapping May 96 956 4.2. Conversion from X.400 to MIME 958 The IPM heading defined here shall be present in the 959 heading of a message. It defines the mapping for all body 960 parts of the specified types, including those in nested 961 messages. 963 wanted-MIME-conversion HEADING-EXTENSION 964 VALUE WantedMIMEConversions 965 ::= id-wanted-MIME-conversions 967 WantedMIMEConversions ::= SEQUENCE OF X400toMIMEConversion 969 X400toMIMEConversion ::= SEQUENCE { 970 x400-type X400Type, 971 mime-type MIMEType } 973 X400Type ::= CHOICE { 974 standard [0] INTEGER, -- standard body part 975 extended [1] OBJECT IDENTIFIER, -- BP 15 976 ftbp [2] OBJECT IDENTIFIER} -- FTBP application-reference 978 MIMEType ::= SEQUENCE { 979 type IA5String, -- type (e.g., application/ms-word) 980 encoding [1] IA5String OPTIONAl -- e.g. quoted-printable 981 parameters [2] IA5String OPTIONAL } -- MIME Parameters 983 The heading extension includes all requested conversions, 984 with explicit information as to how each body part type is 985 encoded in MIME. 987 FTBP is identified as a separate body part type, as there 988 will be a need for different encodings, dependent on what 989 is being carried. 991 Encapsulation is requested by asking for 992 "application/x400-bp" or "application/ftbp" as the 993 destination type. 995 For FTAM body parts, the parameters will survive the 996 gatewaying process. For other body parts, there are three 997 alternatives: 999 draft X.400/MIME body mapping May 96 1001 (1) The gateway knows a defined mapping for this 1002 particular body part and destination type. It will 1003 be used, and parameters mapped accordingly. 1005 (2) The gateway knows how to extract an OCTET STRING 1006 from the body part, and the destination is a simple 1007 MIME body part. All information outside the OCTET 1008 STRING is lost. (This may be the case for a BP14 1009 that should end up in an application/xyzzy, for 1010 instance). 1012 (3) The gateway knows of no relevant mapping, and does 1013 not know how to simplify the X.400 body part. The 1014 gateway will then proceed as if the mapping control 1015 field had not been present. 1017 5. The equivalence registry 1019 5.1. What information one must give about a mapping 1021 The following information MUST be supplied when describing 1022 an equivalence or a mapping: 1024 MIME type name (which must be preregistered) 1026 X.400 body part (often BP15 or FTAM Body Part) 1028 If BP15 is used, the following information must be given: 1030 (1) Object Identifier for X.400 BP15 Data 1032 (2) Object Identifier for X.400 BP15 Parameters 1034 (3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART- 1035 TYPE macro) 1037 If FTBP is used, the following information must be given: 1039 (1) Object Identifier for the FTAM 1040 Environment.application-reference 1042 draft X.400/MIME body mapping May 96 1044 (2) Object Identifier for the FTAM Contents-type, if 1045 unstructured-binary is not used 1047 (3) Any other special considerations 1049 In all cases, the following must be given: 1051 Conversion algorithms. The expected effect of "Conversion 1052 prohibited" and "Conversion with loss prohibited" should 1053 be noted. 1055 The conversion must be specified with enough detail to 1056 permit independent implementation; literature references 1057 are acceptable. 1059 An equivalence can be registered with IANA using the form 1060 at the end of this document. The purpose of the 1061 registration is to achieve a greater uniformity among 1062 gateways implementing the same translation; there is no 1063 requirement that a gateway must support all of the 1064 translations that are registered with IANA. Specific 1065 conformance requirements for MIXER are given at the end of 1066 this document. 1068 5.2. Equivalence summary for known X.400 and MIME Types 1070 This section itemizes the equivalences for all currently 1071 known MIME content-types and X.400 body parts. 1073 For each MIME content-type/X.400 body part pair, the 1074 equivalence table contains an entry with the following 1075 sections: 1077 X.400 Body Part 1078 This section identifies the X.400 Body Part governed 1079 by this Table entry. It includes any OBJECT 1080 IDENTIFIERs or other parameters necessary to uniquely 1081 identify the Body Part. 1083 MIME Content-Type 1084 This section identifies the MIME content-type 1086 draft X.400/MIME body mapping May 96 1088 governed by this Table entry. The MIME content-type 1089 named here must be registered with the IANA. 1091 Section/document reference 1092 Reference to section of this document, or to the 1093 other document that describes this mapping. 1095 The initial Equivalence Table entries in this document are 1096 described using this convention. 1098 Further registrations of equivalences should be submitted 1099 to the IANA after a public review, using the example form 1100 given at the end of this document. 1102 5.3. MIME to X.400 Table 1104 MIME content-type X.400 Body Part Section 1105 ----------------- ------------------ ------- 1106 text/plain 1107 charset=us-ascii ia5-text 6.1 1108 charset=ISO-8859-x EBP - GeneralText 6.2 1109 text/richtext no mapping defined Encap 1110 application/oda EBP - ODA [ODA] 1111 application/octet-stream bilaterally-defined or 6.3 1112 FTBP unknown attachment 6.4 1113 application/postscript EBP - mime-postscript-body [POSTSCRIPT] 1114 image/g3fax g3-facsimile [IMAGES] 1115 image/jpeg EBP - mime-jpeg-body [IMAGES] 1116 image/gif EBP - mime-gif-body [IMAGES] 1117 audio/basic no mapping defined Encap 1118 video/mpeg no mapping defined Encap 1119 message/RFC822 ForwardedIPMessage 6.5 1120 multipart/* ForwardedIPMessage 6.6 1121 multipart/signed HARPOON encap 7.3 1122 multipart/encrypted HARPOON encap 7.4 1124 Abbreviation: EBP - Extended Body Part 1126 draft X.400/MIME body mapping May 96 1128 5.4. X.400 to MIME Table 1129 Basic Body Parts 1131 X.400 Basic Body Part MIME content-type Section 1132 --------------------- -------------------- ------- 1133 ia5-text text/plain;charset=us-ascii 6.1 1134 voice No Mapping Defined Encap 1135 g3-facsimile image/g3fax [IMAGES] 1136 g4-class1 no mapping defined Encap 1137 teletex text/plain;charset=teletex 6.7 1138 videotex no mapping defined Encap 1139 encrypted no mapping defined Encap 1140 bilaterally-defined application/octet-stream 6.3 1141 nationally-defined no mapping defined Encap 1142 externally-defined See Extended Body Parts below 1143 ForwardedIPMessage message/RFC822 or multipart 6.5,6.6 1145 X.400 Extended Body Part MIME content-type Section 1146 ------------------------- -------------------- ------- 1147 GeneralText text/plain;charset=ISO-8859-x 6.2 1148 ODA application/oda [ODA] 1149 mime-postscript-body application/postscript [POSTSCRIPT] 1150 mime-jpeg-body image/jpeg [IMAGES] 1151 mime-gif-body image/gif [IMAGES] 1152 FTAM various 2.3,6.4 1154 FTAM application ID MIME content type Section 1155 ------------------- ----------------- ------- 1156 ema-unknown-attachment application/octet-stream 6.4 1158 draft X.400/MIME body mapping May 96 1160 5.5. Use of OBJECT IDENTIFIERs and ASN.1 MACROS 1162 When one wants to define new BP15 body parts for use with 1163 equivalences, it is important to know that X.420 dictates 1164 that Extended Body Parts shall: 1166 (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify 1167 the contents, and 1169 (2) be defined by using the ASN.1 Macro: 1171 EXTENDED-BODY-PART-TYPE MACRO::= 1172 BEGIN 1173 TYPE NOTATION ::= Parameters Data 1174 VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1176 Parameters ::= "PARAMETERS" type "IDENTIFIED" 1177 "BY" value(OBJECT IDENTIFIER) 1178 | empty; 1179 Data ::= "DATA" type 1180 END 1182 To meet these requirements, this document uses the OID 1184 mixer 1186 defined in [MIXER], as the root OID for X.400 Extended 1187 Body Parts defined for MIME interworking. 1189 Each Extended Body Part contains Data and optional 1190 Parameters, each being named by an OID. To this end, two 1191 OID subtrees are defined under mixer-bodies, one for Data, 1192 and the other for Parameters: 1194 mixer-bp-data OBJECT IDENTIFIER ::= 1195 { mixer 1 } 1197 mixer-bp-parameter OBJECT IDENTIFIER ::= 1198 { mixer 2 } 1200 All definitions of extended X.400 body parts submitted to 1201 the IANA for registration with a mapping must use the 1202 Extended Body Part Type macro for the definition. See 1203 [IMAGES] for an example. 1205 draft X.400/MIME body mapping May 96 1207 Lastly, the IANA will use the mixer-bp-data and mixer-bp- 1208 parameter OIDs as root OIDs for any new MIME content- 1209 type/subtypes that aren't otherwise registered in the 1210 Equivalence Table. 1212 NOTE: The ASN.1 for an ExternallyDefinedBodyPart is 1214 ExternallyDefinedBodyPart ::= SEQUENCE { 1215 parameters [0] ExternallyDefinedParameters OPTIONAL, 1216 data ExternallyDefinedData } 1218 ExternallyDefinedParameters ::= EXTERNAL 1220 ExternallyDefinedData ::= EXTERNAL 1222 The ASN.1 for EXTERNAL is (from X.208): 1224 EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE 1225 {direct-reference OBJECT IDENTIFIER OPTIONAL, 1226 indirect-reference INTEGER OPTIONAL, 1227 data-value-descriptor ObjectDescriptor OPTIONAL, 1228 encoding CHOICE 1229 {single-ASN1-type [0] ANY, 1230 octet-aligned [1] IMPLICIT OCTET STRING, 1231 arbitrary [2] IMPLICIT BIT STRING}} 1233 ObjectDescriptor ::= [UNIVERSAL 7] IMPLICIT GraphicString 1235 There are a bit too many choices here; the common X.400 1236 usage for BP15 encoding is to: 1238 (1) Always use direct-reference 1240 (2) Omit indirect-reference and data-value-descriptor 1242 (3) Use the single-ASN1-type encoding only 1244 Unfortunately, some implementations have chosen to use the 1245 octet-aligned choice when constructing values where the 1246 ASN.1 type is OCTET STRING, which of course caused 1247 interoperability problems. 1249 An attempt to specify that X.420 only allowed the single- 1250 ASN1-type choice in the 1996 versions is still (Sept 1995) 1251 being debated in ISO; the end result seems to be that all 1253 draft X.400/MIME body mapping May 96 1255 agree in principle that single-ASN1-type should be used, 1256 but that one has to allow the generation of the octet- 1257 aligned choice as being conformant. 1259 6. Defined Equivalences 1261 6.1. IA5Text - text/plain 1263 X.400 Body Part: IA5Text 1264 MIME Content-type: text/plain; charset=US-ASCII 1265 Conversion Type: No conversion 1266 Comments: 1268 When mapping from X.400 to MIME, the "repertoire" 1269 parameter is ignored. 1271 When mapping from MIME to X.400, the "repertoire" 1272 parameter is set to IA5 (5). 1274 NOTE: The MIME Content-type headers are omitted, when 1275 mapping from X.400 to MIME, if and only if the IA5Text 1276 body part is the only body part in the IPMS.Body sequence. 1278 NOTE: IA5Text specifies the "currency" symbol in position 1279 2/4. This is converted without comment to the "dollar" 1280 symbol, since the author of this document has seen many 1281 documents in which the position was intended to indicate 1282 "dollar" while he has not yet seen one in which the 1283 "currency" symbol is intended. 1285 (For reference: The T.50 (1988) recommendation, which 1286 defines IA5, talks about ISO registered set number 2, 1287 while ASCII, using the "dollar" symbol, is ISO registered 1288 set number 6. There are no other differences.) 1290 NOTE: It is not uncommon, though it is a violation of the 1291 standard, to use 8-bit character sets inside an IA5 body 1292 part. Gateways that can expect to encounter this situation 1293 should consider implementing something like the guidance 1294 given in RFC 1428, "Transition of Internet Mail from just- 1295 send-8 to 8-bit SMTP/MIME", and generate appropriate 1296 charset parameters for the MIME messages they generate. 1298 draft X.400/MIME body mapping May 96 1300 This behavior is not required for MIXER conformance, since 1301 it is only needed when the base standards are violated. 1303 6.2. GeneralText - text/plain (ISO-8859) 1305 X.400 Body Part: GeneralText; CharacterSets in 1306 6, 14, 42, 87, 100,101,109,110,126,127,138,144,148 1307 MIME Content-Type: text/plain; charset=ISO-8859-(1-9) 1308 or iso-2022-jp 1309 Conversion Type: Text conversion without character change 1310 When mapping from X.400 to MIME, the character-set is 1311 chosen from the table below according to the value of 1312 Parameters.CharacterSets. If no match is found, and the 1313 gateway does not support a conversion, the character set 1314 shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the 1315 numbers of the Parameters.CharacterSets, sorted in numeric 1316 order. 1318 When mapping from MIME to X.400, GeneralText is an 1319 Extended Body Part, hence it requires an OID. The OID for 1320 the GeneralText body is defined in [MOTIS], part 8, annex 1321 D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1 1322 11 11}. 1324 The Parameters.CharacterSets is set from table below 1325 according to the value of "charset" 1327 The following table lists the MIME character sets and the 1328 corresponding ISO registry numbers. If no correspondence 1329 is found, this conversion fails, and the generic body part 1330 approach is used. 1332 MIME charset ISO IR numbers Comment 1333 ----------------------------------------------- 1334 ISO-8859-1 6, 100 West European "8-bit ASCII" 1335 ISO-8859-2 6, 101 East European 1336 ISO-8859-3 6, 109 1337 ISO-8859-4 6, 110 1338 ISO-8859-5 6, 144 Cyrillic 1339 ISO-8859-6 6, 127 Arabic 1340 ISO-8859-7 6, 126 Greek 1341 ISO-8859-8 6, 138 Hebrew 1342 ISO-8859-9 6, 148 Other Latin-using languages 1344 draft X.400/MIME body mapping May 96 1346 ISO-2022-JP 6, 14, 42, 87 Japanese 1348 When converting from MIME to X.400, generate the correct 1349 OIDs for use in the message envelope's Encoded Information 1350 Types by looking up the ISO IR number in the above table, 1351 and then appending it to the id-cs-eit-authority {1 0 1352 10021 7 1 0} OID. 1354 The escape sequences to designate and invoke the relevant 1355 character sets in their proper positions must be added to 1356 the front of the GeneralText character string. 1358 For ISO 8859-1, the relevant escape sequence will be: 1360 ESC 28 42 1361 ASCII in G0 1363 ESC 2D 41 1364 ISO-IR-100 in G1 1366 ESC 21 41 1367 High control character set in C1 1369 ESC 7E 1370 Locking shift 1 Right 1372 These escape sequences are removed when converting from 1373 GeneralText to text/plain. 1375 Note that new character sets may be defined on both the 1376 Internet side and the X.400 side; a gateway MAY choose to 1377 implement more conversions in the same fashion. 1379 DISCUSSION: 1381 The conversion of text is a problematic one, and one in 1382 which it is likely that gateways should be given wide 1383 latitude to make decisions based upon their knowledge of 1384 the user's preferences. The text given below is thought to 1385 give the best approximation to a gateway conforming to 1386 current and anticipated usage in the MIME and X.400 1387 worlds, and is the way recommended when no knowledge of 1388 the recipient's capabilities exists. 1390 The changes, such as normalizing escape sequences, should 1392 draft X.400/MIME body mapping May 96 1394 not be done when "conversion-prohibited" is set. If 1395 "conversion-with-loss-prohibited" is set, translation to a 1396 character set that is not able to encode all characters 1397 cannot be done, and the message should be non-delivered 1398 with an appropriate non-delivery reason. 1400 The common use of character sets in MIME is somewhat 1401 different from the rules given by X.400; in particular, it 1402 is common in MIME to assume that the character sets follow 1403 strict rules. For the ISO-8859-x character sets, it is 1404 assumed that they are designated and invoked at the 1405 beginning of the text, and that no designation or 1406 invocation sequences occur within the body of the text. 1407 The rules for ISO-2022-JP are given in RFC 1468, and are 1408 even more particular, using a pure 7-bit encoding in which 1409 each line of text starts in ASCII. 1411 Therefore, the text must be "normalized" by going through 1412 the whole message, using a state machine or similar device 1413 to remove all escape and shift sequences. 1415 Appendix A gives pseudocode for such a conversion. 1417 NOTE: In 1988, the GeneralText body part was defined in 1418 ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT 1419 recommendation; this was added later. Also, the 1420 parameters have been heavily modified; they should be a 1421 SET OF INTEGER in the currently valid text. Use the 1422 latest version of the standard that you can get hold of. 1424 6.3. BilaterallyDefined - application/octet-stream 1426 X.400 Body Part: BilaterallyDefined 1427 MIME Content-Type: Application/Octet-Stream (no parameters) 1428 Conversion Type: No conversion 1430 When mapping from MIME to X.400, if there are parameters 1431 present in the Content-Type: header field, they are 1432 removed. 1434 DISCUSSION: 1436 The parameters "name" "type" and "conversions" are 1438 draft X.400/MIME body mapping May 96 1440 advisory; name and conversions are depreciated in RFC 1441 1521. 1443 The parameter "padding" changes the interpretation of the 1444 last byte of the data, but it is deemed better by the WG 1445 to delete this information than to non-deliver the body 1446 part. The "padding" parameter is rarely used with MIME. 1448 Use of BilaterallyDefined Body Parts is specifically 1449 deprecated in both 1988 and 1992 X.400. It is retained 1450 solely for backward compatibility with 1984 systems, and 1451 because it is in common use. 1453 6.4. FTBP EMA Unknown Attachment - 1454 application/octet-stream 1456 X.400 Body Part: FTBP EMA Unknown Attachment 1457 MIME Content-Type: Application/Octet-Stream 1458 Conversion Type: No conversion 1460 The OID for the Unknown Attachment is { joint-iso-ccitt(2) 1461 country(16) us(840) organization(1) ema(113694) objects(2) 1462 messaging(2) attachments(1) unknown(1) }, or 1463 2.16.840.1.113694.2.2.1.1 for short. 1465 NOTE: Previous EMA drafts gave it as { iso(1) countries(2) 1466 usa(840) organization (1) ema (113694) objects(2) 1467 messaging(2) attachments(1) unknown (1)}, or 1468 1.2.840.1.113694.2.2.1.1 for short. 1470 The parameters for this type must be mapped according to 1471 chapter 2.3, with the following extensions for the 1472 parameters of the application/octet-stream: 1474 If there is no Content-Disposition parameter with a 1475 filename, and there is a name parameter, the 1476 FTBP.FileTransferParameters.File-attributes.pathname 1477 is generated from this parameter. Note that RFC 1521 1478 recommends not using the "name" parameter. 1480 The "type", "conversions" and "padding" attributes are 1481 ignored; "type" is for human consumption; "conversions" 1483 draft X.400/MIME body mapping May 96 1485 are discouraged in RFC 1521. 1487 The body mapping is just copying the bytes in both 1488 directions. 1490 6.5. MessageBodyPart - message/RFC822 1492 X.400 body part: MessageBodyPart 1493 MIME Content-Type: message/RFC822 1494 Conversion Type: Special 1496 NOTE: If the headers of the X.400 MessageBodyPart contains the 1497 "multipart-message" heading extension with the isAMessage bit set 1498 (either explicitly or implicitly), the mapping should be to 1499 multipart/* according to section 6.6, below. 1501 To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 1502 mapping is recursively applied, to generate an RFC 822 Message. 1503 If present, the IPMS.MessageBodyPart.parameters.delivery-envelope 1504 is used for the MTS Abstract Service Mappings. If present, the 1505 IPMS.MessageBodyPart.parameters.delivery-time is mapped to the 1506 extended RFC 822 field "Delivery-Date:". 1508 When a message/RFC822 is contained within a MIME message, it is 1509 mapped to an IPMS.MessageBodyPart according to MIXER. 1510 specification. Any mappings that would have been made to the MTS 1511 Abstract Service are placed in 1512 IPMS.MessageBodyPart.parameters.delivery-envelope. 1514 6.6. MessageBodyPart - multipart/* 1516 X.400 body part: MessageBodyPart 1517 MIME Content-Type: multipart/* 1518 Conversion Type: Special 1520 NOTE: If the headers of the X.400 MessageBodyPart do not contain the 1521 "multipart-message" heading extension with the "isAMessage" flag FALSE, 1522 the mapping should be to message/RFC822. 1524 A MIME multipart is a set of content-types and not a message with 1525 a set of content types. When the multipart is at the outermost 1526 MIME header, elements of the multipart are mapped directly onto 1527 IPMS.Bodypart. 1529 draft X.400/MIME body mapping May 96 1531 When the MIME multipart is not at the outermost level, it is mapped to 1532 an IPMS.MessageBodyPart containing an IPMS.Bodypart for each element 1533 of the multipart. 1535 When a nested IPMS.Message is generated from a multipart, an 1536 IPMS.heading shall always be generated. The only mandatory field 1537 is the IPMS.Heading.this-IPM message id, which shall be generated 1538 by the gateway. An IPMS.Heading.subject field shall also be 1539 generated, in order to provide useful information to non-MIME 1540 capable X.400(88) UAs and to all X.400(84) UAs. The subject 1541 field is set as follows according to the multipart subtype: 1543 mixed: 1544 "Multipart Message" 1546 alternative: 1547 "Alternative Body Parts containing the same 1548 information" 1550 digest: 1551 "Message Digest" 1553 parallel: 1554 "Body Parts interpreted in parallel" 1556 other: 1557 "Multipart Message ()" 1559 For other types of multipart, the multipart subtype shall 1560 be included in the subject line. 1562 For each multipart, the following IPMS.HeadingExtension 1563 shall be generated, with the value set according to the 1564 subtype. 1565 If the multipart is the outermost multipart, and the 1566 subtype is "mixed", it may be omitted. 1568 multipart-message HEADING-EXTENSION 1569 VALUE MultipartType 1570 ::= id-hex-multipart-message 1572 MultipartType ::= SEQUENCE { 1573 subtype IA5String, 1574 isAMessage BOOLEAN DEFAULT TRUE } 1576 draft X.400/MIME body mapping May 96 1578 The MultipartType contains the subtype, for example 1579 "digest". If this heading is present when mapping from 1580 X.400 to MIME, the appropriate multipart may be generated. 1582 The isAMessage flag is needed because of the case where a 1583 message contains a ForwardedIPMessage, which itself was 1584 generated from a MIME message that was a Multipart; it is 1585 set whenever the multipart is the outermost level of 1586 nesting inside a Message/RFC822. 1588 NOTE: 1589 When downgrading to X.400/84, the content-type SHOULD 1590 be regenerated from this heading-extension and put 1591 into the RFC-822-HEADERS extra body part. 1593 6.7. Teletex - Text/Plain (Teletex) 1595 X.400 Body Part: Teletex 1596 MIME Content-Type: text/plain; charset=Teletex 1597 Conversion Type: Text conversion 1599 From X.400 to RFC-822, the conversion shall take the bytes 1600 of all the pages in the "data" part of the 1601 TeletexBodyPart, add a FF character (0x0C, control-L) to 1602 each part that does not already end in one, and 1603 concatenate them together to form the body of the 1604 Text/Plain. 1606 The character set shall be "Teletex", which is especially 1607 registered for this purpose. Its definition is shown in an 1608 appendix. 1610 The parameters are discarded. 1612 From RFC-822 to X.400, the conversion shall split the 1613 content at each occurrence of the FF character (0x0C), 1614 delete the character and construct the Teletex body part 1615 as a SEQUENCE OF TeletexString, as described in X.420(88), 1616 section 7.3.5 1618 The TeletexParameters may, but need not, contain the 1620 draft X.400/MIME body mapping May 96 1622 number-of-pages component. 1624 NOTE: It is recommended, but not mandated, that the data 1625 be converted into a more widespread character set like 1626 ISO-8859-1 or ISO-2022-JP (if applicable) if possible. 1627 This will result in the reverse translation giving a 1628 GeneralText body part, which will have to be dealt with 1629 appropriately at the X.400/88 to X.400/84 downgrading 1630 boundary, if possible, but will give a much greater chance 1631 that the MIME recipient can actually read the message. 1633 DISCUSSION: 1635 The Teletex body part is frequently used in X.400(84) to 1636 send around text with slightly extended character sets 1637 beyond ASCII. 1639 Its body consists of a series of "pages", separated by 1640 ASN.1 representation. It is important to many people to 1641 have this mapped into something that is readable to most 1642 end-users; therefore, it is recommended to map this onto 1643 Text/Plain; however, since this is not plain text, the 1644 conversion must be specified. 1646 draft X.400/MIME body mapping May 96 1648 7. Body parts where encapsulation is recommended 1650 Some body parts are MIME constructs, and their 1651 functionality will be severely damaged if they are coerced 1652 into an X.400 framework. 1654 Special care needs to be taken with these; they are 1655 described below. 1657 7.1. message/external-body 1659 The gateway MUST support the encapsulation of this body 1660 part using the HARPOON encapsulation (IA5). 1662 It MAY support some kind of retrieval of the referred 1663 object. 1665 DISCUSSION: 1667 The message/external-body part points to an object that 1668 can be retrieved using Internet protocols. 1670 There are three cases to consider for the recipient's 1671 capabilities: 1673 (1) The user has no Internet access. In this case, the 1674 user might be grateful if the gateway fetches the 1675 body part and inserts it into the message. If the 1676 body part is large or dynamic, it might not be 1677 appropriate. 1679 (2) The user has Internet access, but no UA support for 1680 fetching external-body objects. 1682 (3) The user has Internet access and UA support for 1683 fetching external-body objects, based on an 1684 understanding of this document. 1686 Some access-types, like anonymous FTP, are easy to 1687 resolve. Others, like the Mailserver access-type, are 1688 almost impossible to resolve at a gateway. 1690 draft X.400/MIME body mapping May 96 1692 To support the second case above, the tunneling method 1693 chosen is the HARPOON encapsulation described in section 1694 3.1.3, using an IA5 body part, inserting the string "MIME- 1695 Version: 1.0 (generated by gateway)" at the beginning of 1696 the body part. (The part in parentheses can be changed at 1697 will). 1699 This will: 1701 (1) Maximize the chance that the user will see the 1702 message 1704 (2) Give the user hints that will enable him to fetch 1705 the message using other Internet tools 1707 (3) Identify the message as a MIME object in a reliable 1708 fashion, allowing UAs to support the fetching of 1709 the object if the UA implementor desires. 1711 7.2. message/partial 1713 This represents part of a larger message, where it is only 1714 possible to parse the complete message after getting all 1715 the pieces. 1717 The gateway MUST support the encapsulation of this body 1718 part. 1720 It MAY implement transparent reassembly of the message, 1721 but in this case, it MUST support a configurable timeout 1722 for the reassembly, defaulting back to encapsulation. 1724 DISCUSSION: 1726 The gateway's choices are: 1728 (1) Wait until all the pieces arrive at the gateway, 1729 reassemble the message, and use normal processing 1731 (2) Encapsulate the message, using any encapsulation 1732 method (BP15, FTAM or HARPOON). 1734 draft X.400/MIME body mapping May 96 1736 In some cases, not all pieces will arrive at the gateway; 1737 some may have been transferred through other gateways due 1738 to route changes or machine outages; some may have been 1739 lost in transit. 1741 7.3. multipart/signed 1743 A gateway MUST implement encapsulation of multipart/signed 1744 using HARPOON. 1746 The gateway MAY be configured to do other processing, as 1747 outlined in the discussion below. This is outside the 1748 scope of the standard. 1750 DISCUSSION: 1752 Gatewaying security is a problem. The gateway can 1753 basically take three approaches: 1755 - Strip the multipart/signed, leaving the bare body 1756 part unsecured, possibly with a comment that the 1757 signature was stripped 1759 - Attempt to check the signature and re-signing the 1760 message using X.400 security functions, then 1761 stripping as above 1763 - Encapsulate the message. This is the only approach 1764 that allows end to end security, but requires MIME 1765 functionality at the recipient. 1767 - Replace the message content with multiple body parts, 1768 containing first an unsecured body part and then the 1769 encapsulated multipart/signed. 1771 All these are valid options for a MIXER gateway. 1773 Note that the encapsulation must use HARPOON, as the 1774 signature is computed on the ENCODED body part, not on the 1775 canonical representation, and HARPOON is the only 1776 encapsulation that preserves the content transfer encoding 1777 of the message. 1779 draft X.400/MIME body mapping May 96 1781 Note also that all methods except for encapsulation break 1782 end-to-end security; the recipient can place no more trust 1783 in the integrity of the message than he can place in the 1784 security of the gateway. 1786 7.4. multipart/encrypted 1788 A gateway MUST implement encapsulation of 1789 multipart/encrypted using HARPOON. 1791 If the implementor chooses to allow other processing at 1792 the gateway, as outlined below, he/she is advised that 1793 there are grave security concerns with such a solution, 1794 since it violates the general rule of keeping decryption 1795 keys as close to the user as possible. 1797 DISCUSSION: 1799 There are two basic cases for a gateway: 1801 - The gateway is trusted with the user's keys. In this 1802 case, the gateway can decrypt the message, possibly 1803 add a note that it has done so, and gateway the 1804 unencrypted form, possibly applying X.400 security 1805 functions, and possibly attaching a copy of the 1806 original, encrypted material for reference. 1807 This does nothing to protect the transfer from 1808 gateway to recipient, unless suitable X.400-native 1809 security is applied. It also means that the gateway 1810 must be part of the user's trusted environment. 1812 - The gateway is not trusted with the recipient's keys. 1813 In this case, encapsulation is the only approach that 1814 preserves any information at all. 1816 The valid options for a MIXER gateway are therefore: 1818 - Decrypt the body part 1820 - Encapsulate the body part 1822 draft X.400/MIME body mapping May 96 1824 - Drop the body part 1826 The MIXER WG has shown strong preference for the 1827 encapsulation alternative, and urges anyone who thinks of 1828 buying or implementing gateway decryption to carefully 1829 evaluate this choice in light of the company's general 1830 security policy. 1832 8. Conformance requirements 1834 In order to be called MIXER conformant, a gateway must 1835 implement: 1837 - Encapsulation of MIME content in the FTBP body part 1839 - Encapsulation of X.400 body parts in the x400-bp body 1840 part 1842 - Encapsulation of FTBP body parts in the 1843 application/x-oid.n.n.n body part 1845 - Encapsulation of security multiparts using HARPOON 1847 - Text/plain <-> IA5Text 1849 - Text/plain; charset=iso-8859-* <-> GeneralText 1851 - Multipart/* <-> ForwardedIPMessage 1853 - message/RFC822 <-> ForwardedIPMessage 1855 - application/octet-stream <-> FTBP unknown 1857 - application/octet-stream <-> BilaterallyDefined 1859 - A configuration choice of which application/octet- 1860 stream translation to use 1862 All other parts of this specification MAY be implemented 1863 by the gateway. If they are implemented at all, they MUST 1865 draft X.400/MIME body mapping May 96 1867 be implemented conformant to this specification. 1869 In this context, a feature is "implemented" in a product 1870 if it is possible to configure the product in such a way 1871 that this feature is used. This specification does not 1872 restrict the product to only be configured in such a 1873 fashion. 1875 9. Security considerations 1877 The security issues identified in this memo are: 1879 (1) Security implications of using filenames that 1880 arrive in body part headers (section 2.3.2) 1882 (2) Security implications of letting a gateway handle 1883 encrypted and/or signed content (section 7.3 and 1884 7.4) 1886 If a gateway fetches message/external-body on behalf of 1887 the recipient, as described in section 7.1, it may be 1888 tricked into performing inappropriate actions by malicious 1889 senders. 1891 In addition, all the normal caveats that apply to sending 1892 data that may contain executable code apply to UAs on both 1893 sides of the gateway. 1895 10. Author's address 1897 Harald Tveit Alvestrand 1898 UNINETT 1899 P.O.box 6883 Elgeseter 1900 N-7002 Trondheim 1901 NORWAY 1903 Harald.T.Alvestrand@uninett.no 1905 draft X.400/MIME body mapping May 96 1907 11. Acknowledgements 1909 The author wishes to thank all the members of the MIXER WG 1910 for their valuable input, and in particular (in no 1911 particular order): 1913 Steve Kille, Peter Sylvester, Ned Freed, Julian Onions, 1914 Ruth Moulton, Keith Moore, Alain Zahm, Urs Eppenberger, 1915 Kevin Jordan, Jeroen Houttuin, Claudio Allocchio, Colin 1916 Robbins, Steven Thomson, Jim Craigie, 1918 and many others who have been active over the long 1919 lifetime of this document. 1921 References 1923 [RFC-822] 1924 D.H. Crocker, Standard for the Format of ARPA 1925 Internet Text Messages. Request for Comments 822, 1926 (August, 1982). 1928 [MIME] 1929 N. Borenstein, N. Freed, MIME: Mechanisms for 1930 Specifying and Describing the Format of Internet 1931 Message Bodies. Request for Comments 1521, (June, 1932 1992). 1934 [MIXER] 1935 S.E. Kille, Mapping between X.400(1988) / ISO 10021 1936 and RFC-822. (in preparation) 1938 [T.4] 1939 CCITT Recommendation T.4, Standardization of Group 3 1940 Facsimile Apparatus for Document Transmission (1988) 1942 [T.30] 1943 CCITT Recommendation T.30, Procedures For Document 1944 Facsimile Transmission in the General Switched 1945 Telephone Network (1988) 1947 [T.411] 1948 CCITT Recommendation T.411 (1988), Open Document 1949 Architecture (ODA) and Interchange Format, 1950 Introduction and General Principles 1952 draft X.400/MIME body mapping May 96 1954 [MOTIS] 1955 ISO/IEC International Standard 10021, Information 1956 technology - Text Communication - Message-Oriented 1957 Text Interchange Systems (MOTIS) (Parts 1 to 8) 1959 [X.400] 1960 CCITT, Data Communication Networks - Message Handling 1961 Systems - Recommendations X.400 - X.420 (1988 1962 version) 1964 [X.420] 1965 CCITT Recommendation X.420 (1988), Interpersonal 1966 Messaging System 1968 [RFC-X400USE] 1969 Harald Tveit Alvestrand, X.400 use of extended 1970 Character Sets, Internet Draft, June 1992 1972 [MAWG] 1973 Electronic Messaging Association Message Attachment 1974 Working Group (MAWG): File Transfer Body Part 1975 Feasibility Project Guide - version 1.5 - September 1976 1995 1978 [CDISP] 1979 Dorner & Troost, The Content-Disposition header - RFC 1980 1806 1982 [POSTSCRIPT] 1983 Harald Tveit Alvestrand, Carrying PostScript in X.400 1984 and MIME, Work In Progress (draft-ietf-mixer- 1985 postscript-00.txt) 1987 [IMAGES] 1988 Harald Tveit Alvestrand, X.400 image body parts, Work 1989 In Progress (draft-ietf-mixer-images-00.txt) 1991 [ODA] 1992 Harald Tveit Alvestrand, A MIME body part for ODA, 1993 Work in Progress (draft-ietf-mixer-oda-00.txt) 1995 draft X.400/MIME body mapping May 96 1997 APPENDIXES 1999 Appendix A: Escape code normalization 2001 The algorithm given here in pseudocode will reduce a 2002 GeneralString ISO-2022 unlimited use of shifts sequence to 2003 a pure 8-bit sequence that does not use shift sequences, 2004 if possible. 2006 Some error conditions, like EOF, are not tested for. It 2007 crashes if asked to do something it cannot. Control 2008 character set switching is missing. 2010 A similar routine, albeit more complex, can be written for 2011 normalizing to the ISO-2022-JP character set. 2013 BEGIN: (from X.209) 2014 g0 = 6 (should be 2, but ignore the difference) 2015 g1 = NULL 2016 g2 = NULL 2017 g3 = NULL 2018 c0 = 1 (ASCII control) 2019 c1 = NULL 2020 leftset = &g0 (current input set, low) 2021 rightset = &g1 (current input set, high) 2022 lowset = 6 (output set, low) 2023 highset = NULL (output set, high) 2024 charset = US-ASCII 2026 (Init for the set tables) 2027 chartoid[{2D,2E,2F}, 41] = 100 2028 ..... 2029 idtoname[100] = "ISO-8859-1" 2030 ..... 2032 WHILE (more data) 2033 CASE head of input 2034 {These are the locking shift sequences} 2035 INCASE "00/14": (LS0, SO) 2036 leftset = &g0; 2037 INCASE "00/15": (LS1, SI) 2038 leftset = &g 2039 INCASE "ESC 07/14": (LS1R) 2040 rightset = &g1; 2042 draft X.400/MIME body mapping May 96 2044 INCASE "ESC 07/13": (LS2R) 2045 rightset = &g2; 2046 INCASE "ESC 07/12": (LS3R) 2047 rightset = &g3; 2048 {There is missing code for handling the single shift function} 2049 {These are the changes of graphic character sets} 2050 {Note that G0 can contain only 94-character charsets} 2051 INCASE "ESC 28" 2052 g0 = chartoid[lastchar, next character] 2053 sethiset(g0) 2054 INCASE "ESC 2D", "ESC 29" 2055 g1 = chartoid[lastchar, next character] 2056 sethiset(g1) 2057 INCASE "ESC 2E", "ESC 2A" 2058 g2 = chartoid[lastchar, next character] 2059 sethiset(g2) 2060 INCASE "ESC 2F", "ESC 2B" 2061 g3 = chartoid[lastchar, next character] 2062 sethiset(g3) 2063 {control characters. There is missing code for changing these} 2064 INCASE 00/00-01/15 {normal control} 2065 write(char) 2066 INCASE 08/00-09/15 {upper control} 2067 write(char) 2068 {Normal characters} 2069 INCASE 02/00-07/15 (Left) 2070 IF (*leftset == lowset) 2071 write(char) 2072 ELSIF (*leftset == highset) 2073 write(char+80) 2074 ELSE 2075 ERROR "Shift error" 2076 ENDIF 2077 INCASE 10/00-15/15 2078 IF (*rightset == highset) 2079 write(char) 2080 ELSIF (*rightset == lowset) 2081 write(char-80) 2082 ELSE 2083 ERROR "Shift error" 2084 ENDIF 2085 ENDCASE 2086 ENDWHILE 2088 SUBROUTINE sethighset(g1) 2090 draft X.400/MIME body mapping May 96 2092 IF (highset == NULL) 2093 charset = idtoname[g1] 2094 highset = g1 2095 ELSIF (highset == g1) 2096 (it's OK) 2097 ELSE 2098 ERROR "Too many charsets encountered" 2099 ENDIF 2101 ENDROUTINE 2103 Appendix B: OID Assignments 2104 MIXER-MAPPINGS DEFINITIONS ::= BEGIN 2105 EXPORTS -- everything --; 2107 IMPORTS 2108 experimental 2109 FROM RFC1155-SMI; 2110 mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) } 2111 FROM MIXER --Companion RFC--; 2113 mixer-bp-data OBJECT IDENTIFIER ::= 2114 { mixer 1 }; 2116 mixer-bp-parameter OBJECT IDENTIFIER ::= 2117 { mixer 2 }; 2119 -- mixer-core is defined as { mixer core(3) } in [MIXER] 2120 mixer-bp-heading OBJECT IDENTIFIER ::= 2121 { mixer 4 } 2123 id-mime-bp-data OBJECT IDENTIFIER ::= 2124 { mixer-bp-data 1}; 2126 id-mime-bp-parameters OBJECT IDENTIFIER ::= 2127 { mixer-bp-parameter 1}; 2129 -- the following assignments were done in RFC 1494, using 2130 -- slightly different names, but the same numbers. 2131 -- their defining text is now is now in other documents 2132 id-mime-postscript-body OBJECT IDENTIFIER ::= 2133 { mixer-bp-data 2} 2135 draft X.400/MIME body mapping May 96 2137 id-mime-jpeg-body OBJECT IDENTIFIER ::= 2138 { mixer-bp-data 3} 2140 id-mime-gif-body OBJECT IDENTIFIER ::= 2141 { mixer-bp-data 4}; 2143 -- This is a new definition, and defines an FTAM application reference, 2144 -- not a BP15 data OID. 2145 id-mime-ftbp-data OBJECT IDENTIFIER ::= 2146 { mixer-bp-data 5 } 2148 draft X.400/MIME body mapping May 96 2150 Appendix C: Registration information for the Teletex 2151 character set 2153 The Teletex character set is a character set in which the 2154 ISO 2022 character set switching mechanism may be used to 2155 switch between the following registered ISO character 2156 sets: 2158 ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set 2159 ISO-IR-102 - a fairly standard US-ASCII variant 2160 ISO-IR-103 - Latin characters using non-spacing accents 2161 ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more. 2162 ISO-IR-107 - Control characters for C1 use 2164 Its intended use of this character set is to represent 2165 data that comes from ISO protocols that use the ASN.1 2166 construct "TeletexString" or "T61string" without 2167 conversion. 2169 The set of allowed character sets can be found in CCITT 2170 recommendation X.208(1988), chapter 31.2 and Table 2171 6/X.208. 2173 The rules for encoding the data type can be found in CCITT 2174 recommendation X.209(1988), chapter 23. It states that at 2175 the beginning of the string, G0 is always ISO-IR-102, C0 2176 is ISO-IR-106, and C1 is ISO-IR-107. 2178 The specification seems somehow to have missed the 2179 implicit assumption that ISO-IR-103 is designated and 2180 invoked as G1 and shifted into the upper half of the 2181 character set which seems to be assumed at least by the 2182 X.400 and X.500 software that uses TeletexStrings; 2183 implementors should act as if the sequence ESC 2/9 7/6 2184 LS1R is always present at the beginning of the data. 2186 The rules for interpreting T.61 data are found (I believe) 2187 in CCITT recommendations T.51, T.52 and T.53 (data from 2188 the ITU WWW server): 2190 draft X.400/MIME body mapping May 96 2192 T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93] 2193 Latin based coded character sets for telematic services 2194 T.52 (1993) [New] [88 pp.] [Publ.: Apr.94] 2195 Non-Latin coded character sets for telematic services 2196 T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95] 2197 Character coded control functions for telematic services 2199 The Teletex character set is closely related to (but not 2200 identical with) that specified in ISO 6937. 2202 No further restrictions are imposed by this registration; 2203 in particular, character set switching can occur anywhere, 2204 and there is no guarantee that the character sets will be 2205 switched "back" at the end. 2207 draft X.400/MIME body mapping May 96 2209 Appendix D: IANA Registration form for new mappings 2211 To: IANA@isi.edu 2212 Subject: Registration of new X.400/MIME content type mapping 2214 MIME type name: 2216 (this must have been registered previously with IANA) 2218 X.400 body part: 2220 IF BP15: 2222 - X.400 Object Identifier for Data: 2224 (If left empty, an OID will be assigned by IANA under 2225 mixer-bp-data) 2227 - X.400 Object Identifier for Parameters: 2229 (If left empty, an OID will be assigned by IANA under 2230 mixer-bp-parameter. If it is not used, fill in the 2231 words NOT USED.) 2233 X.400 ASN.1 Syntax: 2235 (must be an EXTENDED-BODY-PART-TYPE macro, or refer� 2236 ence to a Basic body part type) 2238 IF FTBP: 2240 - FTAM Object Identifier for application-reference: 2242 - FTAM Object Identifier for contents-type: 2244 (if left empty, unstructured-binary is assumed) 2246 Conversion algorithm: 2248 (must be defined completely enough for independent im� 2249 plementation. It may be defined by reference to RFCs). 2251 Person & email address to contact for further informa� 2252 tion: 2254 draft X.400/MIME body mapping May 96 2256 INFORMATION TO THE SUBMITTER: 2258 The accepted registrations will be listed in the "As� 2259 signed Numbers" series of RFCs. The information in 2260 the registration form is freely distributable. 2262 Table of Contents 2264 Status of this Memo ................................ 1 2265 1 Introduction ...................................... 2 2266 1.1 Glossary ........................................ 2 2267 2 Basic rules for body part conversion .............. 3 2268 2.1 Generating the IPM Body from MIME ............... 5 2269 2.2 Generating the MIME Body from the IPMS.Body ..... 5 2270 2.3 Mapping the EMA FTBP parameters ................. 7 2271 2.3.1 Mapping GraphicStrings ........................ 7 2272 2.3.2 Mapping specific parameters ................... 8 2273 2.3.3 Summary of FTBP elements generated ............ 11 2274 2.4 Information that is lost when mapping ........... 12 2275 3 Encapsulation of body parts ....................... 13 2276 3.1 Encapsulation of MIME in X.400 .................. 13 2277 3.1.1 FTBP encapsulating body part .................. 14 2278 3.1.2 BP15 encapsulating body part .................. 15 2279 3.1.3 Encapsulation using IA5 (HARPOON) ............. 17 2280 3.1.4 Content passing using BP14 .................... 18 2281 3.2 Encapsulating X.400 Body Parts in MIME .......... 18 2282 3.3 Encapsulating FTBP body parts in MIME ........... 19 2283 4 User control over the gateway choice .............. 20 2284 4.1 Conversion from MIME to X.400 ................... 21 2285 4.2 Conversion from X.400 to MIME ................... 23 2286 5 The equivalence registry .......................... 24 2287 5.1 What information one must give about a mapping 2288 ................................................ 24 2289 5.2 Equivalence summary for known X.400 and MIME 2290 Types .......................................... 25 2291 5.3 MIME to X.400 Table ............................. 26 2292 5.4 X.400 to MIME Table ............................. 27 2293 5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 28 2294 6 Defined Equivalences .............................. 30 2295 6.1 IA5Text - text/plain ............................ 30 2296 6.2 GeneralText - text/plain (ISO-8859) ............. 31 2297 6.3 BilaterallyDefined - application/octet-stream 2299 draft X.400/MIME body mapping May 96 2301 ................................................ 33 2302 6.4 FTBP EMA Unknown Attachment - applica� 2303 tion/octet-stream .............................. 34 2304 6.5 MessageBodyPart - message/RFC822 ................ 35 2305 6.6 MessageBodyPart - multipart/* ................... 35 2306 6.7 Teletex - Text/Plain (Teletex) .................. 37 2307 7 Body parts where encapsulation is recommended ..... 39 2308 7.1 message/external-body ........................... 39 2309 7.2 message/partial ................................. 40 2310 7.3 multipart/signed ................................ 41 2311 7.4 multipart/encrypted ............................. 42 2312 8 Conformance requirements .......................... 43 2313 9 Security considerations ........................... 44 2314 10 Author's address ................................. 44 2315 11 Acknowledgements ................................. 45 2316 References ......................................... 45 2317 APPENDIXES ......................................... 47 2318 Appendix A: Escape code normalization .............. 47 2319 Appendix B: OID Assignments ........................ 49 2320 Appendix C: Registration information for the 2321 Teletex character set .......................... 51 2322 Appendix D: IANA Registration form for new map� 2323 pings .......................................... 53 2324 Table of Contents .................................. 54