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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: RE: [ebxml-msg] Re: SyncReply Module

No, SyncReply is NOT perMessage.  I added a paragraph in 6.1 to cover this

My problem is that you never know if there is an intermediary so should you
always include SyncReply if SyncReplyMode not equal *none*?  If SyncReply is
included, it will make it all the way to the end (one hop at a time), isn't
there always a potential for mismatch?  If it is always going to be pass all the
way through, why put actor=next?  If it is always included, then why bother with
it in the CPA?

What was the value of taking this out of QualityOfServiceInfo and making it an
element?  IMO, we just added 100+ bytes for nothing.



-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, November 16, 2001 7:37 PM
To: Doug Bunting; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: SyncReply Module


Thanks for the clarification why SyncReply belongs in 'Core Functionality'
rather than in 'Additional Features'.

I have two related questions:

1. Is syncReply assumed one of those parameters that are perMessage? I don't
think that the CPP/A team is aware of such an assumption.

2. If not, is the element mandatory when it is already specified in the CPA?
When no intermediaries are involved, I would have expected that a syncReply
specification in the CPA would imply that sync reply is to be used
regardless of the presence or absence of a SyncReply element in the message
header. What triggers the sender to include a SyncReply element in the first


-----Original Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Friday, November 16, 2001 5:15 PM
Subject: Re: [ebxml-msg] Re: SyncReply Module


My, you're a quick reader...

You're understanding covers the flag's semantics as it appeared in the 1.08
document.  Maintaining the existing "keep channel open 'til a response is
ready" semantics, we slightly expanded the feature to include making sure an
intermediate SOAP processor doesn't close the connection.  In essence, we
recognised the possibility of "regular" SOAP nodes linking full-blown MSH

The previous synchronous mode would have supported MSH -> HTTP proxy -> MSH
because HTTP proxies operate in a synchronous mode by default.  The new flag
allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node
might prefer.

You're correct that the previous flag in QoS is no longer necessary.

We discussed placement of this module's description in our document during
the meeting and the consensus seemed to be putting this feature in the base
section because it may apply even to a SOAP node with just a bit of ebXML
smarts -- level 0 in ebXML conformance.


----- Original Message -----
From: "Arvola Chan" <arvola@tibco.com>
To: "David Fischer" <david@drummondgroup.com>
Cc: <ebxml-msg@lists.oasis-open.org>
Sent: Friday, 16 November 2001 16:47
Subject: [ebxml-msg] Re: SyncReply Module


My understanding is that the SyncReply module is equivalent to the renaming
of the former Via module, minus the TraceHeaderList. As such, shouldn't it
stay in Part II (Additional Features) and under the Multi-hop chapter?

The syncReply attribute under QualityOfServiceInfo goes away because the use
of syncReply between the From and To parties is governed by a static (not
per pessage) parameter in the CPA.

In the single-hop case, it should be sufficient to indicate in the CPA that
sync reply is to be used, without explicitly including a SyncReply element
in the SOAP header.


-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Friday, November 16, 2001 3:59 PM
Subject: [ebxml-msg] v1.09

This includes all the edits I have received including those decided upon at
F2F this week.

I do not yet have a Conformance Clause or the new sub-section dealing with
Signature Security (Galvin).


David Fischer
Drummond Group
ebXML-MS Editor.

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC