Re: RFC-1148/2: Why not support RFC-822 extensions?

Thread View: comp.protocols.iso.x400.gateway

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Steve Kille Tue, 26 Feb 1991 15:20

#122

Author: Steve Kille
Date: Tue, 26 Feb 1991 15:20

26 lines
1551 bytes

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

Re: RFC-1148/2: Why not support RFC-822 extensions?

#125

Author: harald.alvestrand
Date: Wed, 27 Feb 1991 09:15

34 lines
2035 bytes

Steve, one total miss: I referred to RFC 1158. I should have said 1154.
So much for not checking my numbers before posting.

To your point: You claim that RFC 1154 (I think you understood me!) does not
cover X.400/88 extensibility.
I quote:

> 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.

Given that you can have a header saying

Content: 1123 X400 3/4

meaning that there is a single body part consisting of 1123 lines of 3/4
encoding,
giving the complete ASN.1 encoding of the body part (section 4.6 of RFC 1154),
and that any X.400/88 extended body part may be uniquely identified by its
encoding bytes, which include the object identifier identifying it, I fail to
see the reason why it should not be possible to handle all bodies.
As for header extensibility, I thought 1148 was *supposed* to cover that :-)

I have also read 934 (thanks for the tip!) and fail to see how it can be used
for identifying body parts or their encoding. It separates them, yes,
and covers
the case for forwarded IP-messages with IA5 body parts, but how does it cover
anything except IA5?

Still looking for clarification....

                   Harald Tveit Alvestrand
Harald.Alvestrand@elab-runit.sintef.no
C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald
+47 7 59 70 94

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads