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