Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!gateway
From: S.Kille@cs.ucl.ac.UK (Steve Kille)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Re: RFC-1148/2: Why not support RFC-822 extensions?
Message-ID: <1709.667580940@UK.AC.UCL.CS>
Date: 26 Feb 91 15:20:13 GMT
Lines: 26
Approved: usenet@ICS.UCI.EDU
In-reply-to: Your message of 26 Feb 91 12:16:35 +0000. <1991Feb26.085844.2810@ugle.unit.no>
Phone: +44-71-380-7294

The key point of 1148 was to preserve service, not to add function to 822.

Reversible encoding of DRs.   I don't think that this is worth the effort
(987 DRs were more easily reversible.   In 1148, based on experience,
we shifted to a more user-oriented representation).  This is only critical
when 822 is used to interconnect X.400 systems.  This is not so common.


MMM extensions of RFC 822.   I do not want to put this into 1148.
If it is really needed in the 822 world, this should be defined as an RFC.
RFC 1148bis will referene the most appropriate RFC for encapsulating messages
and encoded body parts.   Currently this is RFC 934.

Thus, I am happy to see this work - just that 1148 is not the right place
for it.

RFC 1158 is not, as it stands, as suitable.  It does not map all of the
X.400 functionality (esp. 88 extensibility).   934 is more portable.

The IETF-SMTP group is currently disucssing extensions of 822 to support
Multimedia messages.  I hope that they will carefully addres the issue of
X.400 compatability.



Steve