[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Attachment support inconsistency
Similarly, the following is statement for the client
client. If Light clients are required to support compression, they need to
support attachments.
Support for attachments is NOT REQUIRED – i.e. any XML message payload will use the SOAP body. From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk Sent: 10 November 2011 17:48 To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] 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: 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!” |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]