[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] Arvola's SyncReply issues
Arvola,
I've snipped out a few of your comments that centre on the
SyncReply element and embedded a few comments below. Hopefully, this will
move us quickly towards resolving your questions.
thanx,
doug
----- Original Message -----
From: Arvola Chan
To: David Fischer ; ebXML Msg
Sent: Wednesday, 02 January 2002 12:33
Subject: Re: [ebxml-msg] Messaging Spec v1.092 ...
6. Line 1412: I like to point out that a SyncReply
element is not compatible with an AckRequested element that is targeted at the
next MSH.
I'm not sure why you're of this opinion.
Why couldn't the next MSH synchronously reply with an Acknowledgment element
(after it's persisted the incoming message, of course)?
12. Line 1591: I think it may be problematical for
the recipient to do duplicate elimination when no DuplicateElimination element
is present. What happens if SyncReply is present and AckRequested is not
present. If the incoming message is not passed on to the application, should any
reply be returned to the sender?
The DuplicateElimination semantics are described
rather clearly in the specification. The answer to your question is that
the synchronous reply must contain the first response to the duplicate
message. The receiver application might not hear about the duplicate but
the will get the same answer back as the first time.
20. Line 1733 and line 1738: These
two bullet points assume that syncReplyMode in the CPA is not used with an
asynchronous communication channel. This is in conflict with the 1.0 CPP/A
spec statement quoted in item 15 above. I think this is a minor technical issue
that may require some discussion.
Would this be resolved by (more correctly)
referencing the syncReplyMode semantics in the CPP/A 1.1 specification? If
not, we still have a discrepancy between the two specifications and that should
be resolved as soon as possible. The CPP/A 1.0 specification may have some
vestiges of the "bundling" semantics I've mentioned before (using syncReplyMode
to describe which signals may be bundled with the application response).
Those semantics apply equally to synchronous and asynchronous channels.
The current SyncReply MSH semantics are all about what signals must appear in
the synchronous response over a synchronous channel.
It's not up to the MSH to determine how later
business responses might be bundled with business signals and asynchronous
channels are therefore not relevant. Of course, the current description of
an MSH doesn't provide a way to describe expectations around bundling of
business responses and signals with MSH signals like the Acknowledgment element
over an asynchronous channel. 2.0 issue?
...
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC