Unfortunately not all changes to previous
versions were tracked.
Comments inline.
Pim
From:
[mailto:] On Behalf Of Jacques
Durand
Sent: 05 December 2011 23:55
To: Pim van der Eijk;
Subject: RE: [ebxml-msg] Groups -
AS4-profile-v1.0-wd20.odt uploaded
I
have uploaded a candidate AS4 spec (AS4-profile-v1.0-wd20.odt) from wd19, that
implements most of Pim’s recommendations, remaining from Sander’s (in
wd19).
1-
Compression property with
value "true" instead of empty string for XML schema
compliance.
Did
the update that requires the “Compressed” property to have a value (I
believe the Example in 3.1 was the main culprit?). Also it seems we never
introduced the “Compressed” property used in the example (so I
did).
Section 3.1 now requires two properties "Compressed"
(fixed value "true") and "CompressionType" (fixed value "application/gzip"), but
the example in that section still only has "Compressed". Having a separate
property for the type of Compression seems useful if more than one type is
allowed (other compression algorithms have emerged after GZIP that have
advantages in some cases, though it's fine if AS4 does not want to use them for
interoperability), but if we have just one allowed value, what does it
add? Isn't the "Compressed" property redundant if we specify the
"CompressionType" ?
2-
MIME type value in property
for a compressed attachment required instead of
recommended.
Done
by Sander.
3-
Add note that a compressed
payload must be in a separate MIME part and not in the SOAP
Body
Added
a simple note in 3.1.
4- In AS4
5.1.8.(a) and 5.1.8.(b), clarify use of receipts with simple SOAP messages,
where the SOAP envelope is not in a part with a content identifier, and has no
MIME content ID, so here there can be no part identifier.
Done
by Sander.
5.1.8 (b) references message parts using
ds:References, but 5.1.8 (a) now should references the ebMS message ID in
a PartInfo ? The
MessageId is already referenced in the eb3:RefToMessageId in the MessageInfo of
the SignalMessage in both cases, having it as value for MessagePartIdentifier in
one case is redundant,
is inconsistent with the other non-repudiation use and does not
match the semantics of the ebbp:NonRepudiationInformation structure.
BTW what would
"should" mean, are other values allowed, if yes, which
ones?
The earlier proposal was to use the MIME part
identifiers for reception awareness. This works for all SOAP with
attachment messages. The
issue was about plain SOAP messages with any payload in the SOAP
body. Another solution is to require SOAP with attachments for AS4
messages (or at least for the ones that require receipts), after all that
worked in ebMS 2.0.
Unfortunately the value of a
MessagePartIdentifier is a non-empty string, so it cannot be left
unspecified.
5-
In AS4 5.1.8.(a) and
5.1.8.(b), note that it is impossible to generate a valid ebBP reception
awareness
We
have to decide what note to be added in 5.1.8 for this.
6-
In AS4 5.1.8.(a) and
5.1.8.(b), decide on ebbp:MessagePartIdentifier format for a payload part in
SOAP body that is implicitly identified by absence of an "href" attribute as
described in ebMS3Core.
Should
we just require something like a string “soap:body”, for readability?
(not done
yet)
Unfortunately the value of a
MessagePartIdentifier is a non-empty string, so it cannot be left unspecified.
We could profile AS4 to make the href attribute mandatory, always or for
messages that request receipts.
7-
Clarify that an identifier
of a payload in the SOAP Body is a stored as an attribute value on the SOAP Body
element, not on the contained document root (AS4 interop).
Not
sure I understand this: the soap Body could have several payload parts actually,
and the @id attribute is at the root of each one of these (not on the Body
element). See example in Appendix C2 of Core V3.
There is a problem with that example in the core
spec: the business document is submitted by the Sending
application, and it may not have an "id" attribute. We shouldn't let
the sending MSH add an id, as the receiving MSH may not know if it was added by
the sending application or by the sending MSH, so it can't remove
it. The XML schema of that document may not even
allow an "id" attribute, so unless it were removed, the receiving application
would consider it an invalid XML
document.
When using WS-Security, the identifying
attribute is on the SOAP:Body, not on the enclosed XML document. We don't
require WS-Security, but the place to put the attribute should be the same
whether we use it or not.
8-
Discuss the format of the
identifier (xml:id or wsu:Id).
It
seems to be @id (not @Id) see examples in core V3.
9-
Bad references to SOAP 1.1
instead of 1.2.
Done
by Sander.
10-Guidelines on values for mpc
(message partition channel) attributes. Pullrequests do not have ebMS
metadata, so a partner that sends documents to multiple partners using Pull mode
must assign them to different channels, unless we want to require support for
the "selective pulling" feature of Part 2 in ebMS.
Here
I think it would be better to add as an optional extra feature (for a
Sender), support for sub-channels. We have defined this feature in Part 2 for
intermediaries only. We can refer to it as an (optional) extra feature, as it
was initially defined for a multi-hop context but can easily be considered in a
single hop case here.. See new proposed section 3.5.
We need a way to specify, as a new PMode parameter the
"receiver sub-MPC". This is the MPC that the receiver pulls from. It may
be different from the MPC the sender submits it to, but not completely
different, it is required to be a sub-channel. The Sending MSH needs to
know how to partition the set of messages submitted to an MPC across various
sub-MPCs. What rules control this partitioning? We might
associate a sub-channel with an XPath _expression_ over the UserMessage
header. Here the partitioning is done at submission time and authorization
can be done at a fine-grained sub-channel level.
Another option is the selective pulling feature in Part
2. Basically, a receiver could pull from a generic MPC and select it
using the to:PartyId=<<their ID>>. Here the selection is done
more dynamically, the receiving MSH has more control. But the receiver must
be authorized for the MPC, so this is more a feature to give better control to
the receiver.
11- Support for Two
Way MEPs. This is not needed for EDIINT, but in essence
allowing an MSH to set the value for RefToMessageId adds minimal complexity to
an implementation. It allows AS4 to be used also for SOA-style,
request/response interactions.
I
think Sander addressed this (just as an option) with a simple
note.
If we want this,
we need to allow them in 2.1.1 and 2.2.1. I'm in favour of allowing Two
Way MEPs. All it means is that an MSH must be able to set an
eb3:RefToMessageId in an outgoing message, which is trivial. (We require
them to set ConversationId already, after all). I can't think of any
interop reasons to leave this out. The main benefit
is that AS4 can be used for SOA-style, request/response interactions and not
just for batch EDI. AS4 could replace ebMS 2.0 for all of my
customers' applications if it supported this.
The OASIS Energy
Interop TC is currently profiling ebMS 3.0 for smart grid, and this issue came
up there are well.
Including RefToMessageId in responses supports a style of
asynchronous programming where the sender registers a callback based on
MessageId. It is possible to do this by correlating message payloads, but
it is much more practical and consistent to be able to use a UserMessage
element. When the response comes it, the appropriate handler can be called
before any payloads are processed.
IMPORTANT:
regarding support for compression:
-
The
question whether light AS4 clients – in particular “minimal” client - should
support compression (meaning also attachments, and msg properties) is still
controversial in my view: if we want to “certify” very light clients and
devices, I’d be in favor of keeping the “minimal client” conformance level low,
i.e. not requiring these features.
There was a
question about this in the OASIS Energy Interop TC as well.
They asked if GZIP support is widespread or practical in low-end devices
that are in their scope. A strong advantage of GZIP is
that it has a very small memory footprint and is fast (compared to other
algorithms that have a better compression ratio).
They also asked
if we had considered http://www.w3.org/TR/2011/REC-exi-20110310/ as
an alternative.
-
So
my uploaded draft reflects this option (low bar for “minimal client” conformance
level). See the conformance Clause: to be discussed.
NOTE:
a small issue not fixed yet: the ref to V3 Part 2 is using a different acronym
in the ref section ([ebMS3ADV]) than
in the body of the spec (ebMSP2)
Thanks
Jacques
From:
[mailto:] On
Behalf Of Pim van der Eijk
Sent: Friday, November 11, 2011 6:26
AM
To:
Subject: [ebxml-msg]
Groups - AS4-Profile-csd04-wd-17.odt uploaded
Submitter's message
I've made some updates based on
discussion of the issues in the TC. Jacques will produce the next version after
the upcoming F2F.
------------
Fixed a bad reference to SOAP 1.1
in section 2.2.1 .
In 3.1 compression, the original MIME type of a
compressed payload is required instead of just being recommended; added
clarification on use of CharacterSet in compression.
Minor editorial
changes and some comments on areas that may need clarification.
-- Mr.
Pim van der Eijk
Document
Name: AS4-Profile-csd04-wd-17.odt
Description
AS4
profile
Download
Latest Revision
Public
Download Link
Submitter: Mr. Pim van
der Eijk
Group: OASIS
ebXML Messaging Services TC
Folder:
documents
Date
submitted: 2011-11-11 06:25:55
Revision:
12
