As per Relevance of the word identifier, we have this rfc below:
Network Working Group H.
Request for Comments: 1494 SINTEF
S.
Soft*Switch, Inc
August 1993
Equivalences between 1988 X.400 and RFC-822 Message
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
Table of
1. Introduction ............................................. 2
2. Equivalence Table Definition ............................. 2
3. Generic conversions ...................................... 3
3.1. Byte copy .............................................. 3
3.2. Text Conversion ........................................ 3
3.3. Image Conversion ....................................... 3
3.4. Tunneling .............................................. 3
4. Conversion Table for known X.400 and MIME Types ......... 4
4.1. MIME to X.400 Table .................................... 4
4.2. X.400 to MIME Table .................................... 4
5. Newly defined X.400 Body Parts ........................... 5
5.1. Use of OBJECT IDENTIFIERs and ASN.1 MACROS ............. 5
5.2. The Generic MIME Extended Body Part .................... 6
5.3. The PostScript body part ............................... 7
5.4. The JPEG body part ..................................... 7
5.5. The GIF body part ...................................... 8
6. Newly defined MIME content-types ......................... 8
6.1. The application/x400-bp content-type ................... 8
6.2. The image/g3fax content-type ........................... 9
6.2.1. G3Fax Parameters ..................................... 9
6.2.2. Content Encoding ..................................... 10
6.3. The Application/ODA content-type ....................... 11
7. Equivalence Definitions ................................... 11
7.1. IA5Text - text/plain .................................... 11
7.2. GeneralText - text/plain (ISO-8859) ..................... 12
7.3. BilaterallyDefined - application/octet-stream .......... 13
7.4. ODA - application/oda ................................... 14
7.5. g3-facsimile - image/g3fax .............................. 15
7.6. application/postscript - postscript-body-part .......... 16
7.7. application/jpeg - jpeg-body-part ....................... 16
Alvestrand & Thompson [Page 1]
RFC 1494 X.400/MIME Body Equivalences August 1993
7.8. image/gif - gif-body-part ............................... 16
8. OID Assignments ........................................... 17
9. IANA Registration form for new mappings ................... 17
10. Security Considerations .................................. 18
11. Authors' Addresses ....................................... 18
12. References ............................................... 19
1.
This document is a companion to [1], which defines the
behind interworking between MIME-based RFC-822 mail and X.400 mail
This document describes the content of the "IANA MHS/MIME
table" referenced in the companion document, and defines the
configuration of this table. Mappings for new MIME content-
and/or X.400 body part types should be registered with the IANA
minimize redundancy and promote interoperability
In MIME, the term "content-type" is used to refer to an
object contained in the body of a message. In contrast, X.400
the term "body part type." In this document, the term "body part"
used to refer to either
Please send comments to the MIME-MHS mailing list
.
2. Equivalence Table
For each MIME content-type/X.400 body part pair, the
Table will contain an entry with the following sections
X.400 Body
This section identifies the X.400 Body Part governed by
Table entry. It includes any OBJECT IDENTIFIERs or
parameters necessary to uniquely identify the Body Part
MIME Content-
This section identifies the MIME content-type governed by
Table entry. The MIME content-type named here must
registered with the IANA
Conversion
This section identifies the type of conversion applied. See
section on Generic Conversions for an explanation of
possible values
Alvestrand & Thompson [Page 2]
RFC 1494 X.400/MIME Body Equivalences August 1993
Comments (optional
This section gives any additional commentary that might
useful in understanding the mapping between the X.400 and
representations
The initial Equivalence Table entries in this document are
using this convention. Any future submissions to the IANA
follow this format
3. Generic
3.1. Byte
This is the trivial case, that is, no conversion at all. The
stream is simply copied between MIME and X.400.
This is the preferred conversion, since it is the simplest
Implementors and vendors will be registering OBJECT IDENTIFIERs
MIME content-types for their various objects. They are
ENCOURAGED to specify their content formats such that a gateway
use Byte Copy to map between them
Note that in some cases, it is necessary to define exactly
ASN.1 construct to replace with the content of the MIME object
3.2. Text
This type of conversion applies to text objects that cannot be
using a simple Byte Copy. Conversion involves scanning
reformatting the object. For example, the MIME and X.400
might differ in their encoding of nonstandard characters, or line
page breaks
3.3. Image
This conversion type applies to raster images, like Group 3
or JPEG. Again, it differs from Byte Copy in that it
scanning reformatting the byte stream. It differs from
Conversion in that it is pixel- oriented, rather than character
oriented
3.4.
This is not a conversion at all, but an encapsulation of the object
This is the fallback conversion, used when no explicit
applies
Alvestrand & Thompson [Page 3]
RFC 1494 X.400/MIME Body Equivalences August 1993
4. Conversion Table for known X.400 and MIME
This section itemizes the equivalences for all currently known
content-types and X.400 body parts
4.1. MIME to X.400
MIME content-type X.400 Body Part
----------------- ------------------ -------
text/
charset=us-ascii ia5-text 7.1
charset=iso-8859-x EBP - GeneralText 7.2
text/richtext no mapping defined 5.2
application/oda EBP - ODA 7.4
application/octet-stream bilaterally-defined 7.3
application/postscript EBP - mime-postscript-body 5.4, 7.6
image/g3fax g3-facsimile 6.2, 7.5
image/jpeg EBP - mime-jpeg-body 5.5, 7.7
image/gif EBP - mime-gif-body 5.6, 7.8
audio/basic no mapping defined 5.2
video/mpeg no mapping defined 5.2
Abbreviation: EBP - Extended Body
4.2. X.400 to MIME
Basic Body
X.400 Basic Body Part MIME content-type
--------------------- -------------------- -------
ia5-text text/plain;charset=us-ascii 7.1
voice No Mapping Defined 6.1
g3-facsimile image/g3fax 6.2, 7.5
g4-class1 no mapping defined 6.1
teletex no mapping defined 6.1
videotex no mapping defined 6.1
encrypted no mapping defined 6.1
bilaterally-defined application/octet-stream 7.3
nationally-defined no mapping defined 6.1
externally-defined See Extended Body Parts 6.1
X.400 Extended Body Part MIME content-type
------------------------- -------------------- -------
GeneralText text/plain;charset=iso-8859-x 7.2
ODA application/oda 7.4
mime-postscript-body application/postscript 5.3, 7.6
mime-jpeg-body image/jpeg 5.4, 7.7
mime-gif-body image/gif 5.5, 7.8
Alvestrand & Thompson [Page 4]
RFC 1494 X.400/MIME Body Equivalences August 1993
5. Newly defined X.400 Body
This section defines new X.400 Body Parts for the purposes
interworking with MIME
All new X.400 Body Parts defined here will be Extended Body Parts,
defined in CCITT Recommendation X.420 [2].
5.1. Use of OBJECT IDENTIFIERs and ASN.1
X.420 dictates that Extended Body Parts shall
(1) use OBJECT IDENTIFIERs (OIDs) to uniquely
the contents,
(2) be defined by using the ASN.1 Macro
EXTENDED-BODY-PART-TYPE MACRO::=
TYPE NOTATION ::= Parameters
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER
Parameters ::= "PARAMETERS" type "IDENTIFIED
"BY" value(OBJECT IDENTIFIER
| empty
Data ::= "DATA"
To meet these requirements, this document uses the
mime-mhs-
defined in [1], as the root OID for X.400 Extended Body Parts
for MIME interworking
Each Extended Body Part contains Data and optional Parameters,
being named by an OID. To this end, two OID subtrees are
under mime-mhs-bodies, one for Data, and the other for Parameters
mime-mhs-bp-data OBJECT IDENTIFIER ::=
{ mime-mhs-bodies 1 }
mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
{ mime-mhs-bodies 2 }
All definitions of X.400 body parts submitted to the IANA
registration must use the Extended Body Part Type macro for
definition. See the next section for an example
Alvestrand & Thompson [Page 5]
RFC 1494 X.400/MIME Body Equivalences August 1993
Lastly, the IANA will use the mime-mhs-bp-data and mime-mhs-bp
parameter OIDs as root OIDs for any new MIME content-type/
that aren't otherwise registered in the Equivalence Table
5.2. The Generic MIME Extended Body
The following X.400 Body Part is defined to carry any MIME content
type for which there is no explicit IANA registered mapping
mime-body-part EXTENDED-BODY-PART-
PARAMETERS
IDENTIFIED BY mime-generic-
DATA OCTET
::= mime-generic-
MimeParameters ::=
SEQUENCE {
content-type IA5String
content-parameters SEQUENCE
SEQUENCE {
parameter IA5String
parameter-value IA5
}
-- from RFC-1327, sec. 5.1.12
other-header-fields RFC822
}
mime-generic-parameters OBJECT IDENTIFIER ::=
{ mime-mhs-bp-parameter 1 }
mime-generic-data OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 1 }
To convert the MIME content-type into the X.400 mime- body-part
(1) Copy the "type/subtype" string from the
Content-Type: header field
MimeParameters.content-
(2) For each "parameter=value" string in the
Content-Type header field, create
MimeParameters.content-parameters structure, and
the "parameter" string into MimeParameters.content
parameters.parameter field and the "value"
into the paired MimeParameters.content
parameters.parameter-value field
(3) Convert the MIME body part into its canonical form
Alvestrand & Thompson [Page 6]
RFC 1494 X.400/MIME Body Equivalences August 1993
(See appendix H of RFC 1341 [3] for a
of canonical in this context.) Said another way
reverse the transfer encoding to recover the
byte stream
(4) Copy the canonical byte stream into the mime-body
part.data octet string
(5) Remove the Content-type and the Content-transfer
encoding header fields from the MIME body part'
RFC822 header
(6) Any header fields starting with "Content-" in
MIME body part is placed in the optional other
header-fields structure. Note that this can
occur when the MIME content-type occurs as part of
"multipart" content-type
The mapping from the X.400 mime-body-part to a MIME content-type
the inverse of the above steps
5.3. The PostScript body
The following Extended Body Part is defined for PostScript
streams. It has no parameters
postscript-body-part EXTENDED-BODY-PART-
DATA OCTET
::= mime-postscript-
mime-postscript-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 2 }
5.4. The JPEG body
The following Extended Body Part is defined for JPEG data streams
It has no parameters
jpeg-body-part EXTENDED-BODY-PART-
DATA OCTET
::= mime-jpeg-
mime-jpeg-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 3 }
Alvestrand & Thompson [Page 7]
RFC 1494 X.400/MIME Body Equivalences August 1993
5.5. The GIF body
The following Extended Body Part is defined for GIF data streams.
has no parameters
gif-body-part EXTENDED-BODY-PART-
DATA OCTET
::= mime-gif-
mime-gif-body OBJECT IDENTIFIER ::=
{ mime-mhs-bp-data 4 }
6. Newly defined MIME content-
This section defines new MIME content-types for the purposes
interworking with X.400.
6.1. The application/x400-bp content-
This content-type is defined to carry any X.400(88) body part
which there is no registered IANA mapping
The content-type field
application/x400-
The parameters are
bp-type=IDENTIFIER
The body contains the raw ASN.1 IPM.body octet stream, including
initial tag octet
If the body is a basic body part, the bp-type parameter is set to
number of the body part's context-specific tag, that is, the tag
the IPMS.Body.BodyPart component
If the body is an Extended Body Part, the bp-type parameter is set
the OBJECT IDENTIFIER
IPMS.body.externally-defined.data.direct-
No attempt is made to turn the parameters of Extended Body Parts
MIME parameters. (This task is the responsibility of the recipient'
UA).
For example, a basic VideotexBodyPart will
Alvestrand & Thompson [Page 8]
RFC 1494 X.400/MIME Body Equivalences August 1993
Content-type=application/x400-bp; bp-type=6
whilst a Extended Videotex body part will
Content-type=application/x400-bp; bp-type=2.6.1.4.5
application/x400-bp will need a content-transfer-encoding of base64
or quoted-printable when carried in 7-bit MIME. Since there is
way to know beforehand the content, it is recommended to just
the first 1 KByte or so of data and choose the one that seems
produce the more compact encoding
If this is not feasible, Base64 is recommended
6.2. The image/g3fax content-
This content-type is defined to carry G3 Facsimile byte streams
In general, a G3Fax image contains 3 pieces of information
(1) A set of flags indicating the particular
scheme. CCITT Recommendation T.30 defines how
flags are transmitted over telephones. In
medium, the flags are carried as parameters in
MIME content-type header field
(2) A structure that divides the bits into pages.
recommendation T.30 describes how to define
boundaries. A page break algorithm is defined
that is independent of how the image data
conveyed
(3) For each page, a sequence of bits that form
encoding of the image. CCITT recommendation T.4
defines the bit image format. This is used
change
6.2.1. G3Fax
The following parameters are defined
(1) page-length - possible values: A4, B4 and
(2) page-width - possible values: A3, A4, B
(3) encoding - possible values: 1-dimensional, 2-
dimensional,
Alvestrand & Thompson [Page 9]
RFC 1494 X.400/MIME Body Equivalences August 1993
(4) resolution - possible values: Fine,
(5) DCS - a bit string, represented in Base64.
(6) pages - an integer, giving the number of pages in
If nothing is specified, the default parameter settings are
page-length=A
page-width=A
encoding=1-
resolution=
It is possible (but misleading) to view the representation of
values as single-bit flags. They correspond to the following bits
the T.30 control string and X.400 G3FacsimileParameters
Parameter T.30 bit X.400
page-length=A4 no bit
page-length=B4 19 21
page-length=Unlimited 20 20
page-width=A4 no bit
page-width=A3 18 22
page-width=B4 17 23
encoding=1-dimensional no bit
encoding=2-dimensional 16 8
encoding=Uncompressed 26 30
resolution=Coarse no bit
resolution=Fine 15 9
The reason for the different bit numbers is that X.400 counts bits
an octet from the MSB down to the LSB, while T.30 uses the
numbering scheme
If any bit but these are set in the Device Control String, the
parameter should be supplied
6.2.2. Content
X.400 defines the g3-facsimile data stream as a SEQUENCE of
STRINGs. Each BIT STRING is a page of facsimile image data,
as defined by Recommendation T.4. The following content encoding
reversible between MIME and X.400 and ensures that page breaks
Alvestrand & Thompson [Page 10]
RFC 1494 X.400/MIME Body Equivalences August 1993
honored in the MIME representation
An EOL is defined as a bit sequence
000000000001 (eleven zeroes and a one).
Each page of the message is delimited by a sequence of six (6)
that MUST start on a byte boundary. The image bit stream is
as needed to achieve this alignment
Searching for the boundary is a matter of searching for the
sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur
the image
See Section 7.5 for the algorithm on conversion between this
and the X.400 encoding
The Base64 content-transfer-encoding is appropriate for carrying
content-type
6.3. The Application/ODA content-
The "ODA" subtype of application is used to indicate that a
contains information encoded according to the Office
Architecture [4] standards, using the ODIF representation format
For application/oda, the Content- Type line should also specify
attribute/value pair that indicates the document application
(DAP), using the key word "profile", and the document class,
the keyword "class".
For the keyword "class", the values "formatted", "processable"
"formatted-processable" are legal values
Thus an appropriate header field might look like this
Content-Type: application/oda; profile=Q112;
class=
Consult the ODA standard [4] for further information
The Base64 content-transfer-encoding is appropriate for carrying ODA
7. Equivalence
7.1. IA5Text - text/
X.400 Body Part: IA5
MIME Content-type: text/plain; charset=US-
Alvestrand & Thompson [Page 11]
RFC 1494 X.400/MIME Body Equivalences August 1993
Conversion Type: Byte
Comments
When mapping from X.400 to MIME, the "repertoire" parameter
ignored
When mapping from MIME to X.400, the "repertoire" parameter is set
IA5 (5).
NOTE: The MIME Content-type headers are omitted, when mapping
X.400 to MIME, if and only if the IA5Text body part is the only
part in the IPMS.Body sequence
NOTE: IA5Text specifies the "currency" symbol in position 2/4.
is converted without comment to the "dollar" symbol, since the
of this document has seen many documents in which the position
intended to indicate "dollar" while he has not yet seen one in
the "currency" symbol is intended
(For reference: The T.50 (1988) recommendation, which defines IA5,
talks about ISO registered set number 2, while ASCII, using
"dollar" symbol, is ISO registered set number 6. There are no
differences.)
7.2. GeneralText - text/plain (ISO-8859)
X.400 Body Part: GeneralText; CharacterSets
6,100,101,109,110,126,127,138,144,148
MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
Conversion Type: Byte
Comments
When mapping from X.400 to MIME, the character-set chosen from
below according to the value of Parameters.CharacterSets
When mapping from MIME to X.400, GeneralText is an Extended
Part, hence it requires an OID. The OID for the GeneralText body
defined in [5], part 8, annex D, as {2 6 1 4 11}. The OID for
parameters is {2 6 1 11 11}.
The Parameters.CharacterSets is set from table below according to
value of "charset
NOTE: The GeneralText body part is defined in ISO 10021-8 [5],
NOT in the corresponding CCITT recommendation. Its parameters
heavily modified in a defect report, and will be a SET OF
(indicating the ISO registry numbers of all the used sets) in
next version of the standard
Alvestrand & Thompson [Page 12]
RFC 1494 X.400/MIME Body Equivalences August 1993
The following table lists the MIME character sets and
corresponding ISO registry numbers. If no correspondence is found
this conversion fails, and the generic body part approach is used
MIME charset ISO IR numbers
-----------------------------------------------
ISO-8859-1 6, 100 West European "8-bit ASCII
ISO-8859-2 6, 101 East
ISO-8859-3 6, 109 obsolete
ISO-8859-4 6, 110 obsolete
ISO-8859-5 6, 144
ISO-8859-6 6, 127
ISO-8859-7 6, 126
ISO-8859-8 6, 138
ISO-8859-8 6, 148 Other Latin-using
When converting from MIME to X.400, generate the correct OIDs for
in the message envelope's Encoded Information Types by looking up
ISO IR number in the above table, and then appending it to the id
cs-eit-authority {1 0 10021 7 1 0} OID
The escape sequences to designate and invoke the relevant
sets in their proper positions must be added to the front of
GeneralText character string
7.3. BilaterallyDefined - application/octet-
X.400 Body Part:
MIME Content-Type: Application/Octet-Stream (no parameters
Conversion Type: Byte
Comments
When mapping from MIME to X.400, if there are parameters present
the Content-Type: header field, the conversion fails since
BilaterallyDefined Body Part does not have any corresponding ASN.1
parameters
DISCUSSION: The parameters "name" "type" and "conversions"
advisory, but may in some cases give vital hints on the
handling of the file. The parameter "conversions" is not
defined, but it is expected that it will be useful, so we cannot
it and expect people to be satisfied
The parameter "padding" changes the interpretation of the last
of the data, and so cannot be deleted
An option is to prepend an IA5 body part that contains the
text; this will aid unmodified readers, and can probably be
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
in both 1988 and 1992 X.400. It is retained solely for
compatibility with 1984 systems. 1992 X.400 defines a File
Body Part to solve this problem (i.e. binary file transfer
email). The standard and its regional profiles are not solid
yet to exploit as a solution for this problem
7.4. ODA - application/
X.400 Body Part:
MIME Content-Type: application/
Conversion Type: Byte
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
MHS
An abbreviated version of its ASN.1 definition is
oda-body-part EXTENDED-BODY-PART-
PARAMETERS
DATA
::= id-et-
OdaBodyPartParameters ::= SET {
document-application-profile [0] OBJECT
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
parameter "profile" according to the table below
Profile OBJECT
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
parameter "class" according to the table
Alvestrand & Thompson [Page 14]
RFC 1494 X.400/MIME Body Equivalences August 1993
String
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
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
parameters are missing, the values for Q112 and formatted-
are used
It is an option for the gateway implementor to try to access
from inside the document, where they are defined
document-profile.document-characteristics.document-architecture-
document-profile.document-characteristics.document-application-
Gateways are NOT required to do this, since the document
characteristics are optional parameters. If a gateway does not,
simply uses the defaulting rules defined above
The OBJECT IDENTIFIERs for the document application profile and
ODA {2 8 0 0} must be added to the Encoded Information
parameter of the message envelope
7.5. g3-facsimile - image/g3
X.400 Body part: g3-
MIME Content-Type: image/g3
Conversion Type: nearly Byte
Comments
The Parameters of the X.400 G3Fax body part are mapped to
corresponding Parameters on the MIME Image/G3Fax body part and
versa. Note that
(1) If fineResolution is not specified, pixels will
twice as tall as they are
(2) If any bit not corresponding to a specially
Alvestrand & Thompson [Page 15]
RFC 1494 X.400/MIME Body Equivalences August 1993
option is set in the G3Fax NonBasicParameters,
"DCS" parameter must be used
(3) Interworking is not guaranteed if any bit apart
those specially named are used in
From X.400 to G3Fax, the body is created in the following way
(1) Any trailing EOL markers on each bitstring
removed. The bistring is padded to a byte boundary
(2) 6 consecutive EOL markers are appended to
bitstring
(3) The padded bitstrings are concatenated
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
of 6 consecutive EOL markers, and trailing EOLs
padding are
(2) Each bitstring is made into an ASN.1
(3) The bitstrings are made into an ASN.1 SEQUENCE,
forms the body of the G3Fax body part
7.6. application/postscript - postscript-body-
X.400 Body Part: Extended Body Part, OID postscript-body-
MIME Content-Type: application/
Conversion Type: Byte
7.7. application/jpeg - jpeg-body-
X.400 Body Part: Extended Body Part, OID jpeg-body-
MIME Content-Type: application/
Conversion Type: Byte
7.8. image/gif - gif-body-
X.400 Body Part: Extended Body Part, OID gif-body-
MIME Content-Type: application/
Conversion Type: Byte
Alvestrand & Thompson [Page 16]
RFC 1494 X.400/MIME Body Equivalences August 1993
8. OID
MIME-MHS-MAPPINGS DEFINITIONS ::=
mail, mime-mhs, mime-mhs-
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
To: IANA@isi.
Subject: Registration of new X.400/MIME content type
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
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
mime-mhs-bp-parameter. If it is not used, fill in
words NOT USED.)
X.400 ASN.1 Syntax
(must be an EXTENDED-BODY-PART-TYPE macro, or reference
a Basic body part type
Conversion algorithm
(must be defined completely enough for
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 "
Numbers" series of RFCs. The information in
registration form is freely distributable
10. Security
Security issues are not discussed in this memo
11. Authors'
Harald Tveit
SINTEF
N-7034
EMail: Harald.Alvestrand@delab.sintef.
Steven J.
Soft*Switch, Inc
640 Lee
Wayne, PA 19087
Phone: (215) 640-7556
EMail: sjt@gateway.ssw.
Alvestrand & Thompson [Page 18]
RFC 1494 X.400/MIME Body Equivalences August 1993
12.
[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
Consulting, Inc., Soft*Switch, Inc., August 1993.
[2] CCITT Recommendation X.420 (1988), Interpersonal
System
[3] Borenstein, N, and N. Freed, "MIME: Mechanisms for
and Describing the Format of Internet Message Bodies", RFC 1341,
Bellcore, Innosoft, June 1992.
[4] ISO 8613; Information Processing: Text and Office System;
Document Architecture (ODA) and Interchange Format (ODIF),
1-8, 1989.
[5] ISO/IEC International Standard 10021, Information technology -
Text Communication - Message-Oriented Text Interchange
(MOTIS) (Parts 1 to 8).
[6] CCITT Recommendation T.411 (1988), Open Document
(ODA) and Interchange Format, Introduction and
Principles
[7] Crocker, D., "Standard for the Format of ARPA Internet
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
Apparatus for Document Transmission (1988).
[10] CCITT Recommendation T.30, Procedures For Document
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",
1502, SINTEF DELAB, August 1993.
Alvestrand & Thompson [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
