[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - AS4-profile-v1.0-wd20.odt uploaded
Unfortunately not all changes to previous
versions were tracked.
Comments inline.
Pim
From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Jacques Durand Sent: 05 December 2011 23:55 To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org 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. 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. -
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:
ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On
Behalf Of Pim van der Eijk Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]