Re: rfc1495
Ned Freed <NED@sigurd.innosoft.com> Wed, 04 May 1994 23:52 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17879; 4 May 94 19:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17875; 4 May 94 19:52 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa24609; 4 May 94 19:52 EDT
Received: from SIGURD.INNOSOFT.COM by survis.surfnet.nl with SMTP (PP) id <06178-0@survis.surfnet.nl>; Thu, 5 May 1994 01:40:38 +0200
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HBXTVFLCF48Y4ZG7@SIGURD.INNOSOFT.COM>; Wed, 4 May 1994 16:40:30 PDT
Date: Wed, 04 May 1994 16:38:24 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: rfc1495
In-reply-to: Your message dated "Wed, 04 May 1994 17:47:17 +0200" <199405041547.AA01784@chandon.inria.fr>
To: Justin Ziegler <Justin.Ziegler@inria.fr>
Cc: mime-mhs@surfnet.nl, ziegler@chandon.inria.fr
Message-id: <01HBY569PNDG8Y4ZG7@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
> I am still studying all the rfcs about gatewaying MIME and X400. > In particular section 3.2.1.2 of rfc1495 has kept my attention. > ------------ > 3.2.1.2. Message/Partial > This is mapped onto a *message*, and the following heading extension is > used. The extension is derived from the message/partial parameters: > partial-message HEADING-EXTENSION > VALUE PartialMessage > ::= id-hex-partial-message > PartialMessage ::= > SEQUENCE { > number INTEGER, > total INTEGER, > id IA5String > } > If this heading is present when mapping from MHS to MIME, then a > message/partial should be generated. > ------------ In practice I've found that the only viable approach is to reassemble message/partial objects before passing them off to X.400. However, I think we still need to provide for a means of carrying them in the X.400 world. > I guess the word message between stars refers to an > IPMS.messageBodyPart. But an IPMS.messageBodyPart has a structure, > and is a sequence of IPMS.BodyParts. The message broken > into message/partials may also have a structure. > Thus the partial message must > be broken into BodyParts if it contains a multipart body. > The parsing can not be applied separatly to the parts of the > broken message. The only > possible solution is that the gateway receives all the parts and > reassembles them. But a gateway can not be expected to receive all > the parts, some of them may be sent to other gateways... I admit I read this as "map onto a part" rather than message, and I agree that mapping onto a message makes no sense. > I feel this creates a few problems, that need a bit more > consideration. Has this already been solved and discussed ?? See above. Ned
- Re: rfc1495 Harald T. Alvestrand
- rfc1495 Justin Ziegler
- Re: rfc1495 Ned Freed
- Re: rfc1495 Harald T. Alvestrand
- Re: rfc1495 John Haxby
- Re: rfc1495 Justin Ziegler
- Re: rfc1495 Carl S. Gutekunst
- Re: rfc1495 Ned Freed
- Re: rfc1495 Keith Moore