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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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

Subject: Prelim Minutes of 6/14 teleconf

The prelim minutes are attached.
Please provide comments before friday.

Tom Rutt
WSRM TC charir

Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes of WSRM TC Conference Call –June 14, 2004


The meeting of the WSRM TC  took place by teleconference 

Monday, June 14, 2004, from 5:30 to 7:30 PM Eastern Standard Time



1         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Action Item Status Review

4 Discussions of unresolved comments

5 Discussion of Document progression

6 Scheduled Vote for CD (not likely)

7 Scheduled Vote to Submit to OASIS for member vote (not likely)

6 Discussion of FAQ for WS-Reliability


2         Roll Call



First Name

Last Name








University of Hong Kong





Sun Microsystems





Sun Microsystems

























NEC Corporation





NEC Corporation


































TC Chair






Booz Allen Hamilton



 Meeting  is  quorate.


3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes will serve to record issue resolutions.

3.1      Approval of previous meeting minutes

The minutes of the June 08 teleconf are posted at:



Alan moved to accept minutes, Jacques seconded.


No opposition minute approved.

4         Status of Action Items


4.1      Action 052503-1 (Tom Rutt) pending

Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.


4.2      Action 060104-5 (Jacques) Pending


Action: Jacques, will propose further edits, on the FAQ for composability.


Still open

4.3      Action 060804-1 (Doug Bunting) closed


Action: Doug will propose text for  in 4.5 to clarify that when you cannot deliver due to rm fault, then send back a soap fault,


Complete, Text incorporated in 1.01I


4.4      Action 060804-2 (Jacques) closed

Jacques took an  action to describe the response reply pattern to work with our abstract model to sneak around to allow response correlation, and how it can be used for duplicate elimination. 


Jacques provided as contribution 1.01J.


Need further discussion with new technical issues PC 24 and 25


Jacques asked all to read these changes. 


5         Discussion of Issues and editorial Comments

The following issues list includes items which need further discussion:



5.1      Approval of Outstanding Editorial Comments Reflected in 1.01I


The following editorial comments need to be formally approved, to apply the agreed edits within 1.01I  to become a new Editor’s draft 1.02.




5.1.1      PC 16





Agreed not yet applied to draft

Sunil Kunisetty


Title: Namespaces and Schema location

Description: Need to change namespaces of our schemata to be the same as URL for final location on OASIS server. Also, may need to revisit the use of version 1.1 in our namespace as a _direictory_.Oasis has given us a document directory http://docs.oasis-open.org/wsrmWS security followed the convention of year and month.

Proposal: Re: [wsrm] Action Item status as of 6/3/04 From Sunil Kunisetty All namespaces qualified with both year/month and filename with 1.1 included in name

Resolution: Proposal agreed at June 08 meeting, incorporated in 1.01I


Action: Iwasa to incrrporate into next draft.

5.1.2      PC20





Agreed in principal not yet applied to working draft

Tom Rutt


Title: Editorial Cleanup

Description: Edits proposed in Detailed Editorial Fixes for Sections 1 - 4 of ED 1.01 andEditorial changes for Sections 5 onward to Draft 1.01

Proposal: accept all proposed edits with following exceptions agreed at 6/08/04 meeting: line 231: Do not add proposed definition for reply publishing, but instead to add new defintion to 1.01 text for publish as folows:"PublishAn abstract operation making an rm-reply available to its destination.For the various rm-reply patterns this entails:_ response reply pattern : publishing the reply requires sending the rm-reply on the response of the underlying transport protocol._ callback reply pattern: publishing the reply requires sending a callback message including the RM-reply information. _ poll reply pattern: publishing the reply requires making the RM-Reply information available to be returned to the sender in response to a poll request"Lines 961 thru LInes 965:At the 6/08 meeting it was agreed to change the second bullet. Doug B provided the following text for the second bulle in proposed wording for bullet in 4.5, Doug Bunting"When the Response RM-Reply Pattern is in use and the message cannot be delivered to the Consumer, the underlying protocol response MUST contain a SOAP Fault (in the SOAP Body) in addition to the appropriate RM Fault (in the SOAP Header). The sending RMP and producer expect either a complete response or a SOAP Fault when using the Response RM-Reply Pattern and this equirement satisfies those expectations. More details are given in the HTTP Binding section."Also: lines 949-951change the following sentence:"These protocol specific fault codes arereturned by the Receiving RMP within the response header element. Reliable Message Faults are carried in the SOAP Header, and do not rely on the SOAP Fault model for the following reasons:"to"These protocol specific fault codes are returned by the Receiving RMP within the response header element. Reliable Message Faults are carried in the SOAP Header, and do not rely exclusively on the SOAP Fault model for the following reasons:"Also:Lines 1273, 1339, 1421:Leave the following text from 1.01 as is: _due to a failure in processing the RM headers_

