rfc1494.txt

<VC++网络游戏建摸与实现>源代码

   BilaterallyDefined Body Part does not have any corresponding ASN.1
   parameters.

   DISCUSSION: The parameters "name" "type" and "conversions" are
   advisory, but may in some cases give vital hints on the expected
   handling of the file. The parameter "conversions" is not fully
   defined, but it is expected that it will be useful, so we cannot drop
   it and expect people to be satisfied.

   The parameter "padding" changes the interpretation of the last byte
   of the data, and so cannot be deleted.

   An option is to prepend an IA5 body part that contains the parameter
   text; this will aid unmodified readers, and can probably be made



Alvestrand & Thompson                                          [Page 13]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   reversible with suitable chicanery, but is it worth it????

   Also, use of BilaterallyDefined Body Parts is specifically deprecated
   in both 1988 and 1992 X.400.  It is retained solely for backward
   compatibility with 1984 systems. 1992 X.400 defines a File Transfer
   Body Part to solve this problem (i.e. binary file transfer through
   email). The standard and its regional profiles are not solid enough
   yet to exploit as a solution for this problem.

7.4.  ODA - application/oda

   X.400 Body Part: ODA
   MIME Content-Type: application/oda
   Conversion Type: Byte copy
   Comments:

   The ODA body part is defined in the CCITT document T.411 [6],
   appendix E, section E.2, "ODA identification in the P2 protocol of
   MHS"

   An abbreviated version of its ASN.1 definition is:

       oda-body-part EXTENDED-BODY-PART-TYPE
            PARAMETERS      OdaBodyPartParameters
            DATA            OdaData
            ::= id-et-oda

       OdaBodyPartParameters ::= SET {
            document-application-profile    [0] OBJECT IDENTIFIER
            document-architecture-class     [1] INTEGER {
                                            formatted (0)
                                            processable (1)
                                            formatted-processable(2)}}

       id-et-oda OBJECT IDENTIFIER ::= { 2 8 1 0 1 }

   Mapping from X.400 to MIME, the following is done:

   The Parameters.document-application-profile is mapped onto the MIME
   parameter "profile" according to the table below.

       Profile         OBJECT IDENTIFIER

       Q112            { iso (1) identified-organization (3) ewos (16)
                         eg (2) oda (6) profile (0)  q112 (1) }

   The Parameters.document-architecture-class is mapped onto the MIME
   parameter "class" according to the table below



Alvestrand & Thompson                                          [Page 14]

RFC 1494              X.400/MIME Body Equivalences           August 1993


       String                  Integer

       formatted               formatted(0)
       processable             processable(1)
       formatted-processable   formatted-processable(2)

   NOTE: This parameter is not defined in RFC 1341.

   The body of the MIME content-type is the Data part of the ODA body
   part.

   When mapping from MIME to X.400, the following steps are done:

   The Parameters.document-application-profile and Parameters.document-
   architecture-class are set from the tables above.  If any of the
   parameters are missing, the values for Q112 and formatted-processable
   are used.

   It is an option for the gateway implementor to try to access them
   from inside the document, where they are defined as

   document-profile.document-characteristics.document-architecture-class

   document-profile.document-characteristics.document-application-profile

   Gateways are NOT required to do this, since the document-
   characteristics are optional parameters.  If a gateway does not, it
   simply uses the defaulting rules defined above.

   The OBJECT IDENTIFIERs for the document application profile and for
   ODA {2 8 0 0} must be added to the Encoded Information Types
   parameter of the message envelope.

7.5.  g3-facsimile - image/g3fax

   X.400 Body part: g3-facsimile
   MIME Content-Type: image/g3fax
   Conversion Type: nearly Byte copy
   Comments:

   The Parameters of the X.400 G3Fax body part are mapped to the
   corresponding Parameters on the MIME Image/G3Fax body part and vice
   versa.  Note that:

       (1)  If fineResolution is not specified, pixels will be
            twice as tall as they are wide

       (2)  If any bit not corresponding to a specially named



Alvestrand & Thompson                                          [Page 15]

RFC 1494              X.400/MIME Body Equivalences           August 1993


            option is set in the G3Fax NonBasicParameters, the
            "DCS" parameter must be used.

       (3)  Interworking is not guaranteed if any bit apart from
            those specially named are used in the
            NonBasicParameters

   From X.400 to G3Fax, the body is created in the following way:

       (1)  Any trailing EOL markers on each bitstring is
            removed. The bistring is padded to a byte boundary.

       (2)  6 consecutive EOL markers are appended to each
            bitstring.

       (3)  The padded bitstrings are concatenated together

   An EOL marker is the bit sequence 000000000001 (11 zeroes and a one).

   From G3Fax to X.400, the body is created in the following way:

       (1)  The body is split into bitstrings at each occurrence
            of 6 consecutive EOL markers, and trailing EOLs and
            padding are removed

       (2)  Each bitstring is made into an ASN.1 BITSTRING

       (3)  The bitstrings are made into an ASN.1 SEQUENCE, which
            forms the body of the G3Fax body part.

