Re: Questions about RFCs 1494, 1495.

Ned Freed <NED@sigurd.innosoft.com> Sun, 05 June 1994 07:18 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14312; 5 Jun 94 3:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14308; 5 Jun 94 3:18 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa17661; 5 Jun 94 3:18 EDT
Received: from SIGURD.INNOSOFT.COM by survis.surfnet.nl with SMTP (PP) id <07474-0@survis.surfnet.nl>; Sun, 5 Jun 1994 08:49:56 +0200
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HD4CXGWAGW96VTLQ@SIGURD.INNOSOFT.COM>; ) id <Sat, 4 Jun 1994 10:45:02 PDT
Date: Sat, 04 Jun 1994 10:43:03 -0700 (PDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: Questions about RFCs 1494, 1495.
In-reply-to: Your message dated "Fri, 03 Jun 1994 10:03:09 +0200" <199406030803.AA05563@chandon.inria.fr>
To: wg-msg@rare.nl, mime-mhs@surfnet.nl, Internet-Drafts@CNRI.Reston.VA.US
Message-id: <01HD53S97BD096VTLQ@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID wZMaE3MkkGATt/Vo3S3qQg)"

As I mentioned in some previous mail, here is the latest revision of my
document describing the mapping of File Transfer Body Parts to and from
MIME.

I'm also posting this as an Internet Draft at this time.

				Ned






Network Working Group                                Ned Freed
Internet Draft               <draft-ietf-mime-mhs-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]