OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg-as4 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: MEPs for User Messages Sent Reliably w/Receipts


Here's my initial thoughts on Jacques summary document on the MEP use cases for user payload messages with receipts + RM.  Hopefully, this will kickstart some discussion and get us on the road towards consensus on which of these cases (subcases) AS4 should support.

First, I think there is two ways we can approach this effort:
  1. We can proceed with deciding which cases and subcases AS4 will support, and then describe those options in the AS4 Deployment Profile document, or
  2. Since the ebMS v3 core spec is non-specific on the how-to/when-to on returning eb:Receipts, we can go ahead a document all of these cases/subcases that Jacques has summarized (and others that are out-of-scope for AS4?) in a general Conformance Profile that can be utilized by ebMS v3 implementations and referenced/constrained by AS4.
My vote is with #2.  In talking with Jacques, I believe he thinks this is some information left out of the ebMS v3 core spec, and I also think that having this in a general profile that can be reference by both ebMS and AS4 implementations, it can improve compatibility between those two groups of impls.  Also, I think that it's good for the ebMS community as a whole that we take advantage of this thinking we are doing around this and get it documented -- not just for the subset that AS4 needs.  Comments?  Thoughts?

Moving forward with what I think AS4 should support...
  1. I think RM as a functionality should be an optional on/off switch.  I don't think that reliable messaging should be REQUIRED for every transaction
  2. I don't think that sending any eb:Receipt reliably should even be an option.  "Acking the ack" to me seems overkill for AS4.  If there is a clamor for it, we could always support it in future versions of the profile.

Use Case 1: Non-addressable Sender

I think there is merit in supporting this Use Case, along with its two subcases (with and w/o RM).  I see non-addressable endpoints using a combination of UC1 (Sync One-Way/Push) and UC3 (Sync One-Way/Pull) and a means to push documents to trading partners, and pulling down documents from trading partners.  If we support UC3 (and I think we should), then I think we got to support UC1.

Use Case 2: Sender and Receiver both Addressable

No doubt in my mind that AS4 should support this UC, but I think (following my statement above) that we should only support Subcase 2 and 3.  I'm inclined to draw the line at sending eb:Receipts reliably.

Use Case 3: Non-addressable Receiver

Already we are getting favorable feedback that AS4 is planning on supporting the document pull model, so I think we commit AS4 to supporting UC3 (along with UC1).   Again, I think that we only support Subcase 1 and not support Subcase 2 with includes a reliably-sent eb:Receipt.

Also, I noticed that Jacques doc didn't include a subcase for UC3 in which there is no RM.  I think that subcase should also be supported.

That's my thoughts...







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]