Re: rfc1495 & mime-body-part
Ned Freed <NED@sigurd.innosoft.com> Fri, 03 June 1994 22:54 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13196; 3 Jun 94 18:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13192; 3 Jun 94 18:54 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa21069; 3 Jun 94 18:54 EDT
Received: from SIGURD.INNOSOFT.COM by survis.surfnet.nl with SMTP (PP) id <29922-0@survis.surfnet.nl>; Sat, 4 Jun 1994 00:44:15 +0200
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HD3WH4MGK096W42K@SIGURD.INNOSOFT.COM>; ) id <Fri, 3 Jun 1994 15:43:44 PDT
Date: Fri, 03 Jun 1994 15:06:17 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: rfc1495 & mime-body-part
In-reply-to: Your message dated "Thu, 02 Jun 1994 09:43:18 +0200" <"survis.sur.104:02.05.94.07.44.04"@surfnet.nl>
To: "Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no>
Cc: Justin Ziegler <Justin.Ziegler@inria.fr>, mime-mhs@surfnet.nl
Message-id: <01HD3ZX808H096W42K@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
> this is a real headache. > I would dearly love to keep those headers, and it will > harm interoperability that they are lost, but > *where can I put them?????* I believe the FTBP solves part of this problem for us. Specifically, along with all the other nonsense in a FTBP, there's this wonderful little field in the FileTransferParameters section: extensions [5] ExtensionsField DEFAULT {} Now, an ExtensionsField is exactly the same sort of field that appears at the P2 level and that RFC1327 uses to carry miscellaneous RFC822 headers that cannot be mapped into X.400 equivalents. This field is an ideal place to put MIME headers with comparable mapping semantics (that is to say, they don't map at all). > When I define the bodypart (like the mime-tunnel one), the > answer is simple: Create a parameter for them. Now that I've come to grips with the FTBP stuff, I don't think this is the right approach any more. I think it is better to define an FTBP equivalent and use the ExtensionsField capabilities for FTBP instead. I see big advantages to the FTBP approach. First of all, if we define a new BP15 for each and every MIME type, we have a never-ending battle with getting support for all this stuff into X.400 systems all over the place. If we use FTBP instead, however, we can always access this field regardless of whether or not we recognize the application reference for the object. > When there is only one bodypart in a message, the answer > is simple too: Put them in the RFC-822-Headers extension. > But when I have (for instance) multipart Text/Plain, which > gateways into multiple GeneralText parts, there > is *no place* where I can put them that I can see. > Any suggestion? This is the one case that FTBP doesn't handle nicely. I have a suggestion as to how to deal with it as well, though. When X.400-1988 added BP15, it also defined a set of extended bodypart types that let you send existing bodyparts as BP15 using an appropriate OID. I believe that support for these critters is required. Why not do the same for FTBP? That is, say that these extended bodypart OIDs can also be used as a contents-type FTBP field. We then have a place to put these parameters that leverages off support vendors are probably going to add for FTBP anyway. Ned P.S. I will be posting a revised version of my propose FTBP mapping document to this list in just a bit.
- rfc1495 & mime-body-part Justin Ziegler
- Re: rfc1495 & mime-body-part Harald T. Alvestrand
- Re: rfc1495 & mime-body-part Ned Freed