[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:dmoberg@axway.com] Sent: 04 November 2011 20:19 To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org 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:pvde@sonnenglanz.net] 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. 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:
ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On
Behalf Of Moberg Dale 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!” |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]