I think the
main obstacle is that the
current mime types for compression do not really define a very good
encapsulation approach like those found in S/MIME or for that matter in
message/* types. Gzip, for example, has not even registered with IANA,
and so
we have things like application/x-gzip and related extension types.
There is an
application/zip but it looks encumbered to me.
We can use
the ebMS 3 Property extension
fields as you suggest. The only other somewhat standardized approach
would be
to encapsulate using the S/MIME plus CMS defined compression object, as
done in
Terry Harding’s internet draft for AS2 compression.
Of course
for AS4 we would only use the
pattern
No
encryption, no signature
-RFC2822/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
This
section shows the layers
of an unsigned, unencrypted compressed
message.
The first line
indicates that the MIME message conforms to
RFCs 2822
and RFC 2045 with a
Content-Type of application/pkcs7-mime.
Within
the pkcs7-mime entity
is a compressed MIME entity containing
the
electronic business
document.
that is
illustrated in the following example:
Content-Type:
application/pkcs7-mime;
smime-type=compressed-data; name=smime.p7z
Content-Transfer-Encoding:
base64
Content-Disposition:
attachment;
filename=smime.p7z
MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg
Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0
Except we
would not need or use base64
encoding when using HTTP as a transfer protocol.
That would
be quite a mix of layers and
technologies – S/MIME, CMS compression (with BER encoding of ASN.1
specified object), inside MIME and then referenced using a CID URL
within
XMLDsig for a signature. And there would be no message level encryption
using
xmldsig.
So, given
the above and by comparison, using
the ebMS 3 defined extension Properties seems almost elegant J
Dale Moberg
Yes.
Each attachment would get a
PartInfo with a href attribute that has a value that is the Content-ID
URI of
the attachment.
Honestly I am a bit mixed about this approach to identifying the
attachment’s original mime-type and character set. If someone has
suggestions with how to deal with this case in the attachment’s mime
headers I would like to hear the idea.
The main advantage of my proposal is that the compression can be
handled
completing outside of the SOAP Processing. Meaning that the
implementation
would be very simple.
On 11/17/08 9:00 PM, "Timothy Bennett" <timothy@drummondgroup.com>
wrote:
If there are multiple
compressed payloads attached, would
there be multiple eb:PartInfo elements to describe each compressed
payload, and
does the href attribute uniquely describe and distinguish which payload?
Ric Emery wrote:
Below is what I had in mind for compression support in AS4. I would
like to
keep the proposal simple - for both implementers and interoperability.
As
such I only propose support for one compression scheme - GZIP. And do
not
drastically alter the SOAP with Attachments Packaging. The scheme below
should be easy to implement without needing to modify existing SOAP
stacks.
The ebMS processor should be able to handle the
compression/decompression
operations on its own.
Regards,
Ric Emery
---------
Application payloads that are built in conformance with the SOAP
Messages
with Attachments [SOAPATTACH] specification may be compressed.
Compression
of the SOAP envelope and/or payload containers within the SOAP Body of
an
ebMS Message is not supported.
To compress the payload(s) of a message build in conformance with the
SOAP
Messages with Attachments [SOAPATTACH] specification
the GZIP compression algorithm MUST be used. Compression MUST be applied
before payloads are attached to the SOAP Message. The content type of
the
compressed attachment MUST be "application/gzip".
When compression, signature and encryption are required of the MSH, the
message MUST be compressed prior to being signed and/or encrypted.
A eb:PartInfo/eb:PartProperties/eb:Property/@name=
"MimeType" value is RECOMMENDED to identify the mimetype of the
payload
before compression was applied.
A eb:PartInfo/eb:PartProperties/eb:Property/@name=
"CharacterSet" value is RECOMMENDED to identify the character set of
the
payload before compression was applied.
Example:
<eb:PartInfo href="cid=foo@example.com"
<mailto:cid=foo@example.com>
>
<eb:PartProperties>
<eb:Property
name="MimeType">application/xml</eb:Property>
<eb:Property
name="CharacterSet">utf-8</eb:Property>
</eb:PartProperties>
<eb:PartInfo>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php