Network Working Group Ned Freed Internet Draft MIME and File Transfer Body Parts June 2, 1994 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. 1. Abstract This memo defines procedures and mechanisms suitable for translating X.400 File Transfer Body Parts to and from MIME. A variety of extensions to MIME are defined, including new MIME content-types and new MIME body part headers. Extensions fields are also defined on the X.400 to carry additional MIME information. 2. Introduction RFC822 [1] and MIME [2, 3] provide the necessary facilities to transfer binary attachments through Internet mail. X.400 has evolved through a number of mechanisms intended to provide a binary attachment capability. The most recent of these Internet Draft MIME File Transfer Body Parts Jun 1994 mechanisms, and by far the most general, is the File Transfer Body Part [4], or FTBP. (The FTBP acronym will be used throughout the remainder of this memo.) This body part type is a specific instance of an External Defined Body Part (Body Part 15) and is first described in the 1993 draft of the X.420 recommendation. The FTBP's new and essential contribution to the handling of binary attachments is the separation of format information from structural information. This separation makes it possible for agents to deal with formats they do not directly understand and support. This works because many useful agent actions only require the structural information necessary to remove any encapsulation and write the data to the right sort of file. No additional knowledge of the file format is necessary. It is worth nothing that this problem is for the most part unique to X.400 and its use of ASN.1 encapsulations. It does not apply to MIME because MIME only provides a single structuring convention for all body parts: they are always an unstructured sequence of octets. Given the fact that the FTBP solves serious interoperability problems in the X.400 world, use of it is expected to be quite widespread and may precede complete deployment of software that fully supports the X.400-1993 recommendations in their entirety. MIME usage is also widespread and increasing rapidly. A mapping of the FTBP is therefore necessary in order to facilitate interoperability between X.400 and MIME. The basis for mapping between X.400 and RFC822 is defined in [5]. This work was extended to cover MIME body parts by [6]. This memo is builds on this foundation and assumes the presence of all the definitions and conventions given in these other documents. 3. The File Transfer Body Part The following section provides the complete ASN.1 definition of the FTBP. This is included because: (1) The defining documents are still only in draft and hence not widely available, and (2) The defining ASN.1 in X.420-1993 is heavily dependent on primary definitions from ISO8571-2, ISO8571-4 Expires Dec 1994 [Page 2] Internet Draft MIME File Transfer Body Parts Jun 1994 (FTAM), and X.227 (ACSE). A single, comprehensive definition is therefore a very useful thing to have. EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE { direct-reference OBJECT IDENTIFIER OPTIONAL, indirect-reference INTEGER OPTIONAL, data-value-descriptor ObjectDescriptor OPTIONAL, encoding CHOICE { single-ASN1-type [0] ANY, octet-aligned [1] IMPLICIT OCTET STRING, arbitrary [2] IMPLICIT BIT STRING } } ExternallyDefinedBodyPart ::= SEQUENCE { Parameters [0] ExternallyDefinedParameters OPTIONAL, Data ExternallyDefinedData } -- The direct-reference component in the following EXTERNALs -- is always present while the indirect-reference and -- data-value-descriptor components are always absent. ExternallyDefinedParameters :== EXTERNAL ExternallyDefinedData ::= EXTERNAL EXTENDED-BODY-PART-TYPE MACRO ::= BEGIN TYPE NOTATION ::= Parameters Data VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Parameters ::= "PARAMETERS" type "IDENTIFIED" "BY" value(OBJECT IDENTIFIER) | empty; Data ::= "DATA" type END file-transfer-body-part EXTENDED-BODY-PART-TYPE PARAMETERS FileTransferParameters IDENTIFIED BY id-ep-file-transfer DATA FileTransferData ::= id-et-file-transfer Expires Dec 1994 [Page 3] Internet Draft MIME File Transfer Body Parts Jun 1994 FileTransferParameters ::= SEQUENCE { related-stored-file [0] RelatedStoredFile OPTIONAL, contents-type [1] ContentsTypeParameter DEFAULT document-type { document-type-name {iso standard 8571 document-type (5) unstructured-binary (3) } }, environment [2] EnvironmentParameter OPTIONAL, compression [3] CompressionParameter OPTIONAL, file-attributes [4] FileAttributes OPTIONAL, extensions [5] ExtensionsField DEFAULT {} } FileTransferData ::= SEQUENCE OF EXTERNAL RelatedStoredFile ::= SET OF SEQUENCE { file-identifier FileIdentifier, relationship Relationship DEFAULT unspecified } FileIdentifier ::= CHOICE { pathname-and-version [0] PathnameandVersion, cross-reference [1] CrossReference } PathnameandVersion ::= SEQUENCE { pathname [0] Pathname-Attribute, file-version [1] GraphicString OPTIONAL } Pathname-Attribute ::= CHOICE { incomplete-pathname [0] IMPLICIT Pathname, complete-pathname [23] IMPLICIT Pathname } Pathname ::= SEQUENCE OF GraphicString CrossReference ::= SEQUENCE { application-cross-reference [0] OCTET STRING, message-reference [1] MessageReference OPTIONAL, body-part-reference [2] INTEGER OPTIONAL } MessageReference ::= SET { user [0] ORName, user-relative-identifier [1] PrintableString } Relationship ::= CHOICE { explicit-relationship [0] ExplicitRelationship, descriptive-relationship [1] GraphicString } Expires Dec 1994 [Page 4] Internet Draft MIME File Transfer Body Parts Jun 1994 ExplicitRelationship ::= ENUMERATED { unspecified (0), new-file (1), replacement (2), extension (3) } ContentsTypeParameter ::= Contents-Type-Attribute Content-Type-Attribute ::= CHOICE { document-type [0] IMPLICIT SEQUENCE { document-type-name Document-Type-Name, parameter [0] ANY OPTIONAL }, constraint-set-and-abstract-syntax [1] IMPLICIT SEQUENCE { constraint-set-name Constraint-Set-Name, abstract-syntax-name Abstract-Syntax-Name } } Document-Type-Name ::= [APPLICATION 14] IMPLICIT OBJECT IDENTIFIER Constraint-Set-Name ::= [APPLICATION 11] IMPLICIT OBJECT IDENTIFIER Abstract-Syntax-Name ::= [APPLICATION 0] IMPLICIT OBJECT IDENTIFIER EnvironmentParameter ::= SEQUENCE { application-reference [0] GeneralIdentifier OPTIONAL, machine [1] GeneralIdentifier OPTIONAL, operating-system [2] OBJECT IDENTIFIER OPTIONAL, user-visible-string [3] SEQUENCE OF GraphicString OPTIONAL } GeneralIdentifier ::= CHOICE { registered-identifier [0] OBJECT IDENTIFIER, descriptive-identifier [1] SEQUENCE OF GraphicString } CompressionParameter ::= SEQUENCE { compression-algorithm-id [0] OBJECT IDENTIFIER, compression-algorithm-param [1] ANY DEFINED BY compression-algorithm-id } Expires Dec 1994 [Page 5] Internet Draft MIME File Transfer Body Parts Jun 1994 FileAttributes ::= SEQUENCE { pathname Pathname-Attribute OPTIONAL permitted-actions [1] Permitted-Actions-Attribute OPTIONAL, storage-account [3] Account-Attribute OPTIONAL, date-and-time-of-creation [4] Date-and-Time-Attribute OPTIONAL, date-and-time-of-last-modification [5] Date-and-Time-Attribute OPTIONAL, date-and-time-of-last-read-access [6] Date-and-Time-Attribute OPTIONAL, identity-of-creator [8] User-Identity-Attribute OPTIONAL, identity-of-last-modifier [9] User-Identity-Attribute OPTIONAL, identity-of-last-reader [10] User-Identity-Attribute OPTIONAL, object-size [13] Object-Size-Attribute OPTIONAL, future-object-size [14] Object-Size-Attribute OPTIONAL, access-control [15] Access-Control-Attribute OPTIONAL, legal-qualifications [16] Legal-Qualifications-Attribute OPTIONAL, private-use [17] Private-Use-Attribute OPTIONAL, attribute-extensions [22] Attribute-Extensions OPTIONAL } Permitted-Actions-Attribute ::= BIT STRING { read (0), insert (1), replace (2), extend (3), erase (4), read-attribute (5), change-attribute (6), delete-file (7), traversal (8), reverse-traversal (9), random-order (10) } Account-Attribute ::= CHOICE { no-value-attribute [0] IMPLICIT NULL, actual-values Account } Account ::= [APPLICATION 4] IMPLICIT GraphicString Expires Dec 1994 [Page 6] Internet Draft MIME File Transfer Body Parts Jun 1994 Date-and-Time-Attribute ::= CHOICE { no-value-available [0] IMPLICIT NULL, actual-values [1] IMPLICIT GeneralizedTime } User-Identity-Attribute ::= CHOICE { no-value-available [0] IMPLICIT NULL, actual-values User-Identity } User-Identity ::= [APPLICATION 22] IMPLICIT GraphicString Object-Size-Attribute ::= CHOICE { no-value-available [0] IMPLICIT NULL, actual-values [1] IMPLICIT INTEGER } Access-Control-Attribute ::= CHOICE { no-value-available [0] IMPLICIT NULL, actual-values [1] SET OF Access-Control-Element } Access-Control-Element ::= SEQUENCE { action-list [0] IMPLICIT Access-Request, concurrency-access [1] IMPLICIT Concurrency-Access OPTIONAL, identity [2] IMPLICIT User-Identity OPTIONAL, passwords [3] IMPLICIT Access-Passwords OPTIONAL, location [4] IMPLICIT Application-Entity-Title OPTIONAL } Access-Request ::= [APPLICATION 3] IMPLICIT BIT STRING { read (0), insert (1), replace (2), extend (3), erase (4), read-attribute (5), change-attribute (6), delete-file (7) } Concurrency-Access ::= SEQUENCE { read [0] IMPLICIT Concurrency-Key, insert [1] IMPLICIT Concurrency-Key, replace [2] IMPLICIT Concurrency-Key, extend [3] IMPLICIT Concurrency-Key, erase [4] IMPLICIT Concurrency-Key, read-attribute [5] IMPLICIT Concurrency-Key, change-attribute [6] IMPLICIT Concurrency-Key, Expires Dec 1994 [Page 7] Internet Draft MIME File Transfer Body Parts Jun 1994 delete-file [7] IMPLICIT Concurrency-Key } Concurrency-Key ::= BIT STRING { not-required (0), shared (1), exclusive (2), no-access (3) } Access-Passwords ::= [APPLICATION 3] IMPLICIT SEQUENCE { read-password [0] IMPLICIT Password, insert-password [1] IMPLICIT Password, replace-password [2] IMPLICIT Password, extend-password [3] IMPLICIT Password, erase-password [4] IMPLICIT Password, read-attribute-password [5] IMPLICIT Password, change-attribute-password [6] IMPLICIT Password, delete-password [7] IMPLICIT Password } Password ::= [APPLICATION 17] CHOICE { GraphicString, OCTET STRING} Application-Entity-Title ::= [APPLICATION 7] AE-title AE-Title ::= SEQUENCE { AP-title, AP-qualifier} AP-title ::= ANY AP-qualifier ::= ANY Legal-Qualifications-Attribute ::= CHOICE { no-value-available [0] IMPLICIT NULL, actual-values [1] IMPLICIT GraphicString } Private-Use-Attribute ::= CHOICE { no-value-available [0] IMPLICIT NULL, abstract-syntax-not-supported [1] IMPLICIT NULL, actual-values [2] IMPLICIT EXTERNAL } Attribute-Extensions ::= ? ExtensionsField ::= SET OF HeadingExtension Expires Dec 1994 [Page 8] Internet Draft MIME File Transfer Body Parts Jun 1994 HeadingExtension ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY DEFINED BY type DEFAULT NULL NULL} HEADING-EXTENSION MACRO ::= BEGIN TYPE NOTATION ::= "VALUE" type | empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) END 4. Mapping Philosophy The approach taken in this memo to FTBP mapping attempts to maximize interoperability with existing and future MIME object definitions. This in turn argues for making the maximum possible use of existing MIME object definitions whenever possible. So, while, this memo does define a MIME content-type specifically to hold FTBPs, this is used as last resort when all attempts to map to a specific MIME content-type have failed for some reason. However, this present a problem for handling ancillary information in FTBPs. As can be seen by the definition above, lots of ancillary information can appear in a FTBP. The obvious place to put such information would be in content-type parameters. However, MIME does not allow global content-type parameters. This means that existing and future MIME content-types could well conflict with any set of parameter names chosen to accomodate FTBP information. The memo therefore defines a set of additional MIME body part headers to contain FTBP information. These headers can be used with any MIME body part regardless of content-type. The characteristics of headers are also used to advantage to represent collections of characteristics. 5. Additional Standard Types Section 3.3 of RFC1327 [5] defines mechanisms for mapping between US-ASCII text and various ASN.1 types. However, these definitions are not sufficient to accomodate the ASN.1 usage in FTBPs. The following sections define additional mappings Expires Dec 1994 [Page 9] Internet Draft MIME File Transfer Body Parts Jun 1994 between ASN.1 objects and US-ASCII text using the EBNF notation of RFC822 [1]. All mappings are reversible except as specifically noted. 5.1. GraphicString In cases where GraphicString strings are only used for conveying human interpreted information, the intent is to render the characters appropriately in the US-ASCII character set, rather than to maximize reversibility. In other cases a precise, reversible mapping is required. 5.1.1. Nonreversible GraphicString to RFC822 conversion The GraphicString is initially converted into a list of the actual characters and character sets involved, removing any character-set-switching escape sequences. If all the characters are part of US-ASCII, the string is converted to US-ASCII and rendering operation is complete. If other characters are present the general approach described in section 7.2 of RFC1494 [6] for mapping GeneralText bodyparts is applied. Specifically, the list of character sets used in the string is converted into their the equivalent ISO IR numeric codes and the table in section 7.2 of RFC1494 is consulted. If one more more matches are found the string is converted into one or more sequences of characters in a listed character set and then encoded for use in message headers as specified in RFC1522 [3]. Note that both this mapping and the previous one are only reversible in the sense that the proper sequence of characters can be preserved -- the exact string is lost. Finally, if the approach described in RFC1494 fails, all character set information is discarded and all non-US-ASCII characters are mapped into their mnemonic equivalents defined in RFC1345 [7]. Note that this mapping is not reversible in any sense. Expires Dec 1994 [Page 10] Internet Draft MIME File Transfer Body Parts Jun 1994 5.1.2. Nonreversible RFC822 to GraphicString conversion The header text is initially converted into a list of the actual characters and character sets involved, removing any character-set-switching escape sequences. This is done by applying the decoding rules for text string defined in RFC1522. If all the characters are part of US-ASCII, the string is converted to US-ASCII and rendering operation is complete. If other characters are present the proper GraphicString control sequences to indicate the associated character sets are determined and the string is encoded using these sequences. Finally, if this mapping fails for some reason all character set information is discarded and all non-US-ASCII characters are mapped into their mnemonic equivalents defined in RFC1345 [7]. Note that this mapping is not reversible in any sense. 5.1.3. Reversible GraphicString conversions There is also a need to represent GraphicString strings in US-ASCII using a reversible mapping. In this case, the following encoding is used: graphic-string = *( gs-char / graphic-encoded ) graphic-encoded = "{" 1* graphic-encoded-char "}" graphic-encoded-char = 3DIGIT gs-char = 1DIGIT / 1ALPHA / " " / "'" / "+" / "," / "-" / "." / ":" / "=" / "?" / "(" / ")" Common characters are simply mapped to themselves. Other octets are represented as 3 decimal digits enclosed in braces. This quoting mechanism is similar to the RFC1327 mapping for T.61 strings. 5.2. SEQUENCE OF GraphicString Sequences of GraphicString strings are used for several different purposes in FTBPs. Two mappings are defined that Expires Dec 1994 [Page 11] Internet Draft MIME File Transfer Body Parts Jun 1994 parallel the mappings for individual GraphicString strings. The informal mapping is to simply convert the individual strings as described above, concatentating the result with spaces separating the strings. The nonreversible mapping of a RFC822 string to a SEQUENCE OF GraphicString simply calls the corresponding GraphicString mapping and therefore always produces a single element sequence. The second, reversible mapping uses the following encoding: graphic-string-sequence = graphic-string *( "/" graphic-string ) 5.3. Pathname-Attribute Pathname-Attribute objects consist of either a complete or incomplete Pathname, which in turn is a sequence of GraphicString strings. pathname-attribute = incomplete-pathname / complete-pathname incomplete-pathname = graphic-string-sequence complete-pathname = "/" graphic-string-sequence 5.4. PathnameandVersion PathnameandVersion objects consist of a pathname and an optional version specification. pathname-and-version = pathname-attribute [ ";" file-version ] file-version = graphic-string 5.5. GeneralIdentifier GeneralIdentifier components consist of either a object identifier or a sequence of GraphicString strings. The object identifier mapping to US-ASCII given in section 3.3.7 of RFC1327 is used when an object identifier is present. general-identifier = object-identifier / ( "/" graphic-string-sequence ) Expires Dec 1994 [Page 12] Internet Draft MIME File Transfer Body Parts Jun 1994 5.6. User-Identity User-Identity components consist of a single GraphicString user-identity = graphic-string 6. Application/file-transfer Content Type Definition (1) MIME type name: application (2) MIME subtype name: file-transfer (3) Required parameters: none (4) Optional parameters: abstract-syntax, application- reference, compression, compress-parameters, constraint-set, document-type, and document-type- parameters. (5) Encoding considerations: Either quoted-printable or base64 encoding should always be used for FTBPs. (6) Usage: The application/file-transfer body part is used only as a last resort when no mapping to an existing MIME content-type can be used. The contents of the application/file-transfer part are equivalent to the data contained in the FTBP FileTransferData component so it is directly accessible to applications without additional processing. (7) Security Considerations: none 7. Mapping FTBPs To MIME body parts The following sections detail how each piece of information in a FTBP is mapped into some component of a MIME body part. 7.1. related-stored-file mapping related-stored-file components are bidirectionally mapped into a sequence of Content-Related-Stored-File MIME body part Expires Dec 1994 [Page 13] Internet Draft MIME File Transfer Body Parts Jun 1994 headers. The syntax of these headers is as follows: related-stored-file = "Content-Related-Stored-File" ":" file-identifier [ relationship ] file-identifier = "path" pathname-and-version cross-reference cross-reference = "application" octet-string [ "message" message-reference ] [ "body-part" 1*DIGIT ] octet-string = word message-reference = 822-address "relative-id" relative-identifier relative-identifier = word relationship = explicit-relationship / descriptive-relationship explicit-relationship = "explicit-relationship" ( "Unspecified" / "New-file" / "Replacement" / "Extension" ) descriptive-relationship = "descriptive-relationship" graphic-string The MessageReference.ORName is converted to an 822-address using the mappings defined in RFC1327. A single Content- Related-Stored header is generated for each element in the RelatedStoredFile set, and vice versa. 7.2. contents-type mapping The contents-type component provides information about the structure of the data contained in the FTBP. In most cases this component is expected to take the default value. An appropriate MIME content-type is chosen based on the application-reference component when the default contents-type value is used and no compression is specified. The mapping of contents-type values other than the default or in the presence of some form of compression depends on the gateway's capabilities. If the gateway understands how to map the non-default contents-type, compression, and application- reference information into some known MIME content-type it is encouraged to do so, as this maximizes interoperability. However, if such a mapping is not possible an application/file-transfer MIME object should be generated and Expires Dec 1994 [Page 14] Internet Draft MIME File Transfer Body Parts Jun 1994 the contents-type component then becomes part of the object's content-type parameters. The MIME content-type parameters derived from the contents- type component are generated as follows. Contents-type components can either be a document-type name and parameter set or a constraint-set name and an abstract-syntax. In the former case two MIME content-type parameters are generated: "document-type" and "document-type-parameters". In the latter case two other MIME content-type parameters are generated: "constraint-set" and "abstract-syntax". "document-type- parameters" can be any ASN.1 sequence, so this information is simply encoded using the base64 encoding. All the other parameters are object identifiers and are mapped using the rules defined in section 3.3.7 of RFC1327. 7.3. environment mapping The individual elements of environment information are each mapped separately. The following sections describe each of the necessary submappings. 7.3.1. application-reference mapping Gateways should maintain a table of correspondences between application-reference object identifiers and MIME content types. When an application-reference object identifier matches one in the table and the gateway is capable of processing the FTBP's contents-type and compression, the body part should converted into a MIME object with the corresponding content- type. This table is also applied when mapping from MIME to X.400, and serves to indicate the MIME content types for which FTBPs should be generated and what their application-reference object identifier values should be. When an unknown application-reference, contents-type, or compression value is encountered an application/file-transfer MIME object should be generated instead with the application- reference parameter set accordingly. The application-reference parameter is generated using the rules for GeneralIdentifier components. Expires Dec 1994 [Page 15] Internet Draft MIME File Transfer Body Parts Jun 1994 An FTBP with no application-reference value and a default contents-type value should be mapped to the application/octet-stream MIME content-type. 7.3.2. machine mapping The machine component is bidirectionally mapped into a Content-Machine MIME body part header. The syntax of this headers is as follows: machine = "Content-Machine" ":" general-identifier 7.3.3. operating-system mapping The operating-system component is bidirectionally mapped into a Content-Operating-System MIME body part header: operating-system = "Content-Operating-System" ":" object-identifier The rules for object identifier mapping are defined in section 3.3.7 of RFC1327. 7.3.4. user-visible-string mapping The user-visible-string component is mapped to and from the Content-Description MIME body part header using the nonreversible mappings for SEQUENCE OF GraphicString. 7.4. compression mapping The compression component provides information about any compression algorithm that has been applied to the data contained in the FTBP. In most cases this component is expected to be absent. When it is absent the mappings described in the section on application-reference components should be used. When compression is used the mapping used depends on the gateway's capabilities. If the gateway understands how to map the specified compression, contents-type, and application- Expires Dec 1994 [Page 16] Internet Draft MIME File Transfer Body Parts Jun 1994 reference information into some known MIME content-type it is encouraged to do so, as this maximizes interoperability. However, if such a mapping is not possible an application/file-transfer MIME object should be generated and the compression component then becomes part of the object's content-type parameters. The MIME content-type parameters derived from the compression component are generated as follows. Compression information consists of an object identifier indicating the compression algorithm used along with some algorithm-specific parameter information. These are used to generate two MIME content-type parameters: "compression" and "compression-parameters". The "compression" parameter is an object identifier and is mapped using the rules defined in section 3.3.7 of RFC1327. "compression-parameters" can be any ASN.1 sequence, so this information is simply encoded using the base64 encoding. 7.5. file-attributes mapping The individual elements of file-attributes information are each mapped separately. The following sections describe each of the necessary submappings. 7.5.1. pathname mapping The pathname component is bidirectionally mapped into a Content-Pathname MIME body part header: pathname = "Content-Pathname" ":" pathname-attribute 7.5.2. permitted-actions mapping The permitted-actions component is bidirectionally mapped into Expires Dec 1994 [Page 17] Internet Draft MIME File Transfer Body Parts Jun 1994 a Content-Permitted-Actions MIME body part header: permitted-actions = "Content-Permitted-Actions" ":" 1#permitted-actions-item permitted-actions-item = "Read" / "Insert" / "Replace" / "Extend" / "Erase" / "Read-attribute" / "Change-attribute" / "Delete-file" / "Traversal" / "Reverse-traversal" / "Random-Order" 7.5.3. storage-account mapping The storage-account component is bidirectionally mapped into a Content-Storage-Account MIME body part header: storage-account = "Content-Storage-Account" ":" graphic-string Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.4. date-and-time-of-creation mapping The date-and-time-of-creation component is bidirectionally mapped into a Content-Creation-Date MIME body part header: creation-date = "Content-Creation-Date" ":" date-time Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.5. date-and-time-of-last-modification mapping The date-and-time-of-last-modification component is bidirectionally mapped into a Content-Last-Modification-Date MIME body part header: last-modification-date = "Content-Last-Modification-Date" ":" Expires Dec 1994 [Page 18] Internet Draft MIME File Transfer Body Parts Jun 1994 date-time Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.6. date-and-time-of-last-read-access mapping The date-and-time-of-last-read-access component is bidirectionally mapped into a Content-Last-Read-Date MIME body part header: last-read-date = "Content-Last-Read-Date" ":" date-time Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.7. identity-of-creator mapping The identity-of-creator component is bidirectionally mapped into a Content-Creator MIME body part header: creator = "Content-Creator" ":" user-identity Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.8. identity-of-last-modifier mapping The identity-of-last-modifier component is bidirectionally mapped into a content-modifier MIME body part header: last-modifier = "Content-Last-Modifier" ":" user-identity Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. Expires Dec 1994 [Page 19] Internet Draft MIME File Transfer Body Parts Jun 1994 7.5.9. identity-of-last-reader mapping The identity-of-last-reader component is bidirectionally mapped into a Content-Last-Reader MIME body part header: last-reader = "Content-Last-Reader" ":" user-identity Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.10. object-size mapping The object-size-mapping component is bidirectionally mapped into a Content-Object-Size MIME body part header: reader = "Content-Object-Size" ":" 1*DIGIT Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.11. future-size mapping The future-object-size-mapping component is bidirectionally mapped into a Content-Future-Object-Size MIME body part header: reader = "Content-Future-Object-Size" ":" 1*DIGIT Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.12. access-control mapping access-control components are bidirectionally mapped into a sequence of Content-Access-Control MIME body part headers. The Expires Dec 1994 [Page 20] Internet Draft MIME File Transfer Body Parts Jun 1994 syntax of these headers is as follows: access-control = "Content-Access-Control" ":" access-control-element access-control-element = action-list [ ";" concurrency-access ] [ ";" identity ] [ ";" passwords ] [ ";" location ] action-list = "actions" #access-request access-request = "read" / "insert" / "replace" / "extend" / "erase" / "read-attribute" / "change-attribute" / "delete-file" concurrency-access = "concurrency" "read" concurrency-key "insert" concurrency-key "replace" concurrency-key "extend" concurrency-key "erase" concurrency-key "read-attribute" concurrency-key "change-attribute" concurrency-key "delete-file" concurrency-key concurrency-key = "not-required" / "shared" / "exclusive" / "no-access" identity = "identity" user-identity passwords = "passwords" "read" password "insert" password "replace" password "extend" password "erase" password "read-attribute" password "change-attribute" password "delete-file" password password = graphic-password / octet-password graphic-password = "string" graphicstring octet-password = "binary" base64 base64 = * location = "location" base64 A single Content-Access-Control file header is generated for Expires Dec 1994 [Page 21] Internet Draft MIME File Transfer Body Parts Jun 1994 each Access-Control-Element in the Access-Control-Attribute set, and vice versa. 7.5.13. legal-qualifications mapping The legal-qualifications component is mapped to and from the Content-Legal-Qualifications header using the nonreversible mappings for GraphicString components. legal-qualification = "Content-Legal-Qualifications" ":" *text Note that the no-value-available choice is only intended for FTAM response PDUs and hence does not have to be dealt with in this context. 7.5.14. private-use mapping private-use information in FTBPs is discarded when mapping to MIME, and MIME never generates private-use information of its own. 7.5.15. attribute-extensions mapping attribute-extensions information in FTBPs is discarded when mapping to MIME, and MIME never generates attribute-extensions information of its own. 7.6. extensions mapping extensions components are used to carry MIME body part Content- header information that does not correspond to a previously defined FTBP field. This would include Content-Id headers, for example. The X.400 extension field defined in RFC1327 is used to carry MIME header information: rfc-822-field HEADING-EXTENSION VALUE RFC822FieldList ::= id-rfc-822-field-list Expires Dec 1994 [Page 22] Internet Draft MIME File Transfer Body Parts Jun 1994 RFC822FieldList ::= SEQUENCE OF RFC822Field RFC822Field ::= IA5String The object identifier id-rfc-822-field-list is defined in Appendix D of RFC1327. To encode any MIME body part Content- header using this extension, an RFC822Field element is built using the entire text of the Content- field, including the Content- prefix and omitting the trailing CRLF (e.g., "Content-Id: <06.06.1944@omaha.fr>"). Multiline headers must be fully unfolded. No spaces are allowed before the initial ":". The reverse mapping builds the MIME Content- header in a straightforward manner. Any other extensions are discared when mapping to MIME, and MIME never generates any extensions other than rfc-822-field. 8. FileTransferData Mapping The FileTransferData component contains the actual file data being transferred. This component is defined as a SEQUENCE OF EXTERNAL. The rules for generating this sequence are implied by the value of the contents-type component. It is expected that the contents-type component will usually have its default value, and when this the following conditions should hold: (1) The direct-reference value will be set to {iso standard 8571 document-type (5) unstructured-binary (3)}. (This is the same object identifer that appears in the content-types component.) (2) The indirect-reference and data-value-descriptor components will be absent. (3) The octet-aligned encoding will be used. This data is extracted, encoded using either the quoted-printable or base64 encoding, and placed in the body of the MIME body part. (4) Only a single EXTERNAL component will appear in the FileTransferData sequence. Expires Dec 1994 [Page 23] Internet Draft MIME File Transfer Body Parts Jun 1994 The first three of these conditions are mandatory. No mapping is defined for FTBPs that violate these conditions. The fourth condition is optional. When multiple EXTERNAL components appear their contents will be concatenated and treated as a single entity. The mapping of other FileTransferData components is not specified by this memo. 9. Security Considerations This memo does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail. Expires Dec 1994 [Page 24] Internet Draft MIME File Transfer Body Parts Jun 1994 10. References [1] D.H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, (August, 1982). [2] N.S. Borenstein, N. Freed. Multipurpose Internet Mail Extensions Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. Request for Comments 1521, September 1993. [2] K. Moore. Multipurpose Internet Mail Extensions Part Two: Message Header Extensions for Non-ASCII Text. Request for Comments 1522, September 1993. [4] CCITT/ISO. CCITT Recommendations X.420/ ISO IS 10021-7. Message Handling Systems: Interpersonal Messaging System. 1992 Draft. [5] S. Hardcastle-Kille. Mapping between X.400(1988) / ISO 10021 and RFC822. Request for Comments 1327, University College London, May 1992. [6] H. Alvestrand and S. Thompson. Equivalences between 1988 X.400 and RFC822 Message Bodies. Request for Comments 1494, SINTEF DELAB, Soft*Switch, Inc., August 1993. [7] K. Simonsen. Character Mnemonics & Character Sets. Request for Comments 1345, Rationel Almen Planlaegning, June 1992. 11. Author Address Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA tel: +1 818 919 3600 fax: +1 818 919 3614 email: ned@innosoft.com Expires Dec 1994 [Page 25]