RFC 1496

RFC 1496 💖 Rules for Downgrading Messages from X.400/88 to X.400/84 When MIME Content-Types are Present in the Messages

Okay bestie, here's the title block tea 🫶

• Series: Network Working Group
• Number: RFC 1496
• Updates: RFC 1328
• Obsoletes: none listed in the header
• Authors: H. Alvestrand (SINTEF DELAB), J. Romaguera (NetConsult AG), K. Jordan (Control Data Systems, Inc.)
• Category: IAB standards track protocol
• Date: August 1993

---

Status of this Memo ✨

So this one is an IAB standards track protocol for the Internet community 🌐 It's asking for discussion and suggestions for improvements. For the current standardization state and status, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 🦋

Table of Contents 🎀

1.  Introduction ...............................................    1
2.  Basic approach .............................................    2
3.  Conversion rules ...........................................    3
3.1  EBP conversions to Basic ..................................    3
3.2  Encapsulation format ......................................    3
4.  Implications ...............................................    4
5.  Security Considerations ....................................    4
6.  Authors' Addresses .........................................    4
7.  References .................................................    5

1. Introduction ✨

Okay so the way X.400(88) and MIME talk to each other is through [4] 💅 That one works alongside RFC-1327 [2], and RFC-1327 is the thing that handles X.400(88) and RFC-822 based mail.

X.400(88) and X.400 (84) get along thanks to RFC-1328 [3]. The catch is that RFC-1328 doesn't say what to do when body parts show up at the gateway that just can't be represented properly in the X.400(84) system 😭

So this document is the glow-up for RFC-1328 🌸 It explains how RFC-1328 has to be changed so it can actually handle these two scenarios:

SMTP(MIME) -> X.400(84)

X.400(84) -> SMTP(MIME)

It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is not obsoleted, so it's still around 🫶

NOTE: A desireable side-effect of HARPOON is that a standardized method for the identification and transmission of multimedia and binary data (like spreadsheets) between X.400/84 UAs is achieved. ✨

Ngl, this method isn't compatible with the current proprietary approaches. But we think it asks for fewer invasive changes to current UAs than other possible methods would 💜

This memo updates RFC 1328. HARPOON is a pure name and has no meaning 🙈 Send comments to the MIME-MHS mailing list <mime-mhs@surnet.nl>.

2. Basic approach 🦋

The plan is to pretend the connection X.400(84) <-> SMTP(MIME) never happens. Obviously it does, but this illusion is lowkey super useful 🔮

So all mail goes down one of these paths when it moves between a MIME user and an X.400(84) user:

     X.400(84) -> X.400(88) -> SMTP(MIME)

     SMTP(MIME) -> X.400(88) -> X.400(84)

At the boundary between X.400(88) and X.400(84), the rules are:

• Convert what you can
• Encapsulate what you have to
• Never drop a message

Of course, for X.400/88 body parts that X.400/84 already defines, you don't downgrade anything 💖 Multi-body messages stay multi-body, IA5 messages (including IA5 messages encoded as Extended Body Parts) stay IA5, and G3Fax messages stay G3Fax. No notes, just vibes ✨

3. Conversion rules 💅

3.1. EBP conversions to Basic

Some body parts in X.400(88) have both a Basic form and an Extended form. You can find them listed in Annex B of X.420 📚

For all of these, going from the Extended Body Part to the Basic Body Part means you put the PARAMETERS and the DATA members together in a SEQUENCE 🎀

The gateway should do this transformation so that X.400(88) systems using the Extended form of the IA5 body part can still talk to X.400(84) systems. Iconic behaviour 👑

3.2. Encapsulation format

If a body part can't be used directly in X.400(84), you make the following IA5Text body part 🧚

• Content = IA5String
• First bytes of content (the description is in USASCII, with C escape sequences used to represent control characters):

MIME-version: <version>\r\n
    Content-type: <the proper MIME content type>\r\n
  Content-transfer-encoding: <quoted-printable or base64>\r\n
  <Possibly other Content headings here, terminated by\r\n>
  \r\n

<Here follows the bytes of the content, as per [4], encoded in the
proper encoding>

Here's the important part 😭 All implementations MUST place the MIME-version: header first in the body part. Headers that are placed by [2] and [4] into other parts of the message MUST NOT be placed in the MIME body part 🚫

This also covers RFC-822 headings carried as heading-extensions. Those must be placed in a new IA5 body part that starts with the string "RFC-822-HEADERS", as specified in [2], Appendix G 🌈

Other heading-extensions are still handled the way chapter 5 of RFC 1328 describes: they get dropped 🗑️

Since all X.400(88) body parts can be represented in MIME by using the x400-bp MIME content-type, this conversion will never fail. Literally unbreakable 💪

Going the other way, any IA5 body part that starts with the token "MIME-Version:" gets converted according to [4] before it goes into an X.400(88) message 💜

4. Implications ✨

There are a few. Here's the tea:

• People with X.400(84) readers that can save messages to a file will now be able to save MIME multimedia messages 📁
• People who can use features like the "Mailcaps" file to figure out what to do with a bodypart can now grab MIME implementations that run as subprograms and get at least some multimedia functionality 🎞️

5. Security Considerations 🔥

The security considerations in [1] and [4] are now relevant for X.400(84) systems too. Beware of trojans that can hit you if your UA automagically starts programs for you! 💀

6. Authors' Addresses 🫶

Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY

EMail: Harald.T.Alvestrand@delab.sintef.no


Kevin E. Jordan, ARH215
Control Data Systems, Inc.
4201 Lexington Avenue N
Arden Hills, MN  55126
USA

EMail: Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com


James A. Romaguera
NetConsult AG
Mettlendwaldweg 20a
3037 Herrenschwanden
Switzerland

EMail: Romaguera@netconsult.ch

7. References 📚

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

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

[3]  Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading", RFC
     1328, University College London, May 1992.

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