RE: [ebxml-msg] Compression issues

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Here is another observation for discussion:

 

An error may occur when a receiving MSH attempts to decompress a compressed payload, or the MSH may find an error in the compressed data.

The AS4 compression feature does not discuss how these errors are to be handled.

 

The ebMS 3 Part 2 message compression feature defines an error EBMS:0055,  "DecompressionError" but it is defined for message decompression. 

 

AS4 right now defines one new error (EBMS:0301 in section 3.2) for missing receipts. Section 5.2.2. has Pmode parameters for receipts errors.

 

We could define a new AS4 payload decompression error as error code EBMS:0302, and extend 5.2.2 with similar parameters for (de)compression errors.

 

Pim

 

---

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Moberg Dale
Sent: 03 November 2011 22:10
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Compression issues

Here are some observations about AS4 compression section, and the issues faced in fixing the specification to align with the ebMS3 schema.

 

tns:non-empty-string is the base type extended by the complexType Property.

 

     <xsd:complexType name="Property">

           <xsd:simpleContent>

                <xsd:extension base="tns:non-empty-string">

                     <xsd:attribute name="name" type="tns:non-empty-string" use="required"/>

                </xsd:extension>

           </xsd:simpleContent>

     </xsd:complexType>

 

 

So, a Property element of the Property type included in a PartProperties sequence of a PartInfo cannot be empty; it needs a text node with at least one character in it.

 

A good choice for a value when the Property@name is “Compressed” is the content-type of the attachment, which MUST be “application/gzip” according to the profile.

 

Already the Property@MimeType value is to be the mime type of the original that has been compressed (application/edi-consent e.g.) , and it is already recommended

that this mime type information of the original be included.

 

The other proposal on the table is to use a Boolean value, as mentioned in describing PMode.PayloadServiceCompression…

But PMode values are really for a MSH’s local operation. Information conveyed in the SOAP message header does not necessarily have to repeat PMode information or values.

 

When a sender includes the PartInfo, I guess the compression Property  metadata’s  value can be useful to the receiver. (Though in my opinion, it should be in an attachment  MIME content- header in the first place.)

 

On the other hand, the PMode information about PayloadServiceCompression tells the sender to compress a part by using the processing of an application/gzip. It is not used to describe a compressed data type like a jpeg or mpeg, and having a PMode PayloadServiceCompression false does not imply that the content has not been compressed in some way as part of its application layer processing definition. At least that is my understanding of what should be understood. Possibly we should clarify the PMode values so that we say:

 

True:  the sending MSH is to compress at least one attachment payload over this MEP segment.

False: no attachments are to be compressed by the sending MSH using application/gzip processing.

 

The defaulting of the PMode PayloadServiceCompression to”false” carries no implication about what an omitted Property@name=Compression has as its value.  

 

If the PMode of PayloadServiceCompression is “false,” and the MSH adds an ebMS3 Property element to a PartInfo saying it has compressed an attachment, the MSH is clearly broken.

 

So the example in section 3.1 needs to change. My proposal  is that the line:

 

<eb:Property name=”Compressed”>application/gzip</eb:Property>

 

replace the current:

 

<eb:Property name=”Compressed”/>

 

I would also urge consideration of rewording the explanatory text around PMode so that no one interprets it to mean that having some payload whose data has been compressed at the application layer requires a PMode value of “true”.  That is simply not what was intended.  We should not confuse an imperative with a declarative semantic!

“True” in the  PMode value here must mean “Make it so!”