FW: [ebxml-msg] Compression issues

Some  comments on Dale's response:
1
is a string
and

                     <Property name= Compressed
>1</Property>

  is schema  valid.

The reference to section 4.2.4 of part 2 is just  because as a TC we may want to be consistent in the way we encode a reference to  a compression algorithm in various specs this TC produces. It is not the only or  necessarily best option, but one we have used before.

The content encoding values list is a reused code  list.  The way to reference the entity is via the  href  attribute of  PartInfo. This href value is not a request URI.

When we are about to make a change to the spec and want to use  the property name to not express that compression happened yes or no,  but  put
a named compression algorithm or a named compressed format in a  property,  then we may want to change the property name to match that.
From:  Moberg Dale [mailto:]
Sent:  04 November 2011 20:19
To:  Pim van der Eijk;  
Subject:  RE: [ebxml-msg] Compression  issues
Other small considerations that  may or may not matter.

The schema for the eb:Property  is of type non-empty-string. Xs:Boolean has allowable values : 0,1,true,false.   Hope this won’t generate any interop problems from some api sticking a “1”  in the text node of the element. Probably should not mention Boolean type if we  use the strings “true” “false”?

If we use a mime/media type then  bilateral agreements might extend AS4 compression to use new improved flavors.  But I agree it looks like we have locked in gzip for AS4, and maybe that is OK.

I am not sure I understand why  there is a  need to change the Property/@name value for various  choices.

Was AS4 supposed to be a profile  over
section 4.2.4 of ebMS  3.0 Part 2? And I am a little worried now about referencing
section  3.5 of HTTP (IETF RFC 2616) dealing with content-codings.

I think  that MSH-added compression is being defined for attachments (not the soap  envelope) in a soap with attachments message. Any one or all of the  non-SOAP-envelope body parts can be described as having a Compression property  in its PartInfo. I am trying to see what the HTTP content-codings mean when  using a multipart. I think we should all research this question and discuss what  we find on the call in 2 weeks.

My  initial view is impacted by the following remark

[HTTP, section 14.11]   The content-coding is a characteristic of the entity identified by the  Request-URI.
along  with the observation that the request-uri is associated with the entire chunk of  stuff after a pair of CRLFs.
From:
Pim van der Eijk  [mailto:]
Sent:  Friday, November 04, 2011 2:16  AM
To:  Moberg Dale; 
Subject:
RE: [ebxml-msg] Compression issues


There  are actually two things:
(1)   Expressing whether or not the message is compressed.  This looks like a  Boolean type to me.  The name of the property  Compressed  seems  to refer to this.
(2)   Expressing which compression algorithm is used.  This is more an  enumeration type.  In AS4 there is only one choice, GZIP,  so  expressing the selected algorithm in the message is actually not  needed.
(3)   Expressing the compressed data format as a MIME type.

In  section 4.2.4 of ebMS 3.0 Part 2, we define a message compression feature. (1)  is encoded by the presence of a  CompressionAlgorithm  element and (2) by a  particular value.  It uses values from the IANA content-coding token list,  as done in section 3.5 of HTTP (IETF RFC 2616).  Some IANA content-coding  values are relevant for compression:  gzip, compress, deflate, and  identity.

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/part2/201004/cs01/ebms-v3.0-part2-cs01.html#__RefHeading__29502104

So here  are the options:

A.   The original proposal was to stick to the property  Compressed  but add a value
true  for (1) and not include (2) in the message, but assume AS4 processors are  hard-wired to use GZIP.  Absence of the property,  or presence with a  value  false  means no compression.

<eb:Property  name= Compressed
>true</eb:Property>

B.   Rename the property to something like  CompressionAlgorithm  or  ContentCoding
and use the content-coding token values.  Absence of the property means no  compression or equivalently  identity  content-coding.

<eb:Property  name= CompressionAlgorithm
>gzip</eb:Property>

The IANA  registry of content-coding values is available at:
http://www.iana.org/assignments/http-parameters/http-parameters.xml

This  works for AS4 as gzip is a value on this list.

C.   The third option is what Dale proposes.  A variant is that the  property might perhaps be renamed to something like:

<eb:Property  name= CompressedMediaType
>application/gzip</eb:Property>

The  advantage of using MIME types is that some newer compression methods have a MIME  type but not (yet) a content encoding, and that there is the convention of  adding new (unregistered) types using a  x-  prefix that does not exist for  content coding. An example is LZMA used by 7-Zip, which has the MIME type
application/x-7z-compressed .   But this is not an issue with AS4 as  it is limited to gzip.

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