[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg-as4] Compression Simple Proposal
Yes, I think compared to the alternatives that
we might use (which would be applications of existing standards), his approach
seems to be “almost elegant” ! From: Timothy Bennett [mailto:timothy@drummondgroup.com] So... your final assessment is
a +1 for Ric's suggestion? 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 From: Ric Emery
[mailto:remery@us.axway.com] Yes. Each
attachment would get a PartInfo with a href attribute that has a value that is
the Content-ID URI of the attachment. 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?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]