MessageProperties inconsistency

While going through AS4 I noted the  following:

Section 3.1
Support for  compression MUST be provided by AS4  implementations.
The  Compression feature uses MessageProperties.

Section 2.2.1, Light Client Features states:
Support for MessageProperties is NOT  REQUIRED
.

These  sections seem to contradict each other ?

My  proposal is to REQUIRE support for message properties in the light client.   It is trivial to support, just like the compression feature.

Pim
From:    [mailto:]  On Behalf Of  Moberg  Dale  Sent:  03 November 2011 22:10
To:

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!”