I think we need a meeting with the full TC, including
the AS4 editors, to resolve this.
I've shown how payload part references can be included,
and a valid ebBP signal can be generated for any AS4 message, using an
XSLT stylesheet. It follows the pattern that e-business receipts provide a
listing of line items that mirrors the line items in the related
messages. E.g. a UBL Receipt Advice or
GS1 eCom XML ReceivingAdvice mirror the structure of the corresponding
DespatchAdvice business documents. But I'll admit it is somewhat contrived.
However, the alternative of having an ebBP
signal receipt that has a single part identifier, the value of which is not
a part identifier but a message identifier, which is redundant as it is already
present as the value of the RefToMessageId, and which does not have part
references for the actual message parts, is even worse. The ebBP structure
may be valid and it's simple but it's an
ugly kludge.
Changing the ebMS schema definition of "receipt" to
allow empty receipts is indeed better than this, and easier than changing the
ebBP schema. I'm not sure if this can be argued to be an "errata" on the core V3
schema.
So are there any other alternatives? In some e-business standards, acknowledgements involve
including a copy of the received
business document. This is the approach of the various OAG BODs using the
"Acknowledge" verb. E.g. an AcknowledgePurchaseOrder BOD contains a
PurchaseOrder structure. In ETSI TS 102 640 (Registered Electronic Mail)
there is the option to include the Original Message or a Normalized Message with
a receipt, for legal reasons.
For large XML messages or messages with large non-XML
attachments, that seems unpractical. So as
a simplified alternative, I'm proposing that we do not use the ebBP signal but
instead include the eb:UserMessage XML element of the received message.
Advantages:
1) We don't use the ebBP element in a way
that does not match its purpose and intent.
2) No need to handle various special cases,
as my previous XSLT had to.
3) Very simple to implement in AS4 message
handlers (basically one line of code to fetch the element using XPath or
equivalent and another to insert it as the child node of the receipt
element).
4) The receipt actually has rich metadata
about the received message, which may be of interest for testing and monitoring
purposes.
5)
The receipt contains the UserMessage including Payload references, but not the
actual payloads, so its size is limited.
6) No need to change the V3 Core XSD or the
ebBP schema.
The
UserMessage element is a separate element in the "refactored" ebMS header we
created in Part 2, so an AS4 engine can validate using that schema.
For consistency across reception awareness and NRR, we
could include the UserMessage also in the NRR case. But the UserMessage
does not contain hash values of payloads, so it is insufficient for NRR, and the
ebBP NonRepudiationInformation element would still be needed.
I'll
be in meetings the rest of the day, talk to you all tonight.
Pim
From:
[mailto:] On Behalf Of Sander
Fieten
Sent: 17 January 2012 19:58
To:
Subject: Re: [ebxml-msg] Groups -
AS4-profile-v1.0-wd20.odt uploaded
I think that the problem here is the use of the Receipt signal
[message] for reception awareness. The phrase "The eb:Receipt element
MAY occur zero or one times; and, if present, SHOULD contain a single
ebbpsig:NonRepudiationInformation child element" in the Core spec however
suggests that the signal was designed with only non repudiation in mind.
Reception awareness is than more a task of the reliability layer.
In principal reception awareness only requires a reference to the received
message, and therefor the eb:Receipt itself would suffice. But that is something
the ebMS schema does not allow. So another option would be to relax that
requirement and make an empty Receipt element possible. However that may
take some time, but the that is also the case when requesting a change for the
ebBP schema.
Another option would be to use a different child element for eb:Receipt in
case of reception awareness. Question than is which element that should be? Also
it goes against the "SHOULD" from the core spec, but that would be defendable
because the goal we want to achieve is not non repudiation but reception
awareness. So not ideal either.
The solution as described in the current draft is, in my opinion the
easiest one to implement the reception awareness case based on the current specs
of both the eb:Receipt and ebbp:NonRepudiationInformation elements. I
therefor favor to stick to the draft as was decided during our TC call on
December 14th.
Regards,
Sander
On 17 jan. 2012, at 17:51, Pim van der Eijk wrote:
Jacques,
In my email to the list of December 13, there are a number
of examples using MessagePartIdentifier. There is also an XSLT that
computes an AS4 receipt, with documentation, for the range of diverse
situations to support.
The ebBP signal assumes a receipt for a message includes
information about constituent parts of a message using either XML Signature
references or using a MessagePartIdentifier. The structure seems
oriented towards MIME-structured messages that have MIME part
identifiers. If we are
re-using this signal structure, we should stick to its structure and
semantics, beyond making sure the receipts pass XML
validation. So if a message has part identifiers (Payload
references), it seems to me that a receipt should use those part
identifiers and not (just) the ebMS MessageId.
If we find the ebBP structure to be limiting, we could
also ask ebCore (which maintains the schema) to update the ebBP signal schema,
e.g. via the Errata process. The XSLT would be much simpler if the schema
would support an empty list of message parts (User Messages with no
Payloads), or part identifiers that have the empty string value (for messages
that have no "href" attribute, using the implicit assumption that this refers
to a payload in the SOAP Body).
Pim
From:
[mailto:] On Behalf Of Jacques
Durand
Sent: 24
December 2011 02:53
To:
Subject: RE: [ebxml-msg] Groups -
AS4-profile-v1.0-wd20.odt uploaded
I
have uploaded AS4-profile-v1.0-wd21.odt. Diffs show compounded changes with
wd20, from wd19. Note:
- 5.1.8
left untouched. It strikes me we have no example of using ebbp:MessagePartIdentifier .
We should have one at least, as this is a foreign element to ebms. Also,
it does not sound right to state “The ebbp:MessagePartIdentifier
element SHOULD contain the
eb:MessageId of the received message.” As
Pim mentioned, this is a SHOULD which does not help much. But why shouldn’t we
refer to each message part, if we have to use ebbp:MessagePartIdentifier? I
would expect to see in a Receipt the content of href string from the original
message ( <eb:PartInfo
href="">) for
each part referred in the receipt.
- I
added in the AS4 additional features section, a couple of Receipt-related
error codes recommended by Pim.
-jacques
From:
[mailto:] On Behalf Of Jacques
Durand
Sent: Wednesday, December 07, 2011 10:03
AM
To: Pim van der
Eijk;
Subject: RE: [ebxml-msg] Groups -
AS4-profile-v1.0-wd20.odt uploaded
Pim
and all:
Inline ,
a few more comments <JD>.
I
am not sure I can attend tomorrow’s meeting – will try, but am in another F2F
meeting out of office.
-jacques
From: Pim van der Eijk
[mailto:]
Sent: Tuesday, December 06, 2011 1:09
AM
To: Jacques Durand;
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:
[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" ?
<JD>
I see. So the example alone was wrong. And if we have to choose between Compressed=”true”
/ “false” andCompressionType=”application/gzip” (no
other altearnative – so far) then I’d choose to keep CompressionType=”application/gzip” because
in a future version of AS4 there might be another compression option, and we
don’t want to change the schema to support that. So I would not give it “true”
as value, or did I misunderstand this issue?
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.
<JD>
I noticed this redundancy. Should we remove that requirement? I don’t recall
why we made it.
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.
<JD>
I see. Should we – as part of AS4 profile – recommend that in case several
payloads are added in the Body, there should be a wrapper that will have this
@id (like <payloadpart id=…>. That’s not pretty but I don’t see
how to do better…
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.
<JD> AS4
can add a new PMode parameter PMode[1].BusinessInfo.subMPCext
that
must contain the extension only to be appended to
the PMode[1].BusinessInfo.MPC. E.g. if
MPC = “http://sender.example.com/mpc123” and subMPCext = “subc42”, then
the subchannel to pull from is: http://sender.example.com/mpc123/subc42
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?
<JD>
the assignment of messages to sub-channels is done similarly to the way its
described in Part 2: there is a different PMode for each subchannel receiver,
so this is just like regular message-to-PMode
matching.
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.
<JD>
the issue with this is that there is no guarantee that your messages will NOT
be pulled by unauthorized parties (as everyone is authorized the same way for
selective pulling)
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.
IncludingRefToMessageId
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 questionabout 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