Resolution: Agreed in principal , included in 1.01I


No objection to Iwasa incorporating these changes.

5.1.3      PC21





Agreed in principla not yet in working draft

Jacques Durand


Title: Editorial corrections to 1.01

Description: Re: [wsrm] editorial comments on 101, J Durand

Proposal: Accept all of Jacques edits , with following change proposed for the introduction paragraph to Table 26:"This specification supports Reliable Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response operation types only. While a Request-Reponse operation can use any of the three RM-Reply patterns to receive acknowledgments or faults, a One-way operation SHOULD (for WS-I BP 1.0 conformance) only use either Callback or Poll RM-Reply pattern. Table 26 indicates recommended usage of reply patterns, for two WSDL operaton typed. An RMP MUST, at leat, support the recommended combinations in Table 26, for the reply patterns it supports. However, an RMP is not requried to disinguish WSDL operation types."

Resolution: Applied to draft 1.01I, not yet applied to Working Draft


Agreed to remove the sentence: from 1.02.

“However, an RMP is not requried to disinguish WSDL operation types.”


Jacques wants to have discussion on the awareness of correlation. 


Doug: I have a general concern about many versions in less than 7 days. 


No objection to incorporating edits, but removeing the paragraph.


All this text is subject to change in resolving the new issues.


5.1.4      PC22





Agreed in principle, not yet applied to working draft

Mark Peel


Title: Editorial comments on 1.01


Proposal: All comments except the one on Line 629 was applied to editing draft 1.01I. Full sentence is allowed to be introduced by Note: prefix in specifications. Also removing redundant "@foo attribute" to become "@foo" throughout.

Resolution: not yet in Working Draft


No objection to changes.

5.1.5      PC23





Agreed in principle, not yet applied to working draft

Tony Graham


Title: Editorial comments from Tony Graham

Description: Re: [wsrm] 1.1-1.02 editorial

Proposal: Agree to proposal, include in editing draft 1.01I

Resolution: Not Yet applied to working draft


No objection to acceptance.


Action: Iwasa will produce new version 1.03 as the new editors draft as baseline.

5.2      PC24






Doug Bunting


Title: Payload inclusion and MEPs other than request/response

Description: Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

Proposal: under discussion



·  Summary of WS-Reliability 1.01* issues discussed over past week
From Doug Bunting <Doug.Bunting@Sun.COM> on
13 Jun 2004 22:10:30 -0000


·  RE: [wsrm] Summary of WS-Reliability 1.01* issues discussed over past week
From Jacques Durand <JDurand@us.fujitsu.com> on
14 Jun 2004 03:26:10 -0000


Title: RE: [wsrm] Summary of WS-Reliability 1.01* issues discussed over past week


Solution proposed for (2a) below:


(removing the sentence  "However,  an RMP  is  not required  to distinguish  WSDL

operation types.")


We can remove this sentence if:


(1) we tighten the RMP definition (terminology):

Keep defining RMP as a "SOAP Node" (as defined in SOAP 1.2) as we did, but

remove the unnecessary and possibly misinterpreted "or a subset or superset thereof".

The RMP is the entity that has all functions needed to transmit reliable SOAP messages,

from the Submit/Deliver/Respond/Notify operations layer down to the wire.

(I think Doug made a similar point)


(2) we replace this sentence with a statement independent from WSDL, and getting

at the core of why the sentence above needed be removed:

"When invoking Deliver operation on a payload, an RMP is required to know whether

a related Respond invocation is expected or not."

(I would not mind narrowing further this statement to make it conditional to the binding

of Deliver/Respond to an underlying request-response MEP)




-----Original Message-----

From: Doug Bunting [mailto:Doug.Bunting@sun.com]

Sent: Sunday, June 13, 2004 3:13 PM

To: wsrm@lists.oasis-open.org

Subject: [wsrm] Summary of WS-Reliability 1.01* issues discussed over

past week


The following is intended to help get everyone caught up.


Most  of  this  derives  from  the abstract  model  in  our  specification,

resulting in  a number  of contradictions  between it and  the rest  of the

document, underscoring  a few over-general restrictions  or indicating some

under-specified  concerns.   While  some  of  the  issues  below  could  be

considered editorial, the bulk are at least minor technical concerns.


When  reading  the  following,  it   is  very  important  to  remember  the

distinction between  the capabilities the  WS-Reliability protocol provides

to  the producer  and consumer  and how  that protocol  maps to  use  of an

underlying  protocol.    Producer  /  consumer   interactions  occur  using

WS-Reliability  and  WS-Reliability  uses  SOAP messaging  (our  underlying

protocol).  The RMP  always has complete control over the  bits on the wire

though  the producer  and  consumer may  provide  the bulk  of the  message

content in a "pass through" fashion.


The example  "solutions" are provided  primarily to make the  issues clear.

While some  of these approaches may resolve  the issues, we must  come to a

common understanding of the problems before working on solving them.


1) The  existing descriptions of  the callback  and poll  RM-Reply patterns

    assume   the   underlying   protocol  supports   request-response   SOAP

    interactions but do  not explain what goes into  the underlying response

    of  the  separate  message  exchanges.   In  detail,  the  response  and

    synchronous  RM-Reply  patterns may  be  used  only  with an  underlying

    protocol that supports request-response (a less general restriction than

    currently specified).   For the callback and  asynchronous poll RM-Reply

    patterns,  we are using  only one-way  messaging; though  the underlying

    protocol  might support  request-response, we  should rely  on  the SOAP

    binding to describe  or profile how the underlying  response is used (or

    ignored).  For  example, we might  clarify that these  RM-Reply patterns

    involve two  separate one-way  SOAP message exchanges  (callback), three

    separate  one-way message  exchanges  (asynchronous poll)  or a  one-way

    followed  by a  request-response  exchange (synchronous  poll).  Such  a

    clarification might also address part of (2) below -- though at the cost

    of some generality.


Tom: is there disagreement we need to fix this problem.


Jacques: we currently assume a request/ response underlying  protocol, we are not talking about broadening.


Doug: Even with http we are using it in a one way fashion.  However we have not described it properly.  It states nothing about using the binding in a one way fashion.



1a) The  "non-essential assumption"  that the underlying  protocol supports

     request-response SOAP  interactions, stated  in section 2.1,  should be

     removed.  This is no longer a general assumption but something specific

     to two of our four RM-Reply pattern options.


Agree to remove as general restriction.  Need to fix this to be only the restriction which is actually required.


Doug: less about the restriction but more about we need to describe how to use the underlying protocol.


Sunil: from day one we had an implicit assumption that it would work on half duplex.


Doug: even for the cases where the general restriction is too strong, we are not leaving it


1b)  The  HTTP Binding  should  be an  instance  of  the general  semantics

     described in  the main body of  the specification and  not extend those

     semantics.   The current  section  provides examples  of semantics  not

     described elsewhere.  After resolving the areas left under-specified or

     over-generalized in the rest of the document, we must recheck section 6

     for conflicts with these semantics.  In addition, any transfer protocol

     responses that may  be unclear because we are  using a request-response

     underlying  protocol  in  a  one-way  fashion should  be  described  by

     reference to the appropriate SOAP over HTTP binding.


