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


David:

We used to have a syncReply attribute under both QualityOfServiceInfo and
Via. We determined that the one under QualityOfServiceInfo is not needed
because it should be obtained from the CPA.

The Via element is essentially renamed as SyncReply because once we removed
the TraceHeaderList, syncReply is the only attribute that is left in Via.

Because the sender may not be aware of the presence of SOAP or MSH
intermediaries, it should always include a syncReply element in the message
header if the CPA specifies any syncReplyMode other than 'none'.

Regards,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Friday, November 16, 2001 6:18 PM
Subject: RE: [ebxml-msg] Re: SyncReply Module


>No, SyncReply is NOT perMessage.  I added a paragraph in 6.1 to cover this
>issue.
>
>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.
>
>Regards,
>
>David.
>
>-----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
>
>
>Doug:
>
>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
>place?
>
>Thanks,
>-Arvola
>
>-----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
>
>
>Arvola,
>
>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
>nodes.
>
>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.
>
>thanx,
>    doug
>
>----- 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
>
>
>David:
>
>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.
>
>Regards,
>-Arvola
>
>-----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
>the
>F2F this week.
>
>I do not yet have a Conformance Clause or the new sub-section dealing with
>Signature Security (Galvin).
>
>Regards,
>
>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