7.6.  application/postscript - postscript-body-part

   X.400 Body Part: Extended Body Part, OID postscript-body-part
   MIME Content-Type: application/postscript
   Conversion Type: Byte Copy

7.7.  application/jpeg - jpeg-body-part

   X.400 Body Part: Extended Body Part, OID jpeg-body-part
   MIME Content-Type: application/jpeg
   Conversion Type: Byte Copy

7.8.  image/gif - gif-body-part

   X.400 Body Part: Extended Body Part, OID gif-body-part
   MIME Content-Type: application/gif
   Conversion Type: Byte Copy




Alvestrand & Thompson                                          [Page 16]

RFC 1494              X.400/MIME Body Equivalences           August 1993


8.  OID Assignments

       MIME-MHS-MAPPINGS DEFINITIONS ::= BEGIN


       IMPORTS
          mail, mime-mhs, mime-mhs-bodies
              FROM MIME-MHS;

       mime-mhs-bp-data OBJECT IDENTIFIER ::=
               { mime-mhs-bodies 1}

       mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
               { mime-mhs-bodies 2}

       mime-generic-data OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 1}

       mime-generic-parameters OBJECT IDENTIFIER ::=
               { mime-mhs-bp-parameter 1}

       mime-postscript-body OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 2}

       mime-jpeg-body OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 3}

       mime-gif-body OBJECT IDENTIFIER ::=
               { mime-mhs-bp-data 4};

9.  IANA Registration form for new mappings

   To: [e-mail]
   Subject: Registration of new X.400/MIME content type mapping

   MIME type name:

   (this must have been registered previously with IANA)

   X.400 body part:

   X.400 Object Identifier for Data:

   (If left empty, an OID will be assigned by IANA under
   mime-mhs-bp-data)

   X.400 Object Identifier for Parameters:




Alvestrand & Thompson                                          [Page 17]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   (If left empty, an OID will be assigned by IANA under
   mime-mhs-bp-parameter.  If it is not used, fill in the
   words NOT USED.)

   X.400 ASN.1 Syntax:

   (must be an EXTENDED-BODY-PART-TYPE macro, or reference to
   a Basic body part type)

   Conversion algorithm:

   (must be defined completely enough for independent
   implementation. It may be defined by reference to RFCs).

   Person & email address to contact for further information:

   INFORMATION TO THE SUBMITTER:

   The accepted registrations will be listed in the "Assigned
   Numbers" series of RFCs.  The information in the
   registration form is freely distributable.

10.  Security Considerations

   Security issues are not discussed in this memo.

11.  Authors' Addresses

   Harald Tveit Alvestrand
   SINTEF DELAB
   N-7034 Trondheim
   NORWAY

   EMail: [e-mail]


   Steven J. Thompson
   Soft*Switch, Inc.
   640 Lee Road
   Wayne, PA 19087

   Phone: [phone]
   EMail: [e-mail]








Alvestrand & Thompson                                          [Page 18]

RFC 1494              X.400/MIME Body Equivalences           August 1993


12.  References

   [1]  Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
        "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
        SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
        Consulting, Inc., Soft*Switch, Inc., August 1993.

   [2]  CCITT Recommendation X.420 (1988), Interpersonal Messaging
        System.

   [3]  Borenstein, N, and N. Freed, "MIME: Mechanisms for Specifying
        and Describing the Format of Internet Message Bodies", RFC 1341,
        Bellcore, Innosoft, June 1992.

   [4]  ISO 8613; Information Processing: Text and Office System; Office
        Document Architecture (ODA) and Interchange Format (ODIF), Part
        1-8, 1989.

   [5]  ISO/IEC International Standard 10021, Information technology -
        Text Communication - Message-Oriented Text Interchange Systems
        (MOTIS) (Parts 1 to 8).

   [6]  CCITT Recommendation T.411 (1988), Open Document Architecture
        (ODA) and Interchange Format, Introduction and General
        Principles.

   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDEL, August 1982.

   [8]  Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
        and RFC-822", RFC 1327, University College London, May 1992.

   [9]  CCITT Recommendation T.4, Standardization of Group 3 Facsimile
        Apparatus for Document Transmission (1988).

   [10] CCITT Recommendation T.30, Procedures For Document Facsimile
        Transmission in the General Switched Telephone Network (1988).

   [11] CCITT, Data Communication Networks - Message Handling Systems -
        Recommendations X.400 - X.420 (1988 version).

   [12] Alvestrand, H., "X.400 Use of Extended Character Sets", RFC
        1502, SINTEF DELAB, August 1993.








Alvestrand & Thompson                                          [Page 19]