Doug: Some things are only described in section 6.  They need to be readdressed after we have the general semantics.


2) Section  5.2 is completely  about the  producer /  consumer interactions

    though some of its text has been applied to the RMP use of an underlying

    protocol.  The matrix  in section 5.2 states that  all RM-Reply patterns

    may be used with  consumer-generated payload(s) or application responses

    on  the receiving  RMP side.   However, the  callback and  poll RM-Reply

    patterns  provide multiple opportunities  to return  payload information

    (as they are  currently described, see (1) above)  and the specification

    does  not  describe  which  option  is  recommended.   Our  new  Respond

    operation  (possibly restricted  to specific  RM-Reply  pattern choices)

    must be mapped  to the underlying protocol at least as  far as timing is

    concerned.  We may also decide to further restrict when the consumer may

    invoke the Respond operation.


Doug: this talks about application payloads than can come back.  But we do not talk about these consumer payloads.  It does not quite work without specifying something more.  This is a problem and added words are needed.


Doug: One proposal was to return in immediate response.  There are multiple options, we are not saying how the responses will come back.


Jacques:  There are different expectations on table 5.2.   The table was just a summary of recommended usage of reply patterns to wsdl operation types.  There is not enough explanation before the table.  


Doug: I think this is getting into the solution space, we need to describe the possibilities in the document.


2a)  The sentence  "However,  an RMP  is  not requried  to disinguish  WSDL

     operation types."  [please note  new spelling errors] was introduced in

     a recent edit to section 5.2,  enshrining an assumption a few of the TC

     had previously made.  This  assumption contradicts the complete control

     an RMP  has over the  bits on  the wire.  The  consumer may or  may not

     provide payload  information (the  consumer interface may  be described

     using either a request-response or  a one-way operation type).  Even if

     the receiving RMP  is only passing the information  through, it must be

     aware of when to wait for the consumer to invoke the Respond operation.

     This sentence should be removed.


We removed this sentence.  However Jacques has proposed a new solution for this.  This sentence conflicts with the info the receiving RMP needs.


Already agreed to remove the sentence, and to resolve the problem indicated by Doug.


Need to discuss Jacques proposed solutions to this problem.


2b) The  one-way consumer  interface and Response  RM-Reply pattern  is the

     most  direct combination to  reliably deliver  one-way messages  from a

     producer "hidden" behind a firewall.   The matrix in section 5.2 should

     not  disallow this  combination.   While synchronous  polling at  least

     works, it always requires an additional round trip.


Doug: Sunil’s objections are mixing up restrictions at producer consumer level with underlying protocol level.  Ws reliability is a soap binding, but we should be able to map to underlying that does not require request/response interaction.  At an abstract level there are two soap bindings.  WS reliability offer to application level is a way to deliver and exchange messages.   Our sending and receiving multiple messages in both directions, regardless of whether producer and consumer are aware of those messages.


The WSDL doc which describes how to use our messages would be different than the one the user made.


Sunil: 5.3 is particular about WSDL one way operation type.  Send RM-reply in the same channe.


Doug: I am suggesting to send one way message at application level, you can use the response reply pattern.  The underlying response that will occur is an rm artifact that the producer is not aware of.


Sunil the no in 5.2 table is appropriate.


Doug: I am sorry, but for everything I have seen, section 5.3 is about the producer consumer interface view.  From its point of view it is about producer. 


Sunil: WSDL is for consumer interface period, it is not for RM information.  If a consumer operation is wsdl 1.1 one way operation, you cannot use response reply pattern.


Doug: lets move on, If Sunil thinks there is a need for a restriction here, lets talk about it on the email.




2c) The matrix in section 5.2 also was the first to introduce the idea that

     the consumer  could provide information intended for  the producer.  We

     needed to extend the abstract model to introduce this earlier and avoid

     a contradiction between the matrix and the model.  I believe this issue

     has become editorial as we discuss the details of the edits necessary.


