Re: rfc1495 & mime-body-part

[Ned Freed <[e-mail]>]

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