idnits 2.17.1 draft-ietf-mixer-bodymap-05.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-05.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-mixer-bodymap-05.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mixer-bodymap-05.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-05.txt.', but the file name used is 'draft-ietf-mixer-bodymap-05' ** 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 53 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 20 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 180: '...rmant MIXER gateway MUST be able to be...' RFC 2119 keyword, line 378: '...rity precautions MUST be taken in usin...' RFC 2119 keyword, line 423: '... with "content-" SHOULD be put into th...' RFC 2119 keyword, line 494: '... A gateway MAY choose to support th...' RFC 2119 keyword, line 495: '... available, but MUST support this lim...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 344 has weird spacing: '...andling of e...' == Line 414 has weird spacing: '...pped to exten...' == Line 1127 has weird spacing: '...-stream bila...' == Line 1506 has weird spacing: '...mapping is re...' == Line 2203 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 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 1244 -- Looks like a reference, but probably isn't: '1' on line 1245 -- Looks like a reference, but probably isn't: '2' on line 1246 == Missing Reference: 'UNIVERSAL 8' is mentioned on line 1239, but not defined == Missing Reference: 'UNIVERSAL 7' is mentioned on line 1248, but not defined -- Looks like a reference, but probably isn't: '100' on line 2000 == Missing Reference: 'New' is mentioned on line 2166, but not defined == Unused Reference: 'RFC-822' is defined on line 1881, but no explicit reference was found in the text == Unused Reference: 'RFC-X400USE' is defined on line 1926, 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 May 96 3 Mapping between X.400 and RFC-822/MIME Message Bodies 5 Mon May 6 00:56:05 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-05.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 (5) Where no mapping is known by the gateway, it may 177 choose to drop the body part, reject the message, 178 or encapsulate the body part as described in 179 chapter 3. The choice may be configurable, but a 180 conformant MIXER gateway MUST be able to be 182 draft X.400/MIME body mapping May 96 184 configured for encapsulation. 186 In many cases, a message that goes SMTP->X.400->SMTP will 187 arrive without loss of information. 189 In some cases, the reverse translation may not be 190 possible, or two gateways may choose to apply different 191 translations, based on the criteria above, leading to an 192 apparently inconsistent service. 194 In addition, service will vary because some gateways will 195 have implemented conversions not implemented by other 196 gateways. 198 This is believed to be unavoidable. 200 2.1. Generating the IPM Body from MIME 202 When converting the body of a message from MIME to X.400, 203 the following steps are taken: 205 If the header does not contain a 822.MIME-Version field, 206 then generate a IPMS.Body with a single IPMS.BodyPart of 207 type IPMS.IA5TextBodyPart with 208 IPMS.IA5TextBodyPart.parameters.repertoire set to the 209 default (IA5) containing the body of the RFC 822 message. 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 If there is more than one body part, and the first body 221 part is IA5 and starts with the string "RFC-822-Headers:" 222 as the first line, then the remainder of this body part 223 shall be appended to the RFC 822 header. This relies upon 224 the theory that this body part has been generated 225 according to Appendix B of MIXER. A gateway shall check 226 the consistency and syntax of this body part, to ensure 228 draft X.400/MIME body mapping May 96 230 that the resulting message is conformant with RFC 822. 232 If the remaining IPMS.Body consists of a single 233 IPMS.Bodypart, there are three possibilities. 235 (1) If it is of type IPMS.IA5Text, and the first line 236 is "MIME-Version: 1.0", it is assumed to be a 237 HARPOON-encapsulated body part. The complete body 238 content is then appended to the headers; the 239 separating blank line is inside the message. If an 240 RFC 822 syntax error is discovered inside the 241 message, it may be mapped directly as described 242 below instead. 244 (2) If it is of type IPMS.IA5Text, then this is mapped 245 directly and no MIME encoding is used. 247 (3) All other types are mapped according to the 248 mappings configured and implemented in the gateway. 250 If the IPMS.Body contains multiple IPMS.Bodypart fields, 251 then a MIME message of content type multipart is 252 generated. If all of the body parts are messages, then 253 this is multipart/digest. Otherwise it is 254 multipart/mixed. The components of the multipart are 255 generated in the same order as in the IPMS.Body. 257 Each component is mapped according to the mappings 258 configured and implemented in the gateway; any IA5 body 259 parts are checked to see if they are HARPOON mappings. 261 2.3. Mapping the EMA FTBP parameters 263 DISCUSSION: 265 EMA has defined a profile for use of the File Transfer 266 Body Part (FTBP). [MAWG] 268 draft X.400/MIME body mapping May 96 270 New mappings are expected to use this as the mechanism for 271 carrying body parts, and since it is important to have a 272 consistent mapping for the special FTBP parameters, these 273 are defined here. 275 The mapping of the body will depend on the content-type in 276 MIME and on the application-reference in FTBP, and is not 277 specified here. 279 However, in many cases, we expect that the translation 280 will involve simply copying the octets from one format to 281 the other; that is, "no conversion". 283 2.3.1. Mapping GraphicStrings 285 Some parameters of the EMA Profile are encoded as ASN.1 286 GraphicStrings, which are troublesome because they can 287 contain any ISO registered graphic character set. 288 To map these to ASCII for use in mail headers, the gateway 289 may either: 291 (1) Use the RFC 1522 encoding mechanism to create 292 appropriate encoded-words for the headers involved. 293 Note that in some cases, such as within Content- 294 Disposition filenames, the encoded-words must be in 295 quotes, which is not the normal usage of encoded- 296 words. 298 (2) Apply the normalization procedure given in Appendix 299 A to identify the ASCII characters of the string, 300 and replace all non-ASCII characters with the 301 question mark (?). 303 Both procedures are valid for MIXER gateways; the 304 simplified procedure of ignoring escape sequences and bit- 305 stripping the result is NOT valid. 307 2.3.2. Mapping specific parameters 309 The following parameters are mapped in both directions: 311 draft X.400/MIME body mapping May 96 313 Content-ID 315 The mapping of this element is complex. 317 The Content-ID is encoded as an IPM.MessageIdentifier 318 and entered into the 319 FTBP.FileTransferParameters.related-stored-file. 320 file-identifier.cross-reference.message-reference. 322 FTBP.FileTransferParameters.related-stored-file. 323 relationship.descriptive-relationship is set to the 324 string "Internet MIME Body Part". 326 FTBP.FileTransferParameters.related-stored-file. 327 file-identifier.cross-reference.application- 328 crossreference is set to a null OCTET STRING. 330 The reverse mapping is only performed if the 331 FTBP.FileTransferParameters.related-stored-file. 332 relationship.descriptive-relationship has the string 333 value "Internet MIME Body Part". 335 Content-Description 337 This is mapped to and from the first string in 338 FTBP.FileTransferParameters.environment.user-visible- 339 string. 341 Content-Disposition 343 This field is defined in [CDISP]. It has multiple 344 components; the handling of each component is 345 given below. 347 The "disposition" component is ignored on MIME -> 348 X.400 mapping, and is always "attachment" on X.400 -> 349 MIME mapping. 351 NOTE: RFC 1806 gives only the "filename" component. 352 The other components are expected to be added to the 354 draft X.400/MIME body mapping May 96 356 next version of 1806. 358 C-D: filename 360 The filename component of the C-D header is mapped to 361 and from FileTransferParameters.file- 362 attributes.pathname. 364 The EBNF.disposition-type is ignored when creating 365 the FTBP pathname, and always set to "attachment" 366 when creating the Content-Disposition header. For 367 example: 369 Content-Disposition: attachment; filename=3Ddodo.doc 371 or 373 Content-Disposition: attachment; filename=3D/etc/passwd 375 The filename will be carried as a single incomplete- 376 pathname string. No special significance is assumed 377 for the characters "/" and "\". Note that normal 378 security precautions MUST be taken in using a 379 filename on a local file system; this should be 380 obvious from the second example. 382 This is done to be conformant with the EMA Profile. 384 C-D: Creation-date 386 Mapped to and from FileTransferParameters.file- 387 attributes.date-and-time-of-creation 389 For this and all other date fields, the RFC-822 date 390 format is used (822.date-time). Note that the 391 parameter syntax of 1802 requires that all dates be 392 quoted! 394 C-D: Modification-date 396 Mapped to and from FileTransferParameters.file- 397 attributes.date-and-time-of-last-modification 399 draft X.400/MIME body mapping May 96 401 C-D: Read-date 403 Mapped to and from FileTransferParameters.file- 404 attributes.date-and-time-of-last-read-access 406 C-D: Size 408 Mapped to and from FileTransferParameters.file- 409 attributes.object-size. If the value is "no-value- 410 available", the component is NOT generated. 412 Other RFC-822 headers 414 Mapped to extension in 415 FTBP.FileTransferParameters.extensions using the 416 rfc-822-field HEADING-EXTENSION from [MIXER]. 418 NOTE: 419 The set of headers that are mapped will depend on the 420 placement of the body part (single body part or 421 multipart). 422 When it is the only body of a message, headers 423 starting with "content-" SHOULD be put into the FTAM 424 extension, and all other headers should be put into 425 the IPMS extension for the message. 426 When it is a single bodypart of a multipart, ALL 427 headers on the body part are included, since there is 428 nowhere else to put them. Note that only headers that 429 start with "content-" have defined semantics in this 430 case. 432 EMA NOTE 434 The EMA profile, version 1.5, specifies that handling 435 of extensions is Optional for reception. This means 436 that some non-MIXER gateways may not implement 437 handling of this field, and some UAs may not have the 438 possibility of showing the content of this field to 439 the user. 441 An alternative approach using 443 draft X.400/MIME body mapping May 96 445 FTBP.FileTransferParameters.environment.user-visible- 446 string was suggested to EMA, and the EMA MAWG 447 recommended in its April 1996 conference that the 448 IETF MIXER group should rather choose this approach. 450 2.3.3. Summary of FTBP elements generated 452 This is a summary of the preceding section, and does not 453 add new information. 455 The following elements of the FTBP parameters are mapped 456 or used (the rightmost column gives their status in the 457 EMA profile; M=3DMandatory, O=3DOptional, R=3DRecommended for 458 Origination/Receipt): 460 FileTransferParameters M/= 461 M 462 Related-Stored-File O/= 463 O 464 file-identifier 465 cross-reference 466 application-crossreference NULL 467 message-reference Content-ID 468 descriptive-relationship Used as marker 469 contents-type Must be unstructured-binary M/= 470 M 471 environment M/= 472 M 473 application-reference Selects mapping M/= 474 M 475 user-visible-string Content-description R/= 476 M 477 file-attributes 478 pathname C-D: Filename R/= 479 M 480 date-and-time-of-creation C-D: Creation-Date O/= 481 O 482 date-and-time-of-last-modification C-D: Modification-Date R/= 483 M 484 date-and-time-of-last-read-access C-D: Read-Date O/= 485 O 486 object-size C-D: Size R/= 487 M 488 Extensions Other headers O/O 490 All other elements of the FTBP parameters are discarded. 492 NOTE: There is ongoing work on defining a more complete 493 mapping between FTBP headers and a set of RFC-822 headers. 494 A gateway MAY choose to support the larger set once it is 495 available, but MUST support this limited set. 497 draft X.400/MIME body mapping May 96 499 2.4. Information that is lost when mapping 501 MIME defines fields which add information to MIME 502 contents. Two of these are "Content-ID", and "Content- 503 Description", but MIME allows new entities to be defined 504 at any time. 506 The possibilities are limited about what one can do with 507 this information: 509 (1) When using encapsulation, the information can be 510 preserved 512 (2) When using mapping to FTBP, the information can be 513 preserved in the environment.user-visible-string 515 (3) When mapping to a single-body message, the 516 information can be preserved as P22 header 517 extensions 519 (4) When mapping to other body part types, the 520 information must be discarded. 522 3. Encapsulation of body parts 524 Where no mapping is possible, the gateway may choose any 525 of the following alternatives: 527 - Discard the body part, leaving a "marker" saying what 528 happened 530 - Reject the message 532 - "Encapsulate" the body part, by wrapping it in a body 533 part defined for that purpose in the other mail 534 system 536 The choice to be made should be configurable in the 537 gateway, and may depend on both policy and knowledge of 538 the recipient's capabilities. 540 draft X.400/MIME body mapping May 96 542 3.1. Encapsulation of MIME in X.400 544 Four body parts are defined here to encapsulate MIME body 545 parts in X.400. 547 The BP15 body part is backwards compatible with RFC 1494. 548 The FTBP body part is compatible with the EMA MAWG 549 document [MAWG], version 1.5, but has some extensions, in 550 particular the one for extra headers. 552 The imagined scenarios for each body part are: 554 FTBP For use when sending to recipients that can handle 555 generic FTBP, and for tunnelling MIME to a MIME UA 557 BP15 For use when tunnelling MIME to a MIME UA through an 558 X.400(88) network, or to UAs that have been written 559 to RFC 1494 561 IA5 For use when tunneling MIME to a MIME UA through an 562 X.400 network, where some of the links may involve 563 X.400(84). 565 BP14 For use when the recipient may be an X.400(84) UA 566 with BP14 handling capability, and the loss of 567 information in headers is not regarded as important. 569 but the gateway is free to use any method it finds 570 appropriate in any situation. 572 FTBP is expected to be the most useful body part in 573 sending to X.400(92) systems, while the BP14 content 574 passing is primarily useful for sending to X.400(84) 575 systems. 577 3.1.1. FTBP encapsulating body part 579 This body part utilizes the fundamental assumption in MIME 580 that all message content can be legally and completely 581 represented by a single octet stream, the "canonical 582 format". 584 The FTBP encapsulating body part is defined by the 585 application-reference id-mime-ftbp-data; all headers are 587 draft X.400/MIME body mapping May 96 589 mapped to the FTBP headers, including putting the 590 "Content-type:" header inside the UserVisibleString. 592 Translation from the MIME body part is done by: 594 - Undoing the content-transfer-encoding 596 - Setting the "FileTransferData.FTdata.value.octet- 597 aligned" to the resulting string of octets 599 - Putting the appropriate parameters into the headers. 601 Reversing the translation is done by: 603 - Extracting the headers 605 - Applying an appropriate content-transfer-encoding to 606 the body. If this is for some reason different from 607 the content-transfer-encoding: header retrieved from 608 the headers, the old one must be deleted. 610 This mapping is lossless, and therefore counts as "no 611 conversion". 613 3.1.2. BP15 encapsulating body part 615 This section defines an extended body part, based on body 616 part 15, which may be used to hold any MIME content. 618 mime-body-part EXTENDED-BODY-PART-TYPE 619 PARAMETERS MimeParameters 620 IDENTIFIED BY id-mime-bp-parameters 621 DATA OCTET STRING 622 ::=3D id-mime-bp-data 624 MimeParameters ::=3D 625 SEQUENCE { 626 content-type IA5String, 627 content-parameters SEQUENCE OF 628 SEQUENCE { 629 parameter IA5String,= 631 parameter-value IA5String 632 } 634 draft X.400/MIME body mapping May 96 636 other-header-fields RFC822FieldList 637 } 639 The OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime- 640 bp-data are defined in Appendix B. A MIME content is 641 mapped onto this body part. The MIME headers of the body 642 part are mapped as follows: 644 Content-Type: 645 The "type/subtype" string is mapped to 646 MimeParameters.content-type. 648 For each "parameter=3Dvalue" string create a 649 MimeParameters.content-parameters element. The 650 MimeParameters.content-Parameters.parameter field is 651 set to the parameter and the MimeParameters.content- 652 parameters.parameter-value field is set to the value. 654 Quoting is preserved in the parameter-value. 656 Other 657 Take all other headers and create 658 MimeParameters.other-header-fields. 660 The MIME-version, content-type and content-transfer- 661 encoding fields are NOT copied. 663 NOTE: 664 The set of headers that are mapped will depend on the 665 placement of the body part (single body part or 666 multipart). 667 When it is the only body of a message, headers 668 starting with "content-" SHOULD be put into the 669 other-header-fields, and all other headers should be 670 put into the IPMS extension for the message. 671 When it is a single bodypart of a multipart, ALL 672 headers on the body part are included, since there is 673 nowhere else to put them. Note that only headers that 674 start with "content-" have defined semantics in this 675 case. 677 draft X.400/MIME body mapping May 96 679 The body is mapped as follows: 681 Convert the MIME body part into its canonical form, as 682 specified in Appendix H of MIME [MIME]. This canonical 683 form is used to generate the mime-body-part.data octet 684 string. 686 The Parameter mapping may be used independently of the 687 body part mapping (e.g., in order to use a different 688 encoding for a mapped MIME body part). 690 This body part contains all of the MIME information, and 691 so can be mapped back to MIME without loss of information. 693 The OID id-mime-bp-data is added to the Encoded 694 Information Types of the envelope. 696 This body part is completely compatible with RFC 1494. 698 When converting back to a MIME body part, the gateway is 699 responsible for: 701 (1) Selecting an appropriate content-transfer-encoding, 702 and deleting any content-transfer-encoding header 703 from the other-header-fields 705 (2) Adding quotes to any parameters that need them (but 706 not adding quotes to parameters that are already 707 quoted) 709 (3) Removing any content-type field that is left in the 710 RFC822FieldList of the message that is redundant or 711 conflicting with the one from the mime-body-part 713 (4) Make sure that on multipart messages, the boundary 714 string actually used is reflected in the boundary=3D 715 parameter of the content-type header, and does not 716 occur within the body of the message. 718 3.1.3. Encapsulation using IA5 (HARPOON) 720 This approach is the one taken in RFC 1496 - HARPOON - for 721 tunneling any MIME body part through X.400/84 networks. It 723 draft X.400/MIME body mapping May 96 725 has proven rather unhelpful for bringing information to 726 X.400 users, but preserves all the information of a MIME 727 body part. 729 The following IA5Text body part is made: 731 - Content =3D IA5String 733 - First bytes of content: (the description is in US 734 ASCII, with C escape sequences used to represent 735 control characters): 737 MIME-version: \r\n 738 Content-type: \r\n 739 Content-transfer-encoding: <7bit, quoted-printable or base64>\r\= 740 n 741 742 \r\n 743 746 All implementations MUST place the MIME-version: header 747 first in the body part. Headers that are placed by [MIXER] 748 into other parts of the message MUST NOT be placed in the 749 MIME body part. 751 3.1.4. Content passing using BP14 753 This is described in this section because it is at the 754 same conceptual level as encapsulation. It is a lossy 755 transformation; it is impossible to reconstruct the MIME 756 type information from it. 758 Nevertheless, there is a demand for such functionality. 760 This "encapsulation" simply strips off all headers, undoes 761 the content-transfer-encoding, and creates a 762 BilaterallyDefined body part (BP14) from the resulting 763 octet stream. 765 No reverse translation is defined; when a BP14 arrives at 766 a MIXER gateway, it will be turned into an 767 application/octet-stream according to chap. 6.3 769 draft X.400/MIME body mapping May 96 771 3.2. Encapsulating X.400 Body Parts in MIME 773 This section specifies a generic mechanism to map X.400 774 body parts to a MIME content. This allows for the body 775 part to be tunneled through MIME. It may also be used 776 directly by an appropriately configured MIME UA. 778 This content-type is defined to carry any X.400 extended 779 body part. The mapping of all standard X.400 body parts 780 is defined in RFC1494bis. The content-type field is 781 "application/x400-bp". The parameter is defined by the 782 EBNF: 784 mime-parameter =3D "bp-type=3D" object-identifier 786 The EBNF.object-identifier is set to the OBJECT IDENTIFIER 787 from IPMS.body.externally-defined.data.direct-reference. 789 For example, a Videotex body part will have 791 Content-type=3Dapplication/x400-bp; bp-type=3D2.6.1.4.5 793 The body contains the raw ASN.1 IPM body octet stream, 794 that is, the BER encoding of the IPM.Body.BodyPart, 795 including the initial tag octet. The content may use a 796 content- transfer-encoding of either base64 or quoted- 797 printable when carried in 7-bit MIME. It is recommended 798 to use the one which gives the more compact encoding of 799 the data. If this cannot be determined, Base64 is 800 recommended. No attempt is made to turn the parameters of 801 Extended Body Parts into MIME parameters, as this cannot 802 be done in a general manner. 804 Standard X.400 body parts may not be encoded directly by 805 this mechanism, but may be encoded indirectly by first 806 translating to the extended representation. 808 NOTE: RFC 1494 defined a bp-type=3D for encoding 809 standard X.400 body parts. If such body parts are 810 encountered, RFC 1494 section 6.1 should be consulted. 812 draft X.400/MIME body mapping May 96 814 3.3. Encapsulating FTBP body parts in MIME 816 The File Transfer Body Part is believed to be important in 817 the future as "the" means of carrying well-identified data 818 in X.400 networks. 820 They also share the property (at lest when limited to the 821 EMA MAWG functional profile) of having a well-defined data 822 part that is always representable as a sequence of bytes. 824 This conversion will have to fail, and the x400-bp 825 encapsulation used instead, if: 827 - FileTransferData has more than one element 829 - Contents-type is not unstructured-binary 831 - Parameters that are not mappable, but important, are 832 present (like Compression, which EMA doesn't 833 recommend). 835 Otherwise, it can be encapsulated in MIME by: 837 - Creating the "content-type" value by forming the 838 string "application/x-ftbp." and appending the 839 numbers of the OID 841 - Mapping all other parameters according to the 842 standard FTBP parameter mapping 844 - Applying an appropriate content-transfer-encoding 846 DISCUSSION: 848 The choice of the somewhat strange, and by necessity 849 unregistered, MIME type "application/x-ftbp.n.n.n.n" is 850 because for any concrete example of this usage, it will be 851 easy to configure any MIME reader to take advantage of the 852 identification. If the MIME type registration rules are 853 ever changed to allow the registration of a namespace, 854 rather than just of names, the "x-" can be deleted, and 855 the types can be "application/ftbp.n.n.n.n". 857 draft X.400/MIME body mapping May 96 859 4. User control over the gateway choice 861 In some cases, the gateway may make an inappropriate 862 choice when deciding what to do about a particular body 863 part. 865 To allow an escape clause, this chapter defines a way in 866 which the user can signal the gateway what action it finds 867 most appropriate. 869 The headers given here override any "conversion 870 prohibited" and "conversion with loss prohibited" on the 871 message. 873 It is still the gateway's responsibility that the 874 generated messages conform to the destination domain's 875 syntax rules. 877 DISCUSSION: 879 The intent of this mechanism is to allow the sender to 880 efficiently get a message through to a single recipient 881 when the sender has information about the recipient that 882 the gateway does not have. 884 It is not a part of the minimum functionality listed in 885 chapter 8; a gateway does not have to implement this spec 886 to be MIXER conformant, but if implemented, it should be 887 done like this. 889 The additional complexity, both in user interface and in 890 protocol, of making this field selectable per recipient 891 was not thought worthwhile; 893 4.1. Conversion from MIME to X.400 895 The header field described below specifies explicit MIXER 896 conversion. Comments are allowed within the field 897 according to the usual RFC 822 convention. 899 If "x400-object-id" is omitted, "tunnel" is assumed. 901 mime-to-x400 =3D "Wanted-X400-Conversion" ":" 903 draft X.400/MIME body mapping May 96 905 [ mime-from ] [ x400-object-id ] 906 "in" x400-encoding 908 x400-object-id =3D "to" ( object-identifier-2 / "tunnel" ) 909 x400-encoding =3D "bp14" / "bp15" / "ftbp" / "ia5" 910 mime-from =3D "from" mime-type 911 mime-type =3D word 913 There is no way to ask for a different conversion based on 914 MIME parameters or bodypart content. 916 Examples: 918 Wanted-X400-Conversion: from application/msword 919 to 1.2.840.113556.4.2 (Microsoft defined ms-word) 920 in ftbp 922 This uses the MAWG definitions, and leads to an FTBP encoding. 924 Wanted-X400-Conversion: from application/msword 925 to tunnel in bp14 927 This leads to a Body Part 14 encoding for all body parts of type 928 application/msword. 930 Wanted-X400-Conversion: in bp14 932 This requests that this specific body part be encoded in Body Part 14= 933 =2E 935 This field may be used in two places: 937 (1) In the heading of an unstructured MIME body part. 938 In this case the EBNF.mime-from is omitted, and the 939 requested conversion applies to the body part. 941 (2) In a multipart. In this case, the body part type to 942 which the conversion applies is defined by 943 EBNF.mime-from, and the conversion applies to all 944 body parts of this MIME type contained in the 945 multipart, including those contained in nested 946 messages and multiparts. If a contained body part 947 has its own heading, this takes precedence. Note 949 draft X.400/MIME body mapping May 96 951 that the "from" parameter is mandatory when used in 952 a multipart. 954 The EBNF.x400-object-id shall be present when "bp15" or 955 "ftbp" encoding is selected. 957 The value "tunnel" implies encapsulation as defined in 958 Chapter 3. 960 The "object identifier" used below is: 962 - For BP 15, it is the value of the EXTENDED-BODY-PART- 963 TYPE macro that defines the body part, which is found 964 in ExternallyDefinedBodyPart.data.direct-reference. 966 - For FTBP, it is the value of the 967 Environment.application-reference. 969 4.2. Conversion from X.400 to MIME 971 The IPM heading defined here shall be present in the 972 heading of a message. It defines the mapping for all body 973 parts of the specified types, including those in nested 974 messages. 976 wanted-MIME-conversion HEADING-EXTENSION 977 VALUE WantedMIMEConversions 978 ::=3D id-wanted-MIME-conversions 980 WantedMIMEConversions ::=3D SEQUENCE OF X400toMIMEConversion 982 X400toMIMEConversion ::=3D SEQUENCE { 983 x400-type X400Type, 984 mime-type MIMEType } 986 X400Type ::=3D CHOICE { 987 standard [0] INTEGER, -- standard body part 988 extended [1] OBJECT IDENTIFIER, -- BP 15 989 ftbp [2] OBJECT IDENTIFIER} -- FTBP application-refer= 990 ence 992 draft X.400/MIME body mapping May 96 994 MIMEType ::=3D SEQUENCE { 995 type IA5String, -- type (e.g., application/ms-word) 996 encoding [1] IA5String OPTIONAl -- e.g. quoted-printable 997 parameters [2] IA5String OPTIONAL } -- MIME Parameters 999 The heading extension includes all requested conversions, 1000 with explicit information as to how each body part type is 1001 encoded in MIME. 1003 FTBP is identified as a separate body part type, as there 1004 will be a need for different encodings, dependent on what 1005 is being carried. 1007 Encapsulation is requested by asking for 1008 "application/x400-bp" or "application/ftbp" as the 1009 destination type. 1011 For FTAM body parts, the parameters will survive the 1012 gatewaying process. For other body parts, there are three 1013 alternatives: 1015 (1) The gateway knows a defined mapping for this 1016 particular body part and destination type. It will 1017 be used, and parameters mapped accordingly. 1019 (2) The gateway knows how to extract an OCTET STRING 1020 from the body part, and the destination is a simple 1021 MIME body part. All information outside the OCTET 1022 STRING is lost. (This may be the case for a BP14 1023 that should end up in an application/xyzzy, for 1024 instance). 1026 (3) The gateway knows of no relevant mapping, and does 1027 not know how to simplify the X.400 body part. The 1028 gateway will then proceed as if the mapping control 1029 field had not been present. 1031 5. The equivalence registry 1033 5.1. What information one must give about a mapping 1035 The following information MUST be supplied when describing 1036 an equivalence or a mapping: 1038 draft X.400/MIME body mapping May 96 1040 MIME type name (which must be preregistered) 1042 X.400 body part (often BP15 or FTAM Body Part) 1044 If BP15 is used, the following information must be given: 1046 (1) Object Identifier for X.400 BP15 Data 1048 (2) Object Identifier for X.400 BP15 Parameters 1050 (3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART- 1051 TYPE macro) 1053 If FTBP is used, the following information must be given: 1055 (1) Object Identifier for the FTAM 1056 Environment.application-reference 1058 (2) Object Identifier for the FTAM Contents-type, if 1059 unstructured-binary is not used 1061 (3) Any other special considerations 1063 In all cases, the following must be given: 1065 Conversion algorithms. The expected effect of "Conversion 1066 prohibited" and "Conversion with loss prohibited" should 1067 be noted. 1069 The conversion must be specified with enough detail to 1070 permit independent implementation; literature references 1071 are acceptable. 1073 An equivalence can be registered with IANA using the form 1074 at the end of this document. The purpose of the 1075 registration is to achieve a greater uniformity among 1076 gateways implementing the same translation; there is no 1077 requirement that a gateway must support all of the 1078 translations that are registered with IANA. Specific 1079 conformance requirements for MIXER are given at the end of 1080 this document. 1082 draft X.400/MIME body mapping May 96 1084 5.2. Equivalence summary for known X.400 and MIME Types 1086 This section itemizes the equivalences for all currently 1087 known MIME content-types and X.400 body parts. 1089 For each MIME content-type/X.400 body part pair, the 1090 equivalence table contains an entry with the following 1091 sections: 1093 X.400 Body Part 1094 This section identifies the X.400 Body Part governed 1095 by this Table entry. It includes any OBJECT 1096 IDENTIFIERs or other parameters necessary to uniquely 1097 identify the Body Part. 1099 MIME Content-Type 1100 This section identifies the MIME content-type 1101 governed by this Table entry. The MIME content-type 1102 named here must be registered with the IANA. 1104 Section/document reference 1105 Reference to section of this document, or to the 1106 other document that describes this mapping. 1108 The initial Equivalence Table entries in this document are 1109 described using this convention. 1111 Further registrations of equivalences should be submitted 1112 to the IANA after a public review, using the example form 1113 given at the end of this document. 1115 5.3. MIME to X.400 Table 1117 MIME content-type X.400 Body Part Section 1118 ----------------- ------------------ ------- 1119 text/plain 1120 charset=3Dus-ascii ia5-text 6.1 1121 charset=3DISO-8859-x EBP - GeneralText 6.2 1122 text/richtext no mapping defined Encap 1123 application/oda EBP - ODA [ODA] 1125 draft X.400/MIME body mapping May 96 1127 application/octet-stream bilaterally-defined or 6.3 1128 FTBP unknown attachment 6.4 1129 application/postscript EBP - mime-postscript-body [POSTSCRIPT] 1130 image/g3fax g3-facsimile [IMAGES] 1131 image/jpeg EBP - mime-jpeg-body [IMAGES] 1132 image/gif EBP - mime-gif-body [IMAGES] 1133 audio/basic no mapping defined Encap 1134 video/mpeg no mapping defined Encap 1135 message/RFC822 ForwardedIPMessage 6.5 1136 multipart/* ForwardedIPMessage 6.6 1137 multipart/signed HARPOON encap 7.3 1138 multipart/encrypted HARPOON encap 7.4 1140 Abbreviation: EBP - Extended Body Part 1142 5.4. X.400 to MIME Table 1143 Basic Body Parts 1145 X.400 Basic Body Part MIME content-type Section 1146 --------------------- -------------------- ------- 1147 ia5-text text/plain;charset=3Dus-ascii 6.1 1148 voice No Mapping Defined Encap 1149 g3-facsimile image/g3fax [IMAGES] 1150 g4-class1 no mapping defined Encap 1151 teletex text/plain;charset=3Dteletex 6.7 1152 videotex no mapping defined Encap 1153 encrypted no mapping defined Encap 1154 bilaterally-defined application/octet-stream 6.3 1155 nationally-defined no mapping defined Encap 1156 externally-defined See Extended Body Parts below 1157 ForwardedIPMessage message/RFC822 or multipart 6.5,6.6 1159 X.400 Extended Body Part MIME content-type Section 1160 ------------------------- -------------------- ------- 1161 GeneralText text/plain;charset=3DISO-8859-x 6.2 1162 ODA application/oda [ODA] 1163 mime-postscript-body application/postscript [POSTSCRIPT= 1164 ] 1165 mime-jpeg-body image/jpeg [IMAGES] 1166 mime-gif-body image/gif [IMAGES] 1167 FTAM various 2.3,6.4 1169 FTAM application ID MIME content type Section 1170 ------------------- ----------------- ------- 1171 ema-unknown-attachment application/octet-stream 6.4 1173 draft X.400/MIME body mapping May 96 1175 5.5. Use of OBJECT IDENTIFIERs and ASN.1 MACROS 1177 When one wants to define new BP15 body parts for use with 1178 equivalences, it is important to know that X.420 dictates 1179 that Extended Body Parts shall: 1181 (1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify 1182 the contents, and 1184 (2) be defined by using the ASN.1 Macro: 1186 EXTENDED-BODY-PART-TYPE MACRO::=3D 1187 BEGIN 1188 TYPE NOTATION ::=3D Parameters Data 1189 VALUE NOTATION ::=3D value (VALUE OBJECT IDENTIFIER) 1191 Parameters ::=3D "PARAMETERS" type "IDENTIFIED" 1192 "BY" value(OBJECT IDENTIFIER) 1193 | empty; 1194 Data ::=3D "DATA" type 1195 END 1197 To meet these requirements, this document uses the OID 1199 mixer 1201 defined in [MIXER], as the root OID for X.400 Extended 1202 Body Parts defined for MIME interworking. 1204 Each Extended Body Part contains Data and optional 1205 Parameters, each being named by an OID. To this end, two 1206 OID subtrees are defined under mixer-bodies, one for Data, 1207 and the other for Parameters: 1209 mixer-bp-data OBJECT IDENTIFIER ::=3D 1210 { mixer 1 } 1212 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 1213 { mixer 2 } 1215 All definitions of extended X.400 body parts submitted to 1216 the IANA for registration with a mapping must use the 1217 Extended Body Part Type macro for the definition. See 1218 [IMAGES] for an example. 1220 draft X.400/MIME body mapping May 96 1222 Lastly, the IANA will use the mixer-bp-data and mixer-bp- 1223 parameter OIDs as root OIDs for any new MIME content- 1224 type/subtypes that aren't otherwise registered in the 1225 Equivalence Table. 1227 NOTE: The ASN.1 for an ExternallyDefinedBodyPart is 1229 ExternallyDefinedBodyPart ::=3D SEQUENCE { 1230 parameters [0] ExternallyDefinedParameters OPTIONAL, 1231 data ExternallyDefinedData } 1233 ExternallyDefinedParameters ::=3D EXTERNAL 1235 ExternallyDefinedData ::=3D EXTERNAL 1237 The ASN.1 for EXTERNAL is (from X.208): 1239 EXTERNAL ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE 1240 {direct-reference OBJECT IDENTIFIER OPTIONAL, 1241 indirect-reference INTEGER OPTIONAL, 1242 data-value-descriptor ObjectDescriptor OPTIONAL, 1243 encoding CHOICE 1244 {single-ASN1-type [0] ANY, 1245 octet-aligned [1] IMPLICIT OCTET STRING, 1246 arbitrary [2] IMPLICIT BIT STRING}} 1248 ObjectDescriptor ::=3D [UNIVERSAL 7] IMPLICIT GraphicString 1250 There are a bit too many choices here; the common X.400 1251 usage for BP15 encoding is to: 1253 (1) Always use direct-reference 1255 (2) Omit indirect-reference and data-value-descriptor 1257 (3) Use the single-ASN1-type encoding only 1259 Unfortunately, some implementations have chosen to use the 1260 octet-aligned choice when constructing values where the 1261 ASN.1 type is OCTET STRING, which of course caused 1262 interoperability problems. 1264 An attempt to specify that X.420 only allowed the single- 1265 ASN1-type choice in the 1996 versions is still (Sept 1995) 1266 being debated in ISO; the end result seems to be that all 1268 draft X.400/MIME body mapping May 96 1270 agree in principle that single-ASN1-type should be used, 1271 but that one has to allow the generation of the octet- 1272 aligned choice as being conformant. 1274 6. Defined Equivalences 1276 6.1. IA5Text - text/plain 1278 X.400 Body Part: IA5Text 1279 MIME Content-type: text/plain; charset=3DUS-ASCII 1280 Conversion Type: No conversion 1281 Comments: 1283 When mapping from X.400 to MIME, the "repertoire" 1284 parameter is ignored. 1286 When mapping from MIME to X.400, the "repertoire" 1287 parameter is set to IA5 (5). 1289 NOTE: The MIME Content-type headers are omitted, when 1290 mapping from X.400 to MIME, if and only if the IA5Text 1291 body part is the only body part in the IPMS.Body sequence. 1293 NOTE: IA5Text specifies the "currency" symbol in position 1294 2/4. This is converted without comment to the "dollar" 1295 symbol, since the author of this document has seen many 1296 documents in which the position was intended to indicate 1297 "dollar" while he has not yet seen one in which the 1298 "currency" symbol is intended. 1300 (For reference: The T.50 (1988) recommendation, which 1301 defines IA5, talks about ISO registered set number 2, 1302 while ASCII, using the "dollar" symbol, is ISO registered 1303 set number 6. There are no other differences.) 1305 NOTE: It is not uncommon, though it is a violation of the 1306 standard, to use 8-bit character sets inside an IA5 body 1307 part. Gateways that can expect to encounter this situation 1308 should consider implementing something like the guidance 1309 given in RFC 1428, "Transition of Internet Mail from just- 1310 send-8 to 8-bit SMTP/MIME", and generate appropriate 1311 charset parameters for the MIME messages they generate. 1313 draft X.400/MIME body mapping May 96 1315 This behavior is not required for MIXER conformance, since 1316 it is only needed when the base standards are violated. 1318 6.2. GeneralText - text/plain (ISO-8859) 1320 X.400 Body Part: GeneralText; CharacterSets in 1321 6,100,101,109,110,126,127,138,144,148 1322 MIME Content-Type: text/plain; charset=3DISO-8859-(1-9) 1323 Conversion Type: Text conversion without character change 1324 When mapping from X.400 to MIME, the character-set is 1325 chosen from the table below according to the value of 1326 Parameters.CharacterSets. If no match is found, and the 1327 gateway does not support a conversion, the character set 1328 shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the 1329 numbers of the Parameters.CharacterSets, sorted in numeric 1330 order. 1332 When mapping from MIME to X.400, GeneralText is an 1333 Extended Body Part, hence it requires an OID. The OID for 1334 the GeneralText body is defined in [MOTIS], part 8, annex 1335 D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1 1336 11 11}. 1338 The Parameters.CharacterSets is set from table below 1339 according to the value of "charset" 1341 The following table lists the MIME character sets and the 1342 corresponding ISO registry numbers. If no correspondence 1343 is found, this conversion fails, and the generic body part 1344 approach is used. 1346 MIME charset ISO IR numbers Comment 1347 ----------------------------------------------- 1348 ISO-8859-1 6, 100 West European "8-bit ASCII" 1349 ISO-8859-2 6, 101 East European 1350 ISO-8859-3 6, 109 1351 ISO-8859-4 6, 110 1352 ISO-8859-5 6, 144 Cyrillic 1353 ISO-8859-6 6, 127 Arabic 1354 ISO-8859-7 6, 126 Greek 1355 ISO-8859-8 6, 138 Hebrew 1356 ISO-8859-9 6, 148 Other Latin-using languages 1357 ISO-2022-JP 6, 14, 42, 87 Japanese 1359 draft X.400/MIME body mapping May 96 1361 When converting from MIME to X.400, generate the correct 1362 OIDs for use in the message envelope's Encoded Information 1363 Types by looking up the ISO IR number in the above table, 1364 and then appending it to the id-cs-eit-authority {1 0 1365 10021 7 1 0} OID. 1367 The escape sequences to designate and invoke the relevant 1368 character sets in their proper positions must be added to 1369 the front of the GeneralText character string. 1371 For ISO 8859-1, the relevant escape sequence will be: 1373 ESC 28 42 1374 ASCII in G0 1376 ESC 2D 41 1377 ISO-IR-100 in G1 1379 ESC 21 41 1380 High control character set in C1 1382 ESC 7E 1383 Locking shift 1 Right 1385 DISCUSSION: 1387 The conversion of text is a problematic one, and one in 1388 which it is likely that gateways should be given wide 1389 latitude to make decisions based upon their knowledge of 1390 the user's preferences. The text given below is thought to 1391 give the best approximation to a gateway conforming to 1392 current and anticipated usage in the MIME and X.400 1393 worlds, and is the way recommended when no knowledge of 1394 the recipient's capabilities exists. 1396 The changes, such as normalizing escape sequences, should 1397 not be done when "conversion-prohibited" is set. If 1398 "conversion-with-loss-prohibited" is set, translation to a 1399 character set that is not able to encode all characters 1400 cannot be done, and the message should be non-delivered 1401 with an appropriate non-delivery reason. 1403 The common use of character sets in MIME is somewhat 1404 different from the rules given by X.400; in particular, it 1406 draft X.400/MIME body mapping May 96 1408 is common in MIME to assume that the character sets follow 1409 strict rules. For the ISO-8859-x character sets, it is 1410 assumed that they are designated and invoked at the 1411 beginning of the text, and that no designation or 1412 invocation sequences occur within the body of the text. 1413 The rules for ISO-2022-JP are given in RFC 1468, and are 1414 even more particular, using a pure 7-bit encoding in which 1415 each line of text starts in ASCII. 1417 Therefore, the text must be "normalized" by going through 1418 the whole message, using a state machine or similar device 1419 to remove all escape and shift sequences. 1421 Appendix A gives pseudocode for such a conversion. 1423 NOTE: In 1988, the GeneralText body part was defined in 1424 ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT 1425 recommendation; this was added later. Also, the 1426 parameters have been heavily modified; they should be a 1427 SET OF INTEGER in the currently valid text. Use the 1428 latest version of the standard that you can get hold of. 1430 6.3. BilaterallyDefined - application/octet-stream 1432 X.400 Body Part: BilaterallyDefined 1433 MIME Content-Type: Application/Octet-Stream (no parameters) 1434 Conversion Type: No conversion 1436 When mapping from MIME to X.400, if there are parameters 1437 present in the Content-Type: header field, they are 1438 removed. 1440 DISCUSSION: 1442 The parameters "name" "type" and "conversions" are 1443 advisory; name and conversions are depreciated in RFC 1444 1521. 1446 The parameter "padding" changes the interpretation of the 1447 last byte of the data, but it is deemed better by the WG 1448 to delete this information than to non-deliver the body 1449 part. The "padding" parameter is rarely used with MIME. 1451 draft X.400/MIME body mapping May 96 1453 Use of BilaterallyDefined Body Parts is specifically 1454 deprecated in both 1988 and 1992 X.400. It is retained 1455 solely for backward compatibility with 1984 systems, and 1456 because it is in common use. 1458 6.4. FTBP EMA Unknown Attachment - 1459 application/octet-stream 1460 X.400 Body Part: FTBP EMA Unknown Attachment 1461 MIME Content-Type: Application/Octet-Stream 1462 Conversion Type: No conversion 1464 The OID for the Unknown Attachment is { joint-iso-ccitt(2) 1465 country(16) us(840) organization(1) ema(113694) objects(2) 1466 messaging(2) attachments(1) unknown(1) }, or 1467 2.16.840.1.113694.2.2.1.1 for short. 1469 NOTE: Previous EMA drafts gave it as { iso(1) countries(2) 1470 usa(840) organization (1) ema (113694) objects(2) 1471 messaging(2) attachments(1) unknown (1)}, or 1472 1.2.840.1.113694.2.2.1.1 for short. 1474 The parameters for this type must be mapped according to 1475 chapter 2.3, with the following extensions for the 1476 parameters of the application/octet-stream: 1478 If there is no Content-Disposition parameter with a 1479 filename, and there is a name parameter, the 1480 FTBP.FileTransferParameters.File-attributes.pathname 1481 is generated from this parameter. Note that RFC 1521 1482 recommends not using the "name" parameter. 1484 The "type", "conversions" and "padding" attributes are 1485 ignored; "type" is for human consumption; "conversions" 1486 are discouraged in RFC 1521. 1488 The body mapping is just copying the bytes in both 1489 directions. 1491 6.5. MessageBodyPart - message/RFC822 1493 X.400 body part: MessageBodyPart 1494 MIME Content-Type: message/RFC822 1496 draft X.400/MIME body mapping May 96 1498 Conversion Type: Special 1500 NOTE: If the headers of the X.400 MessageBodyPart contains the 1501 "multipart-message" heading extension with the isAMessage bit set 1502 (either explicitly or implicitly), the mapping should be to 1503 multipart/* according to section 6.6, below. 1505 To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 1506 mapping is recursively applied, to generate an RFC 822 Message. 1507 If present, the IPMS.MessageBodyPart.parameters.delivery-envelope 1508 is used for the MTS Abstract Service Mappings. If present, the 1509 IPMS.MessageBodyPart.parameters.delivery-time is mapped to the 1510 extended RFC 822 field "Delivery-Date:". 1512 When a message/RFC822 is contained within a MIME message, it is 1513 mapped to an IPMS.MessageBodyPart according to MIXER. 1514 specification. Any mappings that would have been made to the MTS 1515 Abstract Service are placed in 1516 IPMS.MessageBodyPart.parameters.delivery-envelope. 1518 6.6. MessageBodyPart - multipart/* 1520 X.400 body part: MessageBodyPart 1521 MIME Content-Type: multipart/* 1522 Conversion Type: Special 1524 NOTE: If the headers of the X.400 MessageBodyPart do not contain the 1525 "multipart-message" heading extension with the "isAMessage" flag FALS= 1526 E, 1527 the mapping should be to message/RFC822. 1529 A MIME multipart is a set of content-types and not a message with 1530 a set of content types. When the multipart is at the outermost 1531 MIME header, elements of the multipart are mapped directly onto 1532 IPMS.Bodypart. 1533 When the MIME multipart is not at the outermost level, it is mapped t= 1534 o 1535 an IPMS.MessageBodyPart containing an IPMS.Bodypart for each element 1536 of the multipart. 1538 When a nested IPMS.Message is generated from a multipart, an 1539 IPMS.heading shall always be generated. The only mandatory field 1540 is the IPMS.Heading.this-IPM message id, which shall be generated 1541 by the gateway. An IPMS.Heading.subject field shall also be 1542 generated, in order to provide useful information to non-MIME 1543 capable X.400(88) UAs and to all X.400(84) UAs. The subject 1545 draft X.400/MIME body mapping May 96 1547 field is set as follows according to the multipart subtype: 1549 mixed: 1550 "Multipart Message" 1552 alternative: 1553 "Alternative Body Parts containing the same 1554 information" 1556 digest: 1557 "Message Digest" 1559 parallel: 1560 "Body Parts interpreted in parallel" 1562 other: 1563 "Multipart Message ()" 1565 For other types of multipart, the multipart subtype shall 1566 be included in the subject line. 1568 For each multipart, the following IPMS.HeadingExtension 1569 shall be generated, with the value set according to the 1570 subtype. 1571 If the multipart is the outermost multipart, and the 1572 subtype is "mixed", it may be omitted. 1574 multipart-message HEADING-EXTENSION 1575 VALUE MultipartType 1576 ::=3D id-hex-multipart-message 1578 MultipartType ::=3D SEQUENCE { 1579 subtype IA5String, 1580 isAMessage BOOLEAN DEFAULT TRUE } 1582 The MultipartType contains the subtype, for example 1583 "digest". If this heading is present when mapping from 1584 X.400 to MIME, the appropriate multipart may be generated. 1586 The isAMessage flag is needed because of the case where a 1587 message contains a ForwardedIPMessage, which itself was 1588 generated from a MIME message that was a Multipart; it is 1589 set whenever the multipart is the outermost level of 1590 nesting inside a Message/RFC822. 1592 draft X.400/MIME body mapping May 96 1594 NOTE: 1595 When downgrading to X.400/84, the content-type SHOULD 1596 be regenerated from this heading-extension and put 1597 into the RFC-822-HEADERS extra body part. 1599 6.7. Teletex - Text/Plain (Teletex) 1601 X.400 Body Part: Teletex 1602 MIME Content-Type: text/plain; charset=3DTeletex 1603 Conversion Type: Text conversion 1604 From X.400 to RFC-822, the conversion shall take the bytes 1605 of all the pages in the "data" part of the 1606 TeletexBodyPart, add a FF character (0x0C, control-L) to 1607 each part that does not already end in one, and 1608 concatenate them together to form the body of the 1609 Text/Plain. 1611 The character set shall be "Teletex", which is especially 1612 registered for this purpose. Its definition is shown in an 1613 appendix. 1615 The parameters are discarded. 1617 From RFC-822 to X.400, the conversion shall split the 1618 content at each occurrence of the FF character (0x0C), 1619 delete the character and construct the Teletex body part 1620 as a SEQUENCE OF TeletexString, as described in X.420(88), 1621 section 7.3.5 1623 The TeletexParameters may, but need not, contain the 1624 number-of-pages component. 1626 NOTE: It is recommended, but not mandated, that the data 1627 be converted into a more widespread character set like 1628 ISO-8859-1 or ISO-2022-JP (if applicable) if possible. 1629 This will result in the reverse translation giving a 1630 GeneralText body part, which will have to be dealt with 1631 appropriately at the X.400/88 to X.400/84 downgrading 1632 boundary, if possible, but will give a much greater chance 1633 that the MIME recipient can actually read the message. 1635 DISCUSSION: 1637 draft X.400/MIME body mapping May 96 1639 The Teletex body part is frequently used in X.400(84) to 1640 send around text with slightly extended character sets 1641 beyond ASCII. 1643 Its body consists of a series of "pages", separated by 1644 ASN.1 representation. It is important to many people to 1645 have this mapped into something that is readable to most 1646 end-users; therefore, it is recommended to map this onto 1647 Text/Plain; however, since this is not plain text, the 1648 conversion must be specified. 1650 draft X.400/MIME body mapping May 96 1652 7. Body parts where encapsulation is recommended 1654 Some body parts are MIME constructs, and their 1655 functionality will be severely damaged if they are coerced 1656 into an X.400 framework. 1658 Special care needs to be taken with these; they are 1659 described below. 1661 7.1. message/external-body 1663 The gateway MUST support the encapsulation of this body 1664 part using the HARPOON encapsulation (IA5). 1666 It MAY support some kind of retrieval of the referred 1667 object. 1669 DISCUSSION: 1671 The message/external-body part points to an object that 1672 can be retrieved using Internet protocols. 1674 There are three cases to consider for the recipient's 1675 capabilities: 1677 (1) The user has no Internet access. In this case, the 1678 user might be grateful if the gateway fetches the 1679 body part and inserts it into the message. If the 1680 body part is large or dynamic, it might not be 1681 appropriate. 1683 (2) The user has Internet access, but no UA support for 1684 fetching external-body objects. 1686 (3) The user has Internet access and UA support for 1687 fetching external-body objects, based on an 1688 understanding of this document. 1690 Some access-types, like anonymous FTP, are easy to 1691 resolve. Others, like the Mailserver access-type, are 1692 almost impossible to resolve at a gateway. 1694 draft X.400/MIME body mapping May 96 1696 To support the second case above, the tunneling method 1697 chosen is the HARPOON encapsulation described in section 1698 3.1.3, using an IA5 body part, inserting the string "MIME- 1699 Version: 1.0 (generated by gateway)" at the beginning of 1700 the body part. (The part in parentheses can be changed at 1701 will). 1703 This will: 1705 (1) Maximize the chance that the user will see the 1706 message 1708 (2) Give the user hints that will enable him to fetch 1709 the message using other Internet tools 1711 (3) Identify the message as a MIME object in a reliable 1712 fashion, allowing UAs to support the fetching of 1713 the object if the UA implementor desires. 1715 7.2. message/partial 1717 This represents part of a larger message, where it is only 1718 possible to parse the complete message after getting all 1719 the pieces. 1721 The gateway MUST support the encapsulation of this body 1722 part. 1724 It MAY implement transparent reassembly of the message, 1725 but in this case, it MUST support a configurable timeout 1726 for the reassembly, defaulting back to encapsulation. 1728 DISCUSSION: 1730 The gateway's choices are: 1732 (1) Wait until all the pieces arrive at the gateway, 1733 reassemble the message, and use normal processing 1735 (2) Encapsulate the message, using any encapsulation 1736 method (BP15, FTAM or HARPOON). 1738 draft X.400/MIME body mapping May 96 1740 In some cases, not all pieces will arrive at the gateway; 1741 some may have been transferred through other gateways due 1742 to route changes or machine outages; some may have been 1743 lost in transit. 1745 7.3. multipart/signed 1747 A gateway MUST implement encapsulation of multipart/signed 1748 using HARPOON. 1750 The gateway MAY be configured to do other processing, as 1751 outlined in the discussion below. This is outside the 1752 scope of the standard. 1754 DISCUSSION: 1756 Gatewaying security is a problem. The gateway can 1757 basically take three approaches: 1759 - Strip the multipart/signed, leaving the bare body 1760 part unsecured, possibly with a comment that the 1761 signature was stripped 1763 - Attempt to check the signature and re-signing the 1764 message using X.400 security functions, then 1765 stripping as above 1767 - Encapsulate the message. This is the only approach 1768 that allows end to end security, but requires MIME 1769 functionality at the recipient. 1771 - Replace the message content with multiple body parts, 1772 containing first an unsecured body part and then the 1773 encapsulated multipart/signed. 1775 All these are valid options for a MIXER gateway. 1777 Note that the encapsulation must use HARPOON, as the 1778 signature is computed on the ENCODED body part, not on the 1779 canonical representation, and HARPOON is the only 1780 encapsulation that preserves the content transfer encoding 1781 of the message. 1783 draft X.400/MIME body mapping May 96 1785 Note also that all methods except for encapsulation break 1786 end-to-end security; the recipient can place no more trust 1787 in the integrity of the message than he can place in the 1788 security of the gateway. 1790 7.4. multipart/encrypted 1792 A gateway MUST implement encapsulation of 1793 multipart/encrypted using HARPOON. 1795 If the implementor chooses to allow other processing at 1796 the gateway, as outlined below, he/she is advised that 1797 there are grave security concerns with such a solution, 1798 since it violates the general rule of keeping decryption 1799 keys as close to the user as possible. 1801 DISCUSSION: 1803 There are two basic cases for a gateway: 1805 - The gateway is trusted with the user's keys. In this 1806 case, the gateway can decrypt the message, possibly 1807 add a note that it has done so, and gateway the 1808 unencrypted form, possibly applying X.400 security 1809 functions, and possibly attaching a copy of the 1810 original, encrypted material for reference. 1811 This does nothing to protect the transfer from 1812 gateway to recipient, unless suitable X.400-native 1813 security is applied. It also means that the gateway 1814 must be part of the user's trusted environment. 1816 - The gateway is not trusted with the recipient's keys. 1817 In this case, encapsulation is the only approach that 1818 preserves any information at all. 1820 The valid options for a MIXER gateway are therefore: 1822 - Decrypt the body part 1824 - Encapsulate the body part 1826 draft X.400/MIME body mapping May 96 1828 - Drop the body part 1830 The MIXER WG has shown strong preference for the 1831 encapsulation alternative, and urges anyone who thinks of 1832 buying or implementing gateway decryption to carefully 1833 evaluate this choice in light of the company's general 1834 security policy. 1836 8. Conformance requirements 1838 In order to be called MIXER conformant, a gateway must 1839 implement: 1841 - Encapsulation of MIME content in the FTBP body part 1843 - Encapsulation of X.400 body parts in the x400-bp body 1844 part 1846 - Encapsulation of FTBP body parts in the 1847 application/x-oid.n.n.n body part 1849 - Encapsulation of security multiparts using HARPOON 1851 - Text/plain <-> IA5Text 1853 - Text/plain; charset=3Diso-8859-* <-> GeneralText 1855 - Multipart/* <-> ForwardedIPMessage 1857 - message/RFC822 <-> ForwardedIPMessage 1859 - application/octet-stream <-> FTBP unknown 1861 - application/octet-stream <-> BilaterallyDefined 1863 - A configuration choice of which application/octet- 1864 stream translation to use 1866 All other parts of this specification MAY be implemented 1867 by the gateway. If they are implemented at all, they MUST 1869 draft X.400/MIME body mapping May 96 1871 be implemented conformant to this specification. 1873 In this context, a feature is "implemented" in a product 1874 if it is possible to configure the product in such a way 1875 that this feature is used. This specification does not 1876 restrict the product to only be configured in such a 1877 fashion. 1879 References 1881 [RFC-822] 1882 D.H. Crocker, Standard for the Format of ARPA 1883 Internet Text Messages. Request for Comments 822, 1884 (August, 1982). 1886 [MIME] 1887 N. Borenstein, N. Freed, MIME: Mechanisms for 1888 Specifying and Describing the Format of Internet 1889 Message Bodies. Request for Comments 1341, (June, 1890 1992). 1892 [MIXER] 1893 S.E. Kille, Mapping between X.400(1988) / ISO 10021 1894 and RFC-822. (in preparation) 1896 [T.4] 1897 CCITT Recommendation T.4, Standardization of Group 3 1898 Facsimile Apparatus for Document Transmission (1988) 1900 [T.30] 1901 CCITT Recommendation T.30, Procedures For Document 1902 Facsimile Transmission in the General Switched 1903 Telephone Network (1988) 1905 [T.411] 1906 CCITT Recommendation T.411 (1988), Open Document 1907 Architecture (ODA) and Interchange Format, 1908 Introduction and General Principles 1910 [MOTIS] 1911 ISO/IEC International Standard 10021, Information 1912 technology - Text Communication - Message-Oriented 1913 Text Interchange Systems (MOTIS) (Parts 1 to 8) 1915 draft X.400/MIME body mapping May 96 1917 [X.400] 1918 CCITT, Data Communication Networks - Message Handling 1919 Systems - Recommendations X.400 - X.420 (1988 1920 version) 1922 [X.420] 1923 CCITT Recommendation X.420 (1988), Interpersonal 1924 Messaging System 1926 [RFC-X400USE] 1927 Harald Tveit Alvestrand, X.400 use of extended 1928 Character Sets, Internet Draft, June 1992 1930 [MAWG] 1931 Electronic Messaging Association Message Attachment 1932 Working Group (MAWG): File Transfer Body Part 1933 Feasibility Project Guide - version 1.5 - September 1934 1995 1936 [CDISP] 1937 Dorner & Troost, The Content-Disposition header - RFC 1938 1806 1940 [POSTSCRIPT] 1941 Harald Tveit Alvestrand, Carrying PostScript in X.400 1942 and MIME, Work In Progress (draft-ietf-mixer- 1943 postscript-00.txt) 1945 [IMAGES] 1946 Harald Tveit Alvestrand, X.400 image body parts, Work 1947 In Progress (draft-ietf-mixer-images-00.txt) 1949 [ODA] 1950 Harald Tveit Alvestrand, A MIME body part for ODA, 1951 Work in Progress (draft-ietf-mixer-oda-00.txt) 1953 draft X.400/MIME body mapping May 96 1955 9. Authors' address 1957 Harald Tveit Alvestrand 1958 UNINETT 1959 P.O.box 6883 Elgeseter 1960 N-7002 Trondheim 1961 NORWAY 1963 Harald.T.Alvestrand@uninett.no 1965 APPENDIXES 1967 Appendix A: Escape code normalization 1969 The algorithm given here in pseudocode will reduce a 1970 GeneralString ISO-2022 unlimited use of shifts sequence to 1971 a pure 8-bit sequence that does not use shift sequences, 1972 if possible. 1974 Some error conditions, like EOF, are not tested for. It 1975 crashes if asked to do something it cannot. Control 1976 character set switching is missing. 1978 A similar routine, albeit more complex, can be written for 1979 normalizing to the ISO-2022-JP character set. 1981 BEGIN: (from X.209) 1982 g0 =3D 6 (should be 2, but ignore the difference) 1983 g1 =3D NULL 1984 g2 =3D NULL 1985 g3 =3D NULL 1986 c0 =3D 1 (ASCII control) 1987 c1 =3D NULL 1988 leftset =3D &g0 (current input set, low) 1989 rightset =3D &g1 (current input set, high) 1990 lowset =3D 6 (output set, low) 1991 highset =3D NULL (output set, high) 1992 charset =3D US-ASCII 1994 (Init for the set tables) 1995 chartoid[{2D,2E,2F}, 41] =3D 100 1997 draft X.400/MIME body mapping May 96 1999 ..... 2000 idtoname[100] =3D "ISO-8859-1" 2001 ..... 2003 WHILE (more data) 2004 CASE head of input 2005 {These are the locking shift sequences} 2006 INCASE "00/14": (LS0, SO) 2007 leftset =3D &g0; 2008 INCASE "00/15": (LS1, SI) 2009 leftset =3D &g 2010 INCASE "ESC 07/14": (LS1R) 2011 rightset =3D &g1; 2012 INCASE "ESC 07/13": (LS2R) 2013 rightset =3D &g2; 2014 INCASE "ESC 07/12": (LS3R) 2015 rightset =3D &g3; 2016 {There is missing code for handling the single shift function} 2017 {These are the changes of graphic character sets} 2018 {Note that G0 can contain only 94-character charsets} 2019 INCASE "ESC 28" 2020 g0 =3D chartoid[lastchar, next character] 2021 sethiset(g0) 2022 INCASE "ESC 2D", "ESC 29" 2023 g1 =3D chartoid[lastchar, next character] 2024 sethiset(g1) 2025 INCASE "ESC 2E", "ESC 2A" 2026 g2 =3D chartoid[lastchar, next character] 2027 sethiset(g2) 2028 INCASE "ESC 2F", "ESC 2B" 2029 g3 =3D chartoid[lastchar, next character] 2030 sethiset(g3) 2031 {control characters. There is missing code for changing these} 2032 INCASE 00/00-01/15 {normal control} 2033 write(char) 2034 INCASE 08/00-09/15 {upper control} 2035 write(char) 2036 {Normal characters} 2037 INCASE 02/00-07/15 (Left) 2038 IF (*leftset =3D=3D lowset) 2039 write(char) 2040 ELSIF (*leftset =3D=3D highset) 2041 write(char+80) 2042 ELSE 2043 ERROR "Shift error" 2045 draft X.400/MIME body mapping May 96 2047 ENDIF 2048 INCASE 10/00-15/15 2049 IF (*rightset =3D=3D highset) 2050 write(char) 2051 ELSIF (*rightset =3D=3D lowset) 2052 write(char-80) 2053 ELSE 2054 ERROR "Shift error" 2055 ENDIF 2056 ENDCASE 2057 ENDWHILE 2059 SUBROUTINE sethighset(g1) 2061 IF (highset =3D=3D NULL) 2062 charset =3D idtoname[g1] 2063 highset =3D g1 2064 ELSIF (highset =3D=3D g1) 2065 (it's OK) 2066 ELSE 2067 ERROR "Too many charsets encountered" 2068 ENDIF 2070 ENDROUTINE 2072 Appendix B: OID Assignments 2073 MIXER-MAPPINGS DEFINITIONS ::=3D BEGIN 2074 EXPORTS -- everything --; 2076 IMPORTS 2077 experimental 2078 FROM RFC1155-SMI; 2079 mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) } 2080 FROM MIXER --Companion RFC--; 2082 mixer-bp-data OBJECT IDENTIFIER ::=3D 2083 { mixer 1 }; 2085 mixer-bp-parameter OBJECT IDENTIFIER ::=3D 2086 { mixer 2 }; 2088 -- mixer-core is defined as { mixer core(3) } in [MIXER] 2089 mixer-bp-heading OBJECT IDENTIFIER ::=3D 2091 draft X.400/MIME body mapping May 96 2093 { mixer 4 } 2095 id-mime-bp-data OBJECT IDENTIFIER ::=3D 2096 { mixer-bp-data 1}; 2098 id-mime-bp-parameters OBJECT IDENTIFIER ::=3D 2099 { mixer-bp-parameter 1}; 2101 -- the following assignments were done in RFC 1494, using 2102 -- slightly different names, but the same numbers. 2103 -- their defining text is now is now in other documents 2104 id-mime-postscript-body OBJECT IDENTIFIER ::=3D 2105 { mixer-bp-data 2} 2107 id-mime-jpeg-body OBJECT IDENTIFIER ::=3D 2108 { mixer-bp-data 3} 2110 id-mime-gif-body OBJECT IDENTIFIER ::=3D 2111 { mixer-bp-data 4}; 2113 -- This is a new definition, and defines an FTAM application referenc= 2114 e, 2115 -- not a BP15 data OID. 2116 id-mime-ftbp-data OBJECT IDENTIFIER ::=3D 2117 { mixer-bp-data 5 } 2119 draft X.400/MIME body mapping May 96 2121 Appendix C: Registration information for the Teletex 2122 character set 2124 The Teletex character set is a character set in which the 2125 ISO 2022 character set switching mechanism may be used to 2126 switch between the following registered ISO character 2127 sets: 2129 ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set 2130 ISO-IR-102 - a fairly standard US-ASCII variant 2131 ISO-IR-103 - Latin characters using non-spacing accents 2132 ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more= 2133 =2E 2134 ISO-IR-107 - Control characters for C1 use 2136 Its intended use of this character set is to represent 2137 data that comes from ISO protocols that use the ASN.1 2138 construct "TeletexString" or "T61string" without 2139 conversion. 2141 The set of allowed character sets can be found in CCITT 2142 recommendation X.208(1988), chapter 31.2 and Table 2143 6/X.208. 2145 The rules for encoding the data type can be found in CCITT 2146 recommendation X.209(1988), chapter 23. It states that at 2147 the beginning of the string, G0 is always ISO-IR-102, C0 2148 is ISO-IR-106, and C1 is ISO-IR-107. 2150 The specification seems somehow to have missed the 2151 implicit assumption that ISO-IR-103 is designated and 2152 invoked as G1 and shifted into the upper half of the 2153 character set which seems to be assumed at least by the 2154 X.400 and X.500 software that uses TeletexStrings; 2155 implementors should act as if the sequence ESC 2/9 7/6 2156 LS1R is always present at the beginning of the data. 2158 The rules for interpreting T.61 data are found (I believe) 2159 in CCITT recommendations T.51, T.52 and T.53 (data from 2160 the ITU WWW server): 2162 T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93] 2163 Latin based coded character sets for telematic services 2164 T.52 (1993) [New] [88 pp.] [Publ.: Apr.94] 2165 Non-Latin coded character sets for telematic services 2166 T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95] 2168 draft X.400/MIME body mapping May 96 2170 Character coded control functions for telematic services 2172 (The author has not yet obtained a copy of these, even 2173 though they only cost SFR 70 from the ITU...) 2175 The Teletex character set is closely related to (but not 2176 identical with) that specified in ISO 6937. 2178 No further restrictions are imposed by this registration; 2179 in particular, character set switching can occur anywhere, 2180 and there is no guarantee that the character sets will be 2181 switched "back" at the end. 2183 draft X.400/MIME body mapping May 96 2185 Appendix D: IANA Registration form for new mappings 2187 To: IANA@isi.edu 2188 Subject: Registration of new X.400/MIME content type mapping 2190 MIME type name: 2192 (this must have been registered previously with IANA) 2194 X.400 body part: 2196 X.400 Object Identifier for Data: 2198 (If left empty, an OID will be assigned by IANA under 2199 mixer-bp-data) 2201 X.400 Object Identifier for Parameters: 2203 (If left empty, an OID will be assigned by IANA under 2204 mixer-bp-parameter. If it is not used, fill in the 2205 words NOT USED.) 2207 X.400 ASN.1 Syntax: 2209 (must be an EXTENDED-BODY-PART-TYPE macro, or refer=AD 2210 ence to a Basic body part type) 2212 Conversion algorithm: 2214 (must be defined completely enough for independent im=AD 2215 plementation. It may be defined by reference to RFCs). 2217 Person & email address to contact for further informa=AD 2218 tion: 2220 INFORMATION TO THE SUBMITTER: 2222 The accepted registrations will be listed in the "As=AD 2223 signed Numbers" series of RFCs. The information in 2224 the registration form is freely distributable. 2226 draft X.400/MIME body mapping May 96 2228 Table of Contents 2230 Status of this Memo ................................ 1 2231 1 Introduction ...................................... 2 2232 1.1 Glossary ........................................ 2 2233 2 Basic rules for body part conversion .............. 3 2234 2.1 Generating the IPM Body from MIME ............... 5 2235 2.2 Generating the MIME Body from the IPMS.Body ..... 5 2236 2.3 Mapping the EMA FTBP parameters ................. 6 2237 2.3.1 Mapping GraphicStrings ........................ 7 2238 2.3.2 Mapping specific parameters ................... 7 2239 2.3.3 Summary of FTBP elements generated ............ 11 2240 2.4 Information that is lost when mapping ........... 12 2241 3 Encapsulation of body parts ....................... 12 2242 3.1 Encapsulation of MIME in X.400 .................. 13 2243 3.1.1 FTBP encapsulating body part .................. 13 2244 3.1.2 BP15 encapsulating body part .................. 14 2245 3.1.3 Encapsulation using IA5 (HARPOON) ............. 16 2246 3.1.4 Content passing using BP14 .................... 17 2247 3.2 Encapsulating X.400 Body Parts in MIME .......... 18 2248 3.3 Encapsulating FTBP body parts in MIME ........... 19 2249 4 User control over the gateway choice .............. 20 2250 4.1 Conversion from MIME to X.400 ................... 20 2251 4.2 Conversion from X.400 to MIME ................... 22 2252 5 The equivalence registry .......................... 23 2253 5.1 What information one must give about a mapping 2254 ................................................ 23 2255 5.2 Equivalence summary for known X.400 and MIME 2256 Types .......................................... 25 2257 5.3 MIME to X.400 Table ............................. 25 2258 5.4 X.400 to MIME Table ............................. 26 2259 5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...... 27 2260 6 Defined Equivalences .............................. 29 2261 6.1 IA5Text - text/plain ............................ 29 2262 6.2 GeneralText - text/plain (ISO-8859) ............. 30 2263 6.3 BilaterallyDefined - application/octet-stream 2264 ................................................ 32 2265 6.4 FTBP EMA Unknown Attachment - applica=AD 2266 tion/octet-stream .............................. 33 2267 6.5 MessageBodyPart - message/RFC822 ................ 33 2268 6.6 MessageBodyPart - multipart/* ................... 34 2269 6.7 Teletex - Text/Plain (Teletex) .................. 36 2270 7 Body parts where encapsulation is recommended ..... 38 2271 7.1 message/external-body ........................... 38 2273 draft X.400/MIME body mapping May 96 2275 7.2 message/partial ................................. 39 2276 7.3 multipart/signed ................................ 40 2277 7.4 multipart/encrypted ............................. 41 2278 8 Conformance requirements .......................... 42 2279 References ......................................... 43 2280 9 Authors' address .................................. 45 2281 APPENDIXES ......................................... 45 2282 Appendix A: Escape code normalization .............. 45 2283 Appendix B: OID Assignments ........................ 47 2284 Appendix C: Registration information for the 2285 Teletex character set .......................... 49 2286 Appendix D: IANA Registration form for new map=AD 2287 pings .......................................... 51 2288 Table of Contents .................................. 52