Will get back to this.


2d)  When using  the Response  RM-Reply pattern,  the  immediate underlying

     response  may be  lost  and the  sending  RMP may  query  using a  Poll

     request.   Should the response  to such  a "spontaneous"  Poll indicate

     which  referenced messages  included consumer  payloads in  the earlier

     response?  The sending RMP might  "just know" a consumer payload may be

     available from  information the consumer  provides (WSDL, say)  or some

     other means; an  indication of a consumer payload  in the Poll response

     informs the sending  RMP directly.  The sending RMP  can already decide

     when a resend might be  necessary and any indications the receiving RMP

     provides would be a new extension to the WS-Reliability protocol.  Such

     an  extension would,  primarily, reduce  the size  of the  known subset

     requiring resends  since any a  priori information would  indicate only

     that a consumer payload had been possible.


Doug: when sending rmp uses request pattern, it may later use poll to querry response.  There is some additional info it might have to indicate a consumer payload was sent with the original response.   Because the sending RMP has some info about consumer payloads being possible, this might be an optimization.


Jacques: I agree we need to discuss this, but I do not want to extend the scope of what we mean by reliability




3) The  description of  duplicate  elimination in  section  3.2.2 does  not

    describe  the  content  of  either  the  immediate  underlying  protocol

    response nor an RM-Reply that may be sent later (in the callback or poll

    RM-Reply cases).   In particular, whether or not  consumer payloads from

    the response sent the first time  (in the case when the earlier response

    had  been  lost)   may  be  returned  during  this   iteration  is  left

    unspecified.  As Sunil has  stated, some have implementation issues with

    caching  payloads  in  the  receiving   RMP  though  this  is  the  most

    appropriate way to handle the  duplicate message.  We might thus avoid a

    new requirement but concentrate on ensuring caching is allowed.


Doug: we are not specifying much at all about how the receiving RMP needs to respond about a duplicate message.  How often the notify is called.


Tom: There are a lot of possible solutions to this problem.


Jacques: my last mail discusses about how we discuss this problem.


Talk about details of Jacques counter proposal in next section.


Doug: we are in the solution space about this problem, we agree there is a problem




3a) Sunil mentioned  in a private email that no RM-Reply  pattern at all is

     used unless an acknowledgement was  requested.  I have not searched but

     am  pretty sure  we have  not described  RM fault  semantics, duplicate

     elimination nor consumer payloads in this situation.  For example, will

     the  callback be  invoked or  the  poll include  any information  about

     successfully delivered messages when AckRequested did not appear in the

     original message?  I suspect we moved the ReplyPattern element out from

     under the AckRequested  to allow more generality here  but the existing

     text implies an RM-Reply is always publicized.


Tom: I agree there is clarification needed if poll  response in response reply pattern, would the receving RMP need to remember ack without ack requested.


Doug: we need to clarify this.


4) The  RM  Fault processing  model  described  in  section 4.5  previously

    attempted to cover responses to duplicate messages though the reader was

    not directed here from 3.2.2 "Duplicate Elimination".  I believe we have

    agreed  not to  lump  faulting  and responding  to  a duplicate  message

    together  in the  document and  have addressed  the editorial  issues in

    section 4.5.


agreed to separate the duplicate elimination as a separate issue.


4a)  Sunil has  outlined a  few  issues with  including a  SOAP fault  when

     returning an  RM fault.  If  I remember correctly, the  original reason

     for this addition was avoiding an  empty SOAP Body when the sending RMP

     expected a consumer payload.  If  we accept all of the restrictions and

     clarifications mentioned above (in (1) especially), the problem will be

     limited  to  use of  the  Response  RM-Reply pattern  (request-response

     underlying  protocol utilization)  with a  consumer  response expected.

     The SOAP  Fault would cause  the underlying protocol response  to match

     the  signature expected  in that  case but  may  cause interoperability

     problems  in other  cases.   Sunil  would like  to  avoid the  inherent

     redundancy of  a message containing both  SOAP and RM  faults.  He also

     points out that "send a SOAP fault" is not specific enough.


