Internet DRAFT - draft-ietf-mimemhs-ftbp
draft-ietf-mimemhs-ftbp
Network Working Group Ned Freed
Internet Draft <draft-ietf-mimemhs-ftbp-00.txt>
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 = *<any legal base64
encoding character>
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]
