Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jarthur!ucivax!gateway
From: harald.alvestrand@elab-runit.sintef.no
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Re: RFC-1148/2: Why not support RFC-822 extensions?
Message-ID: <1991Feb27.075414.23646@ugle.unit.no>
Date: 27 Feb 91 09:15:33 GMT
References: <1709.667580940@UK.AC.UCL.CS>
Reply-To: harald.alvestrand@elab-runit.sintef.no
Organization: ELAB-RUNIT, SINTEF, Norway
Lines: 34
Approved: usenet@ICS.UCI.EDU
x-attn: jns
ReSent-From: Jerry Sweet <ifip-gtwy-request@ICS.UCI.EDU>
ReSent-To: ifip-gtwy@ICS.UCI.EDU

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