Need to clarify these points in the soap processing model.


5) The   specification   is   generally   vague  about   the   meaning   of

    "application-level"  and talks  about WSDL  primarily as  describing the

    producer /  consumer interaction without making  this distinction clear.

    In some  cases, WSDL operation or  MEP types are applied  at all levels.

    As a  relatively editorial matter, we must  clarify distinctions between

    exchanges  controlled by  the RMP  processing ("underlying  protocol" or

    SOAP  message exchanges)  and how  the  RM-Reply patterns  map to  those

    exchanges  and the  producer /  consumer interface  (sometimes described

    using consumer-provided WSDL).  In effect, the producer and consumer sit

    on top  of an RMP that  is (abstractly) implemented  using an underlying

    SOAP   processor.   That   SOAP  processor   provides  the   one-way  or

    request-response message deliveries used for the RM-Reply patterns.  The

    RMPs  effectively  provide  another,  higher quality  of  service,  WSDL

    binding that the producer and  consumer use to interact.  We probably do

    not need to include the SOAP processor explicitly in our model but we do

    need  to  be clear  throughout  or  document  what level  is  discussed.

    Primarily, section  5.2 will be the  main place in which  the producer /

    consumer interface  come to the fore.  And,  no, this is not  as large a

    change as it seems.


Doug: we need to add clarity in the document to fix this explanation.


Doug: I hope we do not have to change the HTTP bindings chapters.  We may not have to change the HTTP binding of our protocol.



5.3      PC25






Doug Bunting


Title: Duplicate message responses

Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html

Proposal: under discussion



·  RE: [wsrm] clarification on Respond primitive
From Jacques Durand <JDurand@us.fujitsu.com> on
14 Jun 2004 06:19:04 -0000


Title: RE: [wsrm] clarification on Respond primitive


I think we need to state clearly the problem we try to solve here, as it seems

to exceed the one summarized in #3:


(A) Are we trying to guarantee the delivery of the response in an underlying  request-response MEP,  ("Respond" invocation on receiving RMP)? (or of a complete request-response transaction?)

Which, as we have investigated long ago (study September 03), is not that simple and subject to severe implementation limitations, not just caching. I thought we had decided to leave it out for this release. (note that in such case, a duplicate generated by resending should be treated differently from a duplicate generated from network problem).


Jacques: the discussions on the Mailing list have been about A. 


Doug: in this thread you have described a related, but somewhat different problem.  Two ways for the receiving rmp to response can happen.  The sending RMP needs to ensure the notify is not sent more than ones. 


Tom: we need to add text about not having the notify sent twice.


Jacques: the respond and notify message flow is not subject to reliability.


Doug: I was no suggesting that.  There are many ways to get duplicate response.


Tom: we should allow the caching solution for the duplicate response, but we should not require.


Jacques: we had earlier proposed a reliable response.  We cannot guarantee delivery of response.


Tom: Are you concerned about the receiving RMP being allowed to send a cached response.


Doug; I would prefer recommended to cache, but I have not proposed a must for the cached response.  No one has suggested a three way handshake to ensure the response is received.  I am hoping to allow the consumer payloads to ride on the duplicate response.  I do not want to require a soap fault in this condition, which will prevent invisible reuse of cache payload.


(B) Or, more modestly, are we trying to avoid some side effect of acknowledging duplicates in underlying  request-response MEP, which translates into the receiving RMP sending back a response (to the duplicate) that looks like a valid message to the sending RMP (with an RM Reply, and whatever payload) but that the sending RMP

must NOT pass to its Producer ("Notify")? The safest way to do allow this filtering,

I believe, is for the RM Reply to tag the message ID in the RM Reply, as "duplicate" instead of ack. (That is what I was suggesting, though that is more than editorial...)


Tom: are you suggesting a new reply type, acked duplicate.  This would not be a fault.


