in the message envelope's Encoded Information Types by looking up the
ISO IR numbers in the above table, and then appending each to the
id-cs-eit-authority {1 0 10021 7 1 0} OID, generating 2-4 OIDs.
Similar procedures can be used with other MIME charsets that map to a
set of ISO character sets.
The escape sequences to designate and invoke the relevant character
sets in their proper positions must be added to the front of the
GeneralText character string.
For ISO 8859-1, the relevant escape sequence will be:
ESC 28 42
ASCII in G0
ESC 2D 41
ISO-IR-100 in G1
ESC 21 41
High control character set in C1
ESC 7E
Locking shift 1 Right
These escape sequences are removed when converting from GeneralText
to text/plain.
Note that new character sets may be defined on both the Internet side
and the X.400 side; a gateway MAY choose to implement more
conversions in the same fashion.
DISCUSSION:
The conversion of text is a problematic one, and one in which it is
likely that gateways should be given wide latitude to make decisions
based upon their knowledge of the user's preferences. The text given
below is thought to give the best approximation to a gateway
conforming to current and anticipated usage in the MIME and X.400
worlds, and is the way recommended when no knowledge of the
recipient's capabilities exists.
The lossless changes, such as normalizing escape sequences, can be
done even when "conversion-prohibited" is set. If "conversion-with-
loss-prohibited" is set, translation to a character set that is not
able to encode all characters cannot be done, and the message should
be non-delivered with an appropriate non-delivery reason.
The common use of character sets in MIME is somewhat different from
the rules given by X.400; in particular, it is common in MIME to
assume that the character sets follow strict rules. For the ISO-
8859-x character sets, it is assumed that they are designated and
invoked at the beginning of the text, and that no designation or
invocation sequences occur within the body of the text.
The rules for ISO-2022-JP are given in RFC1468 [2022-JP], and are
even more particular, using a pure 7-bit encoding in which each line
of text starts in ASCII.
Therefore, the text must be "normalized" by going through the whole
message, using a state machine or similar device to remove or rewrite
all escape and shift sequences.
Appendix A gives pseudocode for such a conversion.
NOTE: In 1988, the GeneralText body part was defined in ISO 10021-8
[MOTIS], and NOT in the corresponding CCITT recommendation; this was
added later. Also, the parameters have been heavily modified; they
should be a SET OF INTEGER in the currently valid text. Use the
latest version of the standard that you can get hold of.
6.3. BilaterallyDefined - application/octet-stream
X.400 Body Part: BilaterallyDefined
MIME Content-Type: Application/Octet-Stream (no parameters)
Conversion Type: No conversion
When mapping from MIME to X.400, if there are parameters present in
the Content-Type: header field, they are removed.
DISCUSSION:
The parameters "name" "type" and "conversions" are advisory; name and
conversions are depreciated in RFC2046.
The parameter "padding" changes the interpretation of the last byte
of the data, but it is deemed better by the WG to delete this
information than to non-deliver the body part. The "padding"
parameter is rarely used with MIME.
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, and because it is in common use.
6.4. FTBP EMA Unknown Attachment - application/octet-stream
X.400 Body Part: FTBP EMA Unknown Attachment
MIME Content-Type: Application/Octet-Stream
Conversion Type: No conversion
The OID for the Unknown Attachment is { joint-iso-ccitt(2)
country(16) us(840) organization(1) ema(113694) objects(2)
messaging(2) attachments(1) unknown(1) }, or
2.16.840.1.113694.2.2.1.1 for short.
NOTE: Previous EMA drafts gave it as { iso(1) countries(2) usa(840)
organization (1) ema (113694) objects(2) messaging(2) attachments(1)
unknown (1)}, or 1.2.840.1.113694.2.2.1.1 for short.
The parameters for this type must be mapped according to chapter 2.3,
with the following extensions for the parameters of the
application/octet-stream:
If there is no Content-Disposition parameter with a filename, and
there is a name parameter, the FTBP.FileTransferParameters.File-
attributes.pathname is generated from this parameter. Note that
RFC2046 recommends not using the "name" parameter.
The "type", "conversions" and "padding" attributes are ignored;
"type" is for human consumption; "conversions" are discouraged in RFC
2046.
The body mapping is just copying the bytes in both directions.
6.5. MessageBodyPart - message/RFC822
X.400 body part: MessageBodyPart
MIME Content-Type: message/RFC822
Conversion Type: Special
NOTE: If the headers of the X.400 MessageBodyPart contains the
"multipart-message" heading extension with the isAMessage bit set
(either explicitly or implicitly), the mapping should be to
multipart/* according to section 6.6, below.
To map an IPMS.MessageBodyPart, the full X.400 -> RFC822 mapping is
recursively applied, to generate an RFC822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope is used for the MTS
Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time is mapped to the
extended RFC822 field "Delivery-Date:".
When a message/RFC822 is contained within a MIME message, it is
mapped to an IPMS.MessageBodyPart according to MIXER. specification.
Any mappings that would have been made to the MTS Abstract Service
are placed in IPMS.MessageBodyPart.parameters.delivery-envelope.
6.6. MessageBodyPart - multipart/*
X.400 body part: MessageBodyPart
MIME Content-Type: multipart/*
Conversion Type: Special
NOTE: If the headers of the X.400 MessageBodyPart do not contain the
"multipart-message" heading extension with the "isAMessage" flag
FALSE=, the mapping should be to message/RFC822.
A MIME multipart is a set of content-types and not a message with a
set of content types. When the multipart is at the outermost MIME
header, elements of the multipart are mapped directly onto
IPMS.Bodypart.
When the MIME multipart is not at the outermost level, it is mapped
to an IPMS.MessageBodyPart containing an IPMS.Bodypart for each
element of the multipart.
When a nested IPMS.Message is generated from a multipart, an
IPMS.heading shall always be generated. The only mandatory field is
the IPMS.Heading.this-IPM message id, which shall be generated by the
gateway. An IPMS.Heading.subject field shall also be generated, in
order to provide useful information to non-MIME capable X.400(88) UAs
and to all X.400(84) UAs. The subject field is set as follows
according to the multipart subtype:
mixed:
"Multipart Message"
alternative:
"Alternative Body Parts containing the same information"
digest:
"Message Digest"
parallel:
"Body Parts interpreted in parallel"
other:
"Multipart Message (<subtype>)"
For other types of multipart, the multipart subtype shall be included
in the subject line.
For each multipart, the following IPMS.HeadingExtension shall be
generated, with the value set according to the subtype.
If the multipart is the outermost multipart, and the subtype is
"mixed", it may be omitted.
multipart-message HEADING-EXTENSION
VALUE MultipartType
::= id-hex-multipart-message-v2
MultipartType ::= SEQUENCE {
subtype IA5String,
isAMessage BOOLEAN DEFAULT TRUE }
The MultipartType contains the subtype, for example "digest". If
this heading is present when mapping from X.400 to MIME, the
appropriate multipart may be generated.
The isAMessage flag is needed because of the case where a message
contains a ForwardedIPMessage, which itself was generated from a MIME
message that was a Multipart; it is set whenever the multipart is the
outermost level of nesting inside a Message/RFC822.
NOTE:
When downgrading to X.400/84, the content-type SHOULD be
regenerated from this heading-extension and put into the RFC-822-
HEADERS extra body part.
NOTE:
This definition is different from the one in RFC1494, because the
RFC1494 definition turned out to be insufficient when new
subtypes of Multipart (like Signed or Related) were defined. That
is the reason for the "-v2" part of the name of the OID.
If both the old and the new heading extensions occur on a message,
a MIXER gateway should give preference to the new one.
6.7. Teletex - Text/Plain (Teletex)
X.400 Body Part: Teletex
MIME Content-Type: text/plain; charset=Teletex
Conversion Type: Text conversion
From X.400 to RFC-822, the conversion shall take the bytes
of all the pages in the "data" part of the
TeletexBodyPart, add a FF character (0x0C, control-L) to
each part that does not already end in one, and
concatenate them together to form the body of the
Text/Plain.
The character set shall be "Teletex", which is especially
registered for this purpose. Its definition is shown in an
appendix.
The parameters are discarded.
From RFC-822 to X.400, the conversion shall split the
content at each occurrence of the FF character (0x0C),
delete the character and construct the Teletex body part
as a SEQUENCE OF TeletexString, as described in X.420(88),
section 7.3.5
The TeletexParameters may, but need not, contain the
number-of-pages component.
NOTE: It is recommended, but not mandated, that the data
be converted into a more widespread character set like
ISO-8859-1 or ISO-2022-JP (if applicable) if possible.
This will result in the reverse translation giving a
GeneralText body part, which will have to be dealt with
appropriately at the X.400/88 to X.400/84 downgrading
boundary, if possible, but will give a much greater chance
that the MIME recipient can actually read the message.
DISCUSSION:
The Teletex body part is frequently used in X.400(84) to
send around text with slightly extended character sets
beyond ASCII.
Its body consists of a series of "pages", separated by
ASN.1 representation. It is important to many people to
have this mapped into something that is readable to most
end-users; therefore, it is recommended to map this onto
Text/Plain; however, since this is not plain text, the
conversion must be specified.
Note that the definition of Text/Plain permits only CRLF as a line
separator; the sequences "CR FF" and "CR LF LF LF.." permitted in
Teletex must be encoded as Quoted-Printable.
7. Body parts where encapsulation is recommended
Some body parts are MIME constructs, and their functionality will be
severely damaged if they are coerced into an X.400 framework.
Special care needs to be taken with these; they are described below.
7.1. message/external-body
The gateway MUST support the encapsulation of this body part using
the HARPOON encapsulation (IA5).
It MAY support some kind of retrieval of the referred object.
DISCUSSION:
The message/external-body part points to an object that can be
retrieved using Internet protocols.
There are three cases to consider for the recipient's capabilities:
(1) The user has no Internet access. In this case, the
user might be grateful if the gateway fetches the body part and
inserts it into the message. If the body part is large or
dynamic, it might not be appropriate.
(2) The user has Internet access, but no UA support for
fetching external-body objects.
(3) The user has Internet access and UA support for
fetching external-body objects, based on an understanding of
this document.
Some access-types, like anonymous FTP, are easy to resolve. Others,
like the Mailserver access-type, are almost impossible to resolve at
a gateway.
To support the second case above, the tunneling method chosen is the
HARPOON encapsulation described in section 3.1.3, using an IA5 body
part, inserting the string "MIME-Version: 1.0 (generated by gateway)"
at the beginning of the body part. (The part in parentheses can be
changed at will).
This will:
(1) Maximize the chance that the user will see the
message
(2) Give the user hints that will enable him to fetch
the message using other Internet tools
(3) Identify the message as a MIME object in a reliable
fashion, allowing UAs to support the fetching of the object if
the UA implementor desires.
7.2. message/partial
This represents part of a larger message, where it is only possible
to parse the complete message after getting all the pieces.
The gateway MUST support the encapsulation of this body part.
It MAY implement transparent reassembly of the message, but in this
case, it MUST support a configurable timeout
for the reassembly, defaulting back to encapsulation.
DISCUSSION:
The gateway's choices are:
(1) Wait until all the pieces arrive at the gateway,
reassemble the message, and use normal processing
(2) Encapsulate the message, using any encapsulation
method (BP15, FTAM or HARPOON).
In some cases, not all pieces will arrive at the gateway; some may
have been transferred through other gateways due to route changes or
machine outages; some may have been lost in transit.
7.3. multipart/signed
A gateway MUST implement encapsulation of multipart/signed using
HARPOON.
The gateway MAY be configured to do other processing, as outlined in
the discussion below. This is outside the scope of the standard.
DISCUSSION:
Gatewaying security is a problem. The gateway can basically take
three approaches:
- Strip the multipart/signed, leaving the bare body
part unsecured, possibly with a comment that the signature was
stripped
- Attempt to check the signature and re-signing the
message using X.400 security functions, then stripping as above
- Encapsulate the message. This is the only approach
that allows end to end security, but requires MIME functionality
at the recipient.
- Replace the message content with multiple body parts,
containing first an unsecured body part and then the
encapsulated multipart/signed.
All these are valid options for a MIXER gateway.
Note that the encapsulation must use HARPOON, as the signature is
computed on the ENCODED body part, not on the canonical
representation, and HARPOON is the only encapsulation that preserves
the content transfer encoding of the message.
Note also that all methods except for encapsulation break end-to-end
security; the recipient can place no more trust in the integrity of
the message than he can place in the security of the gateway.
7.4. multipart/encrypted
A gateway MUST implement encapsulation of multipart/encrypted using
HARPOON.
If the implementor chooses to allow other processing at the gateway,
as outlined below, he/she is advised that there are grave security
concerns with such a solution, since it violates the general rule of
keeping decryption keys as close to the user as possible.
DISCUSSION:
There are two basic cases for a gateway:
- The gateway is trusted with the user's keys. In this
case, the gateway can decrypt the message, possibly add a note
that it has done so, and gateway the unencrypted form, possibly
applying X.400 security functions, and possibly attaching a copy
of the original, encrypted material for reference. This does
nothing to protect the transfer from gateway to recipient,
unless suitable X.400-native security is applied. It also means
that the gateway must be part of the user's trusted environment.
- The gateway is not trusted with the recipient's keys.
In this case, encapsulation is the only approach that preserves
any information at all.
The valid options for a MIXER gateway are therefore:
- Decrypt the body part
- Encapsulate the body part
- Drop the body part
The MIXER WG has shown strong preference for the encapsulation
alternative, and urges anyone who thinks of buying or implementing
gateway decryption to carefully evaluate this choice in light of the
company's general security policy.
8. Conformance requirements
In order to be called MIXER conformant, a gateway must implement:
- Encapsulation of MIME content in the FTBP body part
- Encapsulation of X.400 body parts in the x400-bp body
part
- Encapsulation of FTBP body parts in the
application/x-ftbp.oid body part
- Encapsulation of security multiparts using HARPOON
- Text/plain <-> IA5Text
- Text/plain; charset=iso-8859-* <-> GeneralText
- Multipart/* <-> ForwardedIPMessage
- message/RFC822 <-> ForwardedIPMessage
- application/octet-stream <-> FTBP unknown
- application/octet-stream <-> BilaterallyDefined
- A configuration choice of which application/octet-
stream translation to use
All other parts of this specification MAY be implemented by the
gateway. If they are implemented at all, they MUST be implemented
conformant to this specification.
In this context, a feature is "implemented" in a product if it is
possible to configure the product in such a way that this feature is
used. This specification does not restrict the product to only be
configured in such a fashion.
9. Security Considerations
The security issues identified in this memo are:
(1) Security implications of using filenames that
arrive in body part headers (section 2.3.2)
(2) Security implications of letting a gateway handle
encrypted and/or signed content (section 7.3 and 7.4)
If a gateway fetches message/external-body on behalf of the
recipient, as described in section 7.1, it may be tricked into
performing inappropriate actions by malicious senders.
In addition, all the normal caveats that apply to sending data that
may contain executable code apply to UAs on both sides of the
gateway.
10. Author's Address
Harald Tveit Alvestrand
UNINETT
P.O.box 6883 Elgeseter
N-7002 Trondheim
NORWAY
EMail: Harald.T.Alvestrand@uninett.no
11. Acknowledgements
The author wishes to thank all the members of the MIXER WG for their
valuable input, and in particular (in no particular order):
Steve Kille, Peter Sylvester, Ned Freed, Julian Onions, Ruth Moulton,
Keith Moore, Alain Zahm, Urs Eppenberger, Kevin Jordan, Jeroen
Houttuin, Claudio Allocchio, Colin Robbins, Steven Thomson, Jim
Craigie, Efifiom Edem, David Wilson, and many others who have been
active over the long lifetime of this document.
References
[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, August, 1982.
[MIME]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046, November
1996.
[MIME-HDR]
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC2047,
November 1996.
[HARPOON]
Alvestrand, H., Romaguera, J., and K. Jordan, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", RFC1496, August
1993.
[MIMETRANS]
Vaudreuil, G., "Transition of Internet Mail from Just-Send-8 to
8Bit-SMTP/MIME", RFC1428, February 1993.
[MIXER]
Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC-822",
RFC1327, May 1992.
[T.4]
CCITT Recommendation T.4, Standardization of Group 3 Facsimile
Apparatus for Document Transmission (1988)
[T.30]
CCITT Recommendation T.30, Procedures For Document Facsimile
Transmission in the General Switched Telephone Network (1988)
[T.411]
CCITT Recommendation T.411 (1988), Open Document Architecture
(ODA) and Interchange Format, Introduction and General Principles
[MOTIS]
ISO/IEC International Standard 10021, Information technology -
Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) (Parts 1 to 8)
[X.400]
CCITT, Data Communication Networks - Message Handling Systems -
Recommendations X.400 - X.420 (1988 version)
[X.420]
CCITT Recommendation X.420 (1988), Interpersonal Messaging System
[RFC-X400USE]
Alvestrand, H., "X.400 use of extended Character Sets", RFC1502,
August 1993.
[MAWG]
Electronic Messaging Association Message Attachment Working Group
(MAWG): File Transfer Body Part Feasibility Project Guide -
version 1.5 - September 1995
[CDISP]
Troost, R., and S. Dorner, "Communicating Presentation Information
in Internet Messages: The Content-Disposition Header", RFC1806,
June 1995.
[POSTSCRIPT]
Alvestrand, H., "Carrying PostScript in X.400 and MIME", RFC2160,
June 1997.
[IMAGES]
Alvestrand, H., "X.400 Image Body Parts", RFC2158, June 1997.
[ODA]
Alvestrand, H., "A MIME Body Part for ODA", RFC2161, June 1997.
[ISO 2022]
ISO/IEC 2022:1994(E): Information technology - Character code
structure and extension techniques
[ISO 8859]
ISO 8859: Information processing -- 8-bit single-byte coded
graphic character sets (various parts)
[2022-JP]
Murai, J., Crispin, M., and E. van der Poel, "Japanese Character
Encoding for Internet Messages", RFC1468, June 1993.
[MUST]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March 1997.
APPENDIXES
Appendix A: Escape code normalization
The algorithm given here in pseudocode will reduce a GeneralString
ISO-2022 unlimited use of shifts sequence to a pure 8-bit sequence
that does not use shift sequences, if possible.
Some error conditions, like EOF, are not tested for. It crashes if
asked to do something it cannot. Control character set switching is
missing.
A similar routine, albeit more complex, can be written for
normalizing to the ISO-2022-JP character set.
BEGIN: (from X.209)
g0 = 6 (should be 2, but ignore the difference)
g1 = NULL
g2 = NULL
g3 = NULL
c0 = 1 (ASCII control)
c1 = NULL
leftset = &g0 (current input set, low)
rightset = &g1 (current input set, high)
lowset = 6 (output set, low)
highset = NULL (output set, high)
charset = US-ASCII
(Init for the set tables)
chartoid[{2D,2E,2F}, 41] = 100
.....
idtoname[100] = "ISO-8859-1"
.....
WHILE (more data)
CASE head of input
{These are the locking shift sequences}
INCASE "00/14": (LS0, SO)
leftset = &g0;
INCASE "00/15": (LS1, SI)
leftset = &g
INCASE "ESC 07/14": (LS1R)
rightset = &g1;
INCASE "ESC 07/13": (LS2R)
rightset = &g2;
INCASE "ESC 07/12": (LS3R)
rightset = &g3;
{There is missing code for handling the single shift function}
{These are the changes of graphic character sets}
{Note that G0 can contain only 94-character charsets}
INCASE "ESC 28"
g0 = chartoid[lastchar, next character]
sethiset(g0)
INCASE "ESC 2D", "ESC 29"
g1 = chartoid[lastchar, next character]
sethiset(g1)
INCASE "ESC 2E", "ESC 2A"
g2 = chartoid[lastchar, next character]
sethiset(g2)
INCASE "ESC 2F", "ESC 2B"
g3 = chartoid[lastchar, next character]
sethiset(g3)
{control characters. There is missing code for changing these}
INCASE 00/00-01/15 {normal control}
write(char)
INCASE 08/00-09/15 {upper control}
write(char)
{Normal characters}
INCASE 02/00-07/15 (Left)
IF (*leftset == lowset)
write(char)
ELSIF (*leftset == highset)
write(char+80)
ELSE
ERROR "Shift error"
ENDIF
INCASE 10/00-15/15
IF (*rightset == highset)
write(char)
ELSIF (*rightset == lowset)
write(char-80)
ELSE
ERROR "Shift error"
ENDIF
ENDCASE
ENDWHILE
SUBROUTINE sethighset(g1)
IF (highset == NULL)
charset = idtoname[g1]
highset = g1
ELSIF (highset == g1)
(it's OK)
ELSE
ERROR "Too many charsets encountered"
ENDIF
ENDROUTINE
Appendix B: OID Assignments
MIXER-MAPPINGS DEFINITIONS ::= BEGIN
EXPORTS -- everything --;
IMPORTS
mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) }
FROM MIXER --Companion RFC--;
mixer-headings OBJECT IDENTIFIER ::=
{ mixer 1 } -- called mime-mhs-headings in RFC1495 --
mixer-bodies OBJECT IDENTIFIER ::=
{ mixer 2 } -- called mime-mhs-bodies in RFC1495 --
-- mixer-core is defined as { mixer core(3) } in [MIXER]
mixer-bp-data OBJECT IDENTIFIER ::=
{ mixer-bodies 1 }; -- called mime-mhs-bp-data in RFC1494 --
mixer-bp-parameter OBJECT IDENTIFIER ::=
{ mixer-bodies 2 };
id-mime-bp-data OBJECT IDENTIFIER ::=
{ mixer-bp-data 1 };
-- for debugging: mixer-bp-data is 1.3.6.1.7.1.2.1.1
id-mime-bp-parameters OBJECT IDENTIFIER ::=
{ mixer-bp-parameter 1 };
-- the following assignments were done in RFC1494, using
-- slightly different names, but the same numbers.
-- their defining text is now is now in other documents
id-mime-postscript-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 2 }
id-mime-jpeg-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 3 }
id-mime-gif-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 4 }
-- This is a new definition, and defines an FTAM application
reference,
-- not a BP15 data OID.
id-mime-ftbp-data OBJECT IDENTIFIER ::=
{ mixer-bp-data 5 }
-- The following heading extensions are defined
id-hex-partial-message OBJECT IDENTIFIER ::=
{ mixer-headings 1 }
id-hex-multipart-message OBJECT IDENTIFIER ::=
{ mixer-headings 2 } -- from RFC1495; obsolete
id-hex-multipart-message-v2 OBJECT IDENTIFIER ::=
{ mixer-headings 3 }
END
Appendix C: Registration information for the Teletex
character set
The Teletex character set is a character set in which the ISO 2022
character set switching mechanism may be used to switch between the
following registered ISO character sets:
ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set
ISO-IR-102 - a fairly standard US-ASCII variant
ISO-IR-103 - Latin characters using non-spacing accents
ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more.
ISO-IR-107 - Control characters for C1 use
Its intended use of this character set is to represent data that
comes from ISO protocols that use the ASN.1 construct "TeletexString"
or "T61string" without conversion.
The set of allowed character sets can be found in CCITT
recommendation X.208(1988), chapter 31.2 and Table 6/X.208.
The rules for encoding the data type can be found in CCITT
recommendation X.209(1988), chapter 23. It states that at the
beginning of the string, G0 is always ISO-IR-102, C0 is ISO-IR-106,
and C1 is ISO-IR-107.
The specification seems somehow to have missed the implicit
assumption that ISO-IR-103 is designated and invoked as G1 and
shifted into the upper half of the character set which seems to be
assumed at least by the X.400 and X.500 software that uses
TeletexStrings; implementors should act as if the sequence ESC 2/9
7/6 LS1R is always present at the beginning of the data; however,
when generating Teletex strings, implementors should include the
sequence ESC 2/9 7/6 within the string before the first occurence of
a character from ISO-IR-103.
The rules for interpreting T.61 data are found (I believe) in CCITT
recommendations T.51, T.52 and T.53 (data from the ITU WWW server):
T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93]
Latin based coded character sets for telematic services
T.52 (1993) [New] [88 pp.] [Publ.: Apr.94]
Non-Latin coded character sets for telematic services
T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95]
Character coded control functions for telematic services
The Teletex character set is closely related to (but not identical
with) that specified in ISO 6937.
No further restrictions are imposed by this registration; in
particular, character set switching can occur anywhere, and there is
no guarantee that the character sets will be switched "back" at the
end.
Appendix D: IANA Registration form for new mappings
To: IANA@isi.edu
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:
IF BP15:
- X.400 Object Identifier for Data:
(If left empty, an OID will be assigned by IANA under mixer-bp-data)
- X.400 Object Identifier for Parameters:
(If left empty, an OID will be assigned by IANA under mixer-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)
IF FTBP:
- FTAM Object Identifier for application-reference:
- FTAM Object Identifier for contents-type:
(if left empty, unstructured-binary is assumed)
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.
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.