Peculiar X.400 body parts

Some information about body parts have actually vanished from the standardization effort. This page is my attempt to track down references to some of them.

Some body parts are also things that will never occur in a standard; see the textstuff section for more info.

The Standard Profile for X.400, ISO/IEC ISP 12062-1:1995(E) lists the following body parts as "non-standard"; the [numbers] are the tag numbers they use in the ASN.1 encoding.

ISO6937Text

The ISO 6937 text body part was defined in the X.400 extension "MOTIS'86", which was dropped from the ISO standardization process at DIS level.

Its ASN.1 (from DIS 9065, courtesy of Andrew Gordon <Andrew.Gordon@net-tel.co.uk>; module extension mine):

iso6937BodyPart DEFINITIONS EXPLICIT TAGS ::=
BEGIN

BodyPart ::= CHOICE {
          [0] IMPLICIT ISO646Text,
          [1] IMPLICIT TLX,
          [2] IMPLICIT Voice,
          [3] IMPLICIT G3Fax,
          [4] IMPLICIT TIF0,
          [5] IMPLICIT TTX,
          [6] IMPLICIT Videotex,
          [7] NationallyDefined,
          [8] IMPLICIT Encrypted,
          [9] IMPLICIT ForwardedIPMessage,
          [10] IMPLICIT SFD,
          [11] IMPLICIT TIF1,
          [12] IMPLICIT ODA,
          [13] IMPLICIT ISO6937Text}

ISO6937Text ::= SEQUENCE {
  SET { repertoire [0] IMPLICIT INTEGER OPTIONAL
         -- default is full graphic repertoire -- },
  SEQUENCE OF ISO6937Line }
  -- the ISODE source claims that 3 means "teletexSubrepertoire" --

ISO6937Line ::= [0] IMPLICIT OCTET STRING

END  
(another copy was submitted by Paul Gover Warwick <paul_gover@uk.ibm.com>)

The textual description in the DIS reads:

An ISO6937Text body part contains a sequence of lines containing only graphic characters, encoded according to parts 1 and 2 of ISO 6937, together with an indication of which repertoires of such characters is in use. The value of repertoire is that allocated to the repertoire by the registration set up under ISO 6937. Annex B contains a list of known registrations.
(Annex B actually says "for further study"....)

ISO 6937 is a superset of the Teletex charset definition. It seems, according to Paul Gover, that sometimes an accent-backspace-character is used in place of the nonspacingaccent-character combinations used in Teletex.
BUT: Note that the ASN.1 TeletexString has mutated over the years, so that much that wasn't originally part of the Teletex character set is now allowed in a TeletexString!

Andrew Gordon notes that the phrase 'containing only graphic characters' means that the lines should definitely NOT contain CRLF. This also matches what most implementations have actually done!

Note: Steve Townsend <SteveTownsend@msn.com> reports that there is disagreement over the permitted length of lines in ISO6937 body parts; in particular, some Soft*Switch products demand and enforce a line length limit of 80 characters, which creates "interesting" results when you, for instance, try to send PostScript as ISO6937 text.

There is no trace of such a restriction in the draft standards themselves, but the X/Open spec for "API To Electronic Mail (X.400)" apparently imposes such a restriction.

US Nationally-defined

This in fact has an online reference; it is the NIST Stable Implementors' agreement (94), part 7.

Its ASN.1 is:

BodyPart                :: =  CHOICE { 
                                [0] IMPLICIT IA5Text,         
                                [1] IMPLICIT TLX,             
                                .                           
                                [234] IMPLICIT UKBodyParts, 
                                .                           
                                .                             
                                .                             
                                [310] IMPLICIT USABodyParts,  
                                .                             
                                .                             
                                .    }                        
-- Where UKBodyParts and USABodyParts are defined as:         
                             SEQUENCE { BodyPartNumber, ANY } 
BodyPartNumber          ::=  INTEGER                          

The surrounding text says to "Refer to clause 12.6 for recommendations regarding the implementaion of USABodyParts." Since there is no such clause number in the document, I assume that the reference should go to appendix B, that says in section 6:
It is recommended that UAs can generate any USA Body Part, as defined in clause 5.3.6.2, and that they can receive such body parts as well. reception of USA Body Parts does not imply further processing by the UA, but merely that the body part is made available, with a indication of its registered body part identifier, to another process or deposition in a file.
Generation implies the reverse of this process.
The agreements for 1988 X.400 have removed the reference to the UKBodyParts and renamed the ASN.1 to "USAPrivatelyDefinedBodyParts". The relevant text says:
These privately-defined body part types are specified as an interim measure to provide backward compatibility with 1984 MHS implementations. For interworking between UAs based on the 1988 (or later) MHS standards, it is strongly recommended that the externally-defined body part be used instead.
No information about its registration authority or index of assignments is found in the document; the one example I've seen seems to have number zero and contain an OCTET STRING (which was a WordPerfect document, but that seems irrelevant).

According to Andrew Gordon, the plan for national body parts was to use the X.121 country codes as tag numbers; the US one is believed to be the only one that has seen any usage at all. The UK never defined anything under the UK tag.

The ODA (1984) body part

From the NIST OIW agreements for 1988 X.400, Annex B, Figure B1:
           |   oda-1984                [12] IMPLICIT OCTET STRING,       |
           |                                                             |
           | The content of the ODA OCTET STRING will contain a value of |
           | type ODABodyPart as follows:                                |
           |                                                             |
           | ODABodyPart ::= SEQUENCE {                                  |
           |    ODABodyPartParameters,                                   |
           |    ODAData }                                                |
           |                                                             |
           | The Parameters and Data components are defined in Annex E   |
           | of CCITT Recommendation T.411 (1988) (ISO 8613-1).          |
           |                                                             |
According to Andrew Gordon:
The definitive version (referenced by ISP 12062-1) is in ISP 10610-1, Annex B (this is FOD11, the ODA simple character architectures profile).
Given that 10610-1 was only published in 1995, most people have actually worked from ENV 41 510. Fortunately, these two are identical. The text you have quoted from NIST is slightly different but produces the same encoding. Finally, there is also a definition of the ODA bodypart in MOTIS86 (DIS 9065), which uses the [12] tag but is *different* from the others; fortunately, I don't believe anybody implements this.

The official ASN.1 reads:

 OdaBodyPart ::= SEQUENCE { OdaBodyPartParameters, OdaData }
 OdaBodyPartParameters ::= SET {
   document-application-profile [0] IMPLICIT OBJECT IDENTIFIER,
   document-architecture-class [1] IMPLICIT INTEGER {
     formatted (0),
     processable (1),
     formatted-processable (2) }
 OdaData ::= SEQUENCE OF Interchange-Data-Element
It is recommended to transfer an ODA document as a single bodypart with tag 12:

 Oda [12] IMPLICIT OCTET STRING

The content of the octet string is encoded as OdaBodyPart, defined above.

Textual conventions in body parts

There are a number of things that are carried as IA5 body parts that are in fact other things.

The things I know about include:

The ISOCOR attachment

ISOCOR e-mail gateways will generate an additional attachment, called a manifest or a file transfer attachment. This attachment contains the information discarded by X.400 1984/8. The manifest attachment contains a separate line for each attachment sent, identifying: An example ISOCOR attachment manifest body part contains:
----------------------------------------------------
ATTACHMENT MANIFEST 1.0

=BP TYPE FILENAME      RENDER
1   NOTE
2   FILE attach02.doc  -1
=END
-----------------------------------------------------

Harald.T.Alvestrand@uninett.no
Last modified: Tue Jan 7 09:24:42 1997