Jacques: this is getting into the solution space.  We need to clarify the spec in this area.


Tom: I am not sure we need this new reply type.  We need to discuss it further.


Doug: I am not entirely sure that this new indicator would solve the problem.


Jacques I suggest we leave this for discussion.


NOTE:  messages produced by a Consumer via "Respond" could still have guaranteed delivery even if we don't solve (A). The problem lies in the underlying request-response MEP, so we don't have to tie - in our spec - the use of "Respond" with the response leg of such an MEP.

Note also that if a Producer could be notified - e.g. by a subsequent Poll - that its request has been well delivered (acked) even if the response is lost, that might be quite sufficient, and allow the Producer to take appropriate action, which may vary depending on whether the request was idempotent or not.


Jacques; where we bring value with WS reliability, is that an independent spontaneous poll, the sender would know whether the request was correctly delivered is valuable.  If the request/response failed should not depend on whether the response is delivered.


Tom: this needs to be discussed further on the list.






-----Original Message-----

From: Doug Bunting [mailto:Doug.Bunting@sun.com]

Sent: Saturday, June 12, 2004 8:30 PM

To: Jacques Durand

Cc: wsrm

Subject: Re: [wsrm] clarification on Respond primitive




On 11-Jun-04 14:11, Jacques Durand wrote:




> Now, here is a position on the duplicate issue:

> - The response to a duplicate - whether acknowledged or not - should never

> be passed through the WS stack of the sending side. It should be caught

> by the RMP

> and discarded. The Producer should never be aware of it, simply because

> the Producer

> in the first place did not / cannot have generated this duplicate ! (it

> has to originate

> at RMP level, because a duplicate Submit call on an RMP will translate

> into different message IDs.)

> - so the question is : how can the receiving RMP "mark" this response so

> that

> teh sending RMP will not pass it to the Producer?


This question implies an all-powerful receiving RMP that also has complete

control over the underlying protocol and can assure itself that no

duplicates or unequal delays will occur during message transfer.  The

sending RMP must be responsible for filtering duplicate RM-Replies it

receives and preventing redundant Notify invocations.  Such a requirement

is entirely reasonable since the sending RMP already tracks message

identifiers for which RM-Replies are outstanding.


Unless, of course, you have reversed our abstract model's identification of

the sending and receiving RMP?  In the model, the receiving RMP publicizes

information and "sends" RM-Replies to the sending RMP.


> Jacques





6         Discussion of Document Progression.


Tom: do we want a small team.


Jeff: lets use the full email list.


Tom: I am hearing that all discussion should be on the full list at this point.


Doug: the only time I have seen things moving off the mail list is to remove people to not see things that were not required for all to see.  I think that all should see the discussion.


Take the entire discussion to the list.


Try to make jule 15.


Full CD ballot ending before prior July 15 meeting.


Tom: we should try to meet July 15 deadline for submitssion.


Tom: Should be schedule two hour meetings on Tuesday starting at 530 eastern time.

7         Potential Vote for CD progression


Draft Not ready, due to new issues


8         Potential Vote for OASIS Submission for Member vote of CD


Draft no Ready, due to new issues


9         Frequently Asked Questions


Tom posted the following:


·  Approved FAQ set for WSRM TC
From Tom Rutt <tom@coastin.com> on 3 Jun 2004 13:57:21 -0000


This is low priority, will keep open

10   New business


Sunil will put new schemas on the draft folder..


Jacques: I would liked to talk about underling protocol.  Request response vs. one way is alternatives.  Doug has stated that one way can be done with http.  When we look at soap binding, all we have is one, http is request/response protocol we have to straighten up our terminology.  We need to be more precise here.  If we no longer make assumption of underlying request/response, we have to make the difference of bindings to one way underlying (say smtp), and the request/response underlying binding.


Doug: I am not sure what the best words are, but we can come up with proper terminology.


Jacques: I am pointing out things that need to be clarified in our messaging model.



Bob F moved to adjourn, Mark Peel seconded.



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