Many thanks for replying, Jim.
Did you mean to say "bodypart" rather than "content" at the end of
your sentence:
Conveying a content within a ForwardedContent body-part clearly
has a different semantic to conveying a content.
I thought the application/x400-bp had adequate MIME parameters and
other framework to encapsulate any Basic or Extended X.400 bodypart.
And a ForwardedContent is an Extended bodypart too.
o The "x400-bp" subtype would not have lost any information and
would have preserved the ForwardedContent.
o The x400-bp's parameter would tell the receiving agent that an
Extended bodypart of type ForwardedContent had been encapsulated.
o The receiving agent could then base64-decode this and invoke an
X.400 content-identification routine, which would render the
Content if it could.
Or is there more to it all? Are there things I haven't considered?
Best Regards,
Hari.
-----Original Message-----
From: Jim Craigie On Behalf Of Jim(_dot_)Craigie(_at_)clearswift(_dot_)com
Sent: Wednesday, August 28, 2002 5:45 PM
To: Muzumdar, Hari
Cc: 'SMIME, IETF'
Subject: Re: CMS-X.400: [application/x400-content] versus
[application/x400-bp ]
Hello,
There was some discussion early this year about the proposed new MIME
subtype "application/x400-content".
Have there been any further discussions and/or decisions on this topic?
The mailing list contains only the initial few exchanges.
Was the application/x400-bp type (IANA-registered by RFC 1494) not
considered? At first glance, this does look like it could encapsulate
ForwardedContent. What were the reasons for proposing a new MIME type?
Conveying a content within a ForwardedContent body-part clearly has a
different semantic to conveying a content. Preserving that semantic is
usually important to both originator and recipients.
Jim