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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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

Subject: Prelim minutes for Thursday of RTP f2f.

the prelim minutes for thursday only are attached.

Please provide any corrections on these minutes and also the Wed minutes 
before Monday.

Tom Rutt

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

Title: Minutes of OASIS WS-RX Teleconference

Thursday Prelim Minutes WS-RX F2F meeting

RTP March 23, 2006

8         Agenda Tuning

Sanjay presented the following draft agenda


9:00-11:00 Anonymous URI and Offer - review of the Interop Scenario 2.4

Paul F to present issues.


11- 11:15   Acceptance of any new issues


11:15-12:00 Review and update of State Tables


13:00 - 13:45  Application Notes discussion


13:45-14:45 Planning

Please see note: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00151.html

- Editors next steps

- CD4

- Ballot for PR

- Public Review

- Future distributed and F2F schedule


15 - 16:00 Discussion of new issues


Marc G asked where issue 89 will be discussed.


Sanjay: that was intended to be part of the anonymous URI and offer discussion.


Bob F stated the state Table discussions could be put offline with a small team, since the issues are not contentious,.


Jacques stated the application notes discussion could be less than ½ hour.


9         Discussion of Issue 89


When an AS uses an RMS to reliably send messages to an RMD, the RMS will need to be able to resend the un-acked messages at will. If the AS uses a target URL or wsa:To value such that the RMS can not, at its own discretion, initiate the (re)sending of messages then the RMS would be severely limited in its ability to complete its job. To this end the RM spec should discourage the use of wsa:To values that would put the RMS in this situation, like the anonymous URI. Of course, there may be times that using the anonymous URI _and_ RM can work and so we shouldn't totally ban the use of anonymous URI but we should make people aware that w/o some other mechanism, a generic WSA+RM soap stack would not be able to support this. Note, that while this is phrased in the context of wsa:To, for replies the RMD becomes the RMS and the wsa:ReplyTo becomes the wsa:To - so it would mean that we'd, implicitly, be discouraging the use of the anonymous URI in wsa:ReplyTo when people would want responses sent reliably.


Paul Freemantle gave a presentation on Anonymous URI and Offer - review of the Interop Scenario 2.4


Paul talked about 2 scenarios:

  • Scenario 1 _ reliable http request with anon reply to and non reliable http response.
  • Scenario 2 – Reliable http request with anon ReplyTo and reliable http response using offer.


Doug D stated there is a scenario 3, non reliable request with reliable response.


Paul stated that if a server receives a create sequence with anon ack to and anon reply to with an offer, it could refuse to create this sequence.


Matt: lets look at the scenario, then discuss the marker that signals its presence.


Marc G asked how this relates to I089 restrictions.


Tom R: the presentation is about anonymous reply to with an offer at sequence creation for a reliable response.


Paul F: for scenario 2.4 the request must be replayed to stimulate receipt of a lost response.


Paul F : there is one issue that you cannot terminate an offered sequence, since it is a two/way operation in reverse.


Paul F::Another potential issue is that the server has to echo the response for a duplicate message before it drops delivery of the duplicate to the AD.


Paul F: this scenario involves polling for the response, and currently the only way to do that is to replay the response.


Paul F: to replay the client must keep the request after it is acked, so it can replay it.  One way to do that is for the client to know that this scenario is in place, knowing the mep.  However this would not work for a gateway style implementation, which does not know the mep in use.


Paul F: another was would be for the server to change its acknowledgement behaviour if it knows the MEP.


Anish: Is there an assumption that a co-related request response is tied to a single http exchange.


Paul F: yes, since otherwise it would break ws-addressing.


Anish: if you constrain the lower level protocol behaviour based on a higher layer MEP, this seems to be problematic.


Paul F proposed an additional solution mechanism: the client can poll rmd.either

·        Ack request with empty body, signals resending the response in return. (a hack with several problems)

·        Special “get response” message with offerSequenceID in header


Paul F: the get message is better, because it eliminates the need for the server to correlate messages in sequence.


Paul F: the response has two relatesTo, one to the get message the other to the original message.


Doug:D: the polled response is a response to the get request, and a reply to the original message.


Bob F: the echoed message response is to the get request, not the original message.  It should not use two relatesTo elements.


Peter N: we need two relates to. They could have different relationship type.


Tom R: we could define our own relationship type for the reference to original message: correlation, say wsrm:replay.


Anish: anonymous semantics for soap http binding the response has to be sent on same response channel.  But in our case there is a failure and you never got a reply.  The get message is a new message, and its reply to can be whatever is required.


Marc G: I am concerned as to our references to ws-addressing.  Does this compose to the submitted version of ws-addressing.


Tom R: I think it is better to give two relationship types, because the response to the get does not obey the semantics of an anonymous reply to the original message.

5.1.2 wsa: soap binding spec quote

When "http://www.w3.org/2005/08/addressing/anonymous" is specified for the response endpoint and the message is the http://www.w3.org/2003/05/soap/mep/InboundMessage property of a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts], then any response MUST be the http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same instance of the SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts].


Gil: but it would be better to have the infrastructure see the message as a response to both the original message and the get message. 


Anish: since there was a failure this text does not apply. I could live with a new relationship type URI, but do not think it is necessary.  If there is a failure nothing stops me from doing extra things with that response message.


Glen D: this perceived restriction is at soap mep level..  Application mep semantics can add extra things.  The use of WS-RM can add additional paths for the reply channel.


Umit: I agree there may be a loophole in wsa which we can exploit.  However, I really do not like changing semantics without minting a new URI.  Introducing polling semantics with anonymous uri needs to be adequately defined.


Paul F: we need to take straw poll on preferred approach.  Is there support for the get message approach without minting new URIs.  The replay should be able to keep the original relationship element as the original response.


Glen D: do you mean both requests use anonymous replyTo, and the replay response will have two relationship elements with the relationship type WSA: reply.


Paul F: yes that is the question for the Straw poll.  Who thinks this does not break WS addressing.

Does not break: 7

Do not know: 7

Does break: 2


Chris F: this case does not break ws addressing.  However that is the wrong question.  I think it is legitimate, if you attempt to respond anonymously and fail, to replay.  However I still see a valid requirement for a new URI for the original reply to (this should be change to “multipleRetry” anonymous.


Tom: if we had this we do not need a separate get message, since the client knows it is playing the game, and can buffer the original request until it gets the response.  It can use the replay of the message itself as the poll for the response replay.


Chris F: the application does not know anything about wsrm specifics, and URIs.


Paulf F: straw poll three options

0)      do nothing

1)      forbid anonymous reply to with offered sequences (don’t support scenario 2)

2)      Fix Replay model without adding get message

3)      Support replay using get message.


Option 0 – none

Option 1 -  1

Option 2 – 4

Option 3 – 11


Ø  Action: Paul F will produce a detailed proposal for i089 with usage of Get Message.


Ø  Action: Marc G will produce a detailed proposal for i089 by fixing normal replay mechanism.


10   New issues raised since yesterday

10.1Bob F new issue


Bob F raise new issue: http://lists.oasis-open.org/archives/ws-rx/200603/msg00185.html


Modify definition of SequenceAcknowledgement:Final to reflect accurate ending delivery capability status.



The protocol defines the SequenceAcknowledgement:Final element which contains the final summary of message acknowledgements at the closure of a sequence. It is assumed that the RMD has taken responsibility for all messages that have been acknowledged.  Depending upon the operation of the RMD and its interface with the application, Messages that have been previously acknowledged as received by the RMD, may never be deliverable.  One such case of note that comes to mind is the situation of a message sequence that is being delivered in-order to an application which is closed at the time when one or more gaps that may exist in the sequence.  If this situation occurs, the RMS will have incorrect information concerning exactly which messages have been or will be deliverable at the conclusion of a sequence.


Note that there is nothing in the spec that states what the RMS is to do with the information contained in SequenceAcknowledgement:Final.  This proposal does not add any such statement, but it does permit the information to be potentially interpretable.


Target: core



Reference Core Spec CD03

insert after line 613:

SequenceAcknowledgemnt:Final shall identify only those messages that have been delivered or which the RMD has taken responsibility for delivery without regard to the previous acknowledgement status of any message.


State Table impact: None


Doug D: this is reopening the issue of DA.  This is regarding delivery beyond RMD.


No objection to accept as a new issue.


10.2Semantics of Nack




The description of Nack implies but does not clearly state that a Nack acknowledges messages received of a lower sequence number.








Ref spec CD03


Insert in line 621 after “by the Nack.”


Receipt of a NACK by the RMS implicitly acknowledges all messages of sequence numbers lower than the lowest sequence number contained in the Nack or Nacks.


State table impact: none


No objection to raise as new issue.


10.3Misplaced Guidance on Fault Handling


Title: Misplaced guidance on fault handling




Line 566 CD3 WS-RM spec (SeqAck section 3.6) reads:


If a non-mustUnderstand fault occurs when processing an RM Header that was piggy-backed on

another message, a fault MUST be generated, but the processing of the original

message MUST NOT be affected.


First point, this text isn't very clear. Second, it is IMO misplaced. It really should be called out separately

as it applies to more than just SequenceAcks.




This guidance is in the SeqAck section and really deserves to stand on its own as it applies to any

RM header block that is piggy-backed on a message unrelated to the Sequence.


Target: core




Strike sentence beginning on line 566, through line 568.


Insert, after line 232:


When processing of an RM protocol element generates a fault and that RM protocol element

pertains to a Sequence that is otherwise unrelated to the message in which the protocol element is contained,  

(i.e. the RM protocol element is a SequenceAcknowledgement or AcksRequested element) the receiving endpoint MUST continue

normal processing the message unless the generated fault is a SOAP MustUnderstand fault.


After matter:


Note that this says nothing about transmission of the generated fault. I personally believe that we

should leave well enough alone, however, I recognize that this MAY present interoperability

issues, especially in the case where both the [reply] endpoint and the [fault] endpoint are

anonymous. I COULD see adding guidance that says that when the above criteria are met

that the endpoint MUST NOT transmit the fault to the anon endpoint UNLESS there is

no response message to be transmitted


No objection to raising as a new issue.


10.4Description of sequence element


Title: The description of the <Sequence/> element could use some wordsmithing.


Description: The description of the Sequence element could use some wordsmithing.


Justification: It currently says nothing of substantive meaning.


Target: core (CD3)




Change line 504 from:


This is the element containing Sequence information for WS-ReliableMessaging.




This protocol element associates the message in which it is contained with a previously established RM Sequence. It contains

the Sequence's unique identifier and the containing message's ordinal position within that Sequence.


No objection to raising as new issue.

10.5Chris Miscelaneous


Title: editorial tweaks




suggested editorial tweaks


Target: core (CD3 WS-RM)




change line 141 from:


The protocol supports reliability features which include ordered delivery, duplicate elimination, ...




The protocol supports reliability features that enable ordered delivery, duplicate elimination, ...


Change line 143:


In any case the wire protocol does not change.




Regardless of which of the reliability features are employed, the wire protocol does not change.


Change line 218 from:


associated acknowledgement may have been lost.




associated acknowledgement might have been lost.


Line 337: text is BLUE, should be black.


Change line 370 from:


If the RM Source wishes to close the Sequence then it sends a




If the RM Source wishes to close the Sequence, then it sends a


There are numerous places throughout the specification where the term "Sequence"

uses lower-case "S". I believe that all uses of the term Sequence should be typographically

consistent and use a capital "S".


s/sequence/Sequence/g where the term is used as a noun.


I also spotted a couple of instances where the term RM Source used a lower-case "s".


s/RM source/RM Source/g

s/RM destination/RM Destination/g


Change line 534 from:


The RM Source may request an acknowledgement




The RM Source MAY request an acknowledgement



No objection to adding as new issue.


11   Plan for progressing State Table changes


Bob F: Matt gave a contribution to fix and clarify the state tables.  Matt, myself, and Tom Rutt will work on a more complete proposal for the amended state tables.


Matt: we could have a contribution ready by the next teleconf call, on April 6.


Ø  Action: Matt, Bob, and Tom will provide an amended state table before the April 6 teleconference.


12   Interop SC report

Paul F: I believe the interop SC should provide a report.


Bob: have corner cases been exercised?


Stefan: we have just done the easy things to date.


Doug D: the report should show who participated, but the result details should be anonymized.


There was no objection to the Interop SC providing a report.


13   Issue 42 resolution


Issue 042 which ws-addressing version


Bob WS-Addressing has achieved Proposed Recommendation status, with the AC comment period ending April 18.




On or before April 20, update the ws-rm specification to refer to the W3C's current WS-Addressing version.


It would be good to have the next interop event on the new spec since there is diminishing doubt of its near-term acceptance.


Paul C: Perhaps rm could refer to the input spec as well as the W3C output spec of ws addressing.  This could be the same as referencing both versions of SOAP.


Jeff M; why would be want to do what Paul C suggests.  There are big differences in PR version from input version.


Paul C:where are there differences.


Tom R: The epr format is different.


Paul C: we should not orphan customers currently using the input version of ws-addressing.


Anish: One main difference is the semantics of anonymous URI.  In the input version the anon URI is meant to allow pointing at devices behind a NAT.  Now anonymous is defined by the binding and not the core.


Chris F:  We should not prohibit compositions with other versions of addressing.  In the spec, where a normative reference is required, we should use the new version (e.g., epr schema type used in our message schema).


Dave O: While I can see a reason to support both versions, I realize that this can make people slow in moving the the new spec.  This is now occurring with Soap 1.2.  At some point the industry needs to make a decision to support just the w3c version.  This provides an opportunity to show commitment to moving forward, and people should consider this as a rationale for supporting just the new ws-addressing spec.


Umit: Is Paul C suggesting use of both ws-addressing specs at same time, or just to support transition from old version to new.  Is the old version to be a normative reference.


Paul C: RM can reference both ws addressing specs.  I think profiles can deal with the details of supporting only one version.  I prefer to leave the option in the OASIS spec.


Umit: I cannot agree with requiring support for both versions of ws-addressing.


Paul C: we intend to support both implementations of addressing with ws-rm.  I would like to have the spec facilitate both.


Paul F: I believe non of the interop participants had problems with using 2004 version.


Doug D: we agreed to do that, it is not that we had no problems.


Paul F: I believe it is ok to refer normatively to both specs.


Tom Rutt: Companies can do anything they want to support migration for their customers.  However I see no way to allow two epr formats supported as normative conformance to this spec.


Bob F: I move we reference the new w3c spec, leaving reference to the prior specification, but deprecate its use.  This allows continued claims of conformance for the old spec.


Failed for lack of a second.


Paul C: with respect to Tom Rutt’s concern, we would have to go to extreme cases to support one or the other.  Supporting both namespaces will make life difficult for implementers.  I am changing my position, and recommend that we  substitute the w3c namespace for WSaddressing.


Paul F moved that the namespace be changed to the new w3c ws addressing spec.  Tom Rutt seconded.


§    No objections issue 042 closed by changing reference to the PR w3c namespace and to refer to the new spec.


14   Discussion of Application Notes Document

Jacques presented the latest version of the draft application notes document, posted as:



Jacques stated that he wants to separate discussion of the detailed contents of the document (which is preliminary) from discussion of the need for the document itself.


Jacques pointed to the ws-rf TC application notes document.


Such a document can aid people in the understanding of the base specification, and can include material which is considered out of scope of the spec.


Paul F asked how much work was done in the WS-RF tc on this document.


Doug B: in the wsrf case three editors did most of the work.  The TC was involved in the review.


Paul F: as member I have no problem, but as chair I have concerns that this may take too much time.


Tom R: if the examples raise controversy, then the time should be taken to discuss them. If the spec is stable and complete there should be no great effort to review it.


Paul F: I would like to ensure that this document does not delay progression of the Base specification.


Jacques: if it takes too long, the TC can postpone or delay it.  It does not have to be put on a critical path.


Sanjay: we could initate a subcommittee to produce such a document.


Paul F: If it is just an effort done by some members, with a goal to produce a draft CD for vote by the TC.  I do not want a schedule associated with this document.  It would be incumbent on the proposers to produce a document which can be voted as CD.


Doug D: from a quick reading, I have a concern that this states things that are obvious from reading ws addressing.  If it is merely repeat of what ws addressing already says, rather than a set of guidance to document things which had controversy in the TC, I cannot support it.  If it profides guidance on things this TC has grappled with (like use of anonymous with offer) then I could accept it.


Jacques gave a summary on the contents.  The focus is on how to identify different ways the message patterns may be used.  They involve bindings to underlying protocol in ways that might be constrained (e.g. case where the client can only initiate connections).  


Marc G: I share some concerns with Doug D on content.  I do not think delivering it on a separate non CS track warrants the same level of review as the core spec.  I am concerned about the scheduling impact this will have on the spec.  I do not want to be here another year.  We should be able to stop once we reach CS on the base spec.


Jacques: we can get some experience information from WS-RF on how much work this entailed.  It does not have to take a long time.


Paul F: I agree with Marc G that we delay the progression of the spec.  I think a Primer might be a better document.  Perhaps we can take the interop scenarios, clean them up and document what we learned during interop exercise, as an alternative approach.


Paul C: I cannot discuss this without the content.  But I see it talking about binding examples.  Is the problem that the spec is not clear how to do the bindings.  If it gives general advice to do things different that our product, that will impact interop with our implementation.


Tom: what if one implementation only supports synchronous reliable request response, while another only supports asynch one way.  Can they interoperate.


Paul C: my concern is that making these bindings visible, may make some think that is the preferred way to do things.


Gil: one example is the deadlock problem found during the interop..It would be a shame if that knowledge disappeared after this meeting.  Having a place to allow people to read and benefit from our experience is usefule.


Paul F: the benefit to focus this on the interop document is that it is focused on our tc process.  The schedule for this would be tied to the interop work.  The only thing to add for CD is to add the additional notes to give guidance to people, on this.


Doug D: without a document to look at we are talking about nothing.  In order to move this along, concerns have been express already.  It should be up to them to see if they can cross the threshold to make this a useful document.


Tom: do the interop scenarios cover both cases of using ack requested for stimulating acks, vs having the rmd send acks at normal intervals.  In general I think Paul F idea is good, to have the application notes reflect what is learned in the inteorp scenarios.


Paul F: the scenarios make no such prescriptions, the idea is to test if different assumptions made by the implementations can cause interop problems.


Tom R: can the interop SC post in an accessible place the interop scenario document.


Ø  Action: Paul F will post a version of interop Scenario document on Kavi for access by entire TC.


Sanjay: straw poll, should this be pursued further with a second example.

Yes: 7

No 0



Paul C: I do not know what my position is. I do not know whether it would affect interop. I do not think the TC has stated it is for it yet.  All I can conclude is that perspective authors can come up with a new version to let us decide.


Tom: once Paul F posts an accessible version of the interop scenarios Fujitsu can try to make the application notes more related to those scenarios.


15   Planning Disussion

Paul F posted the following timeline:

March 31st  Next WD ready for review

April 6th Ballot for CD/PR

April 14th  PR begins

June 13th = PR ends

June 19th = Final pre-CS draft ready for review (with non-substantive


June 29 = CS ballot starts

July 6th = CS ballot ends

Chairs to run around

July 14 Submission to OASIS


Paul C: are we going to public review before we resolve all our our own issues?


Peter N: the first public review is 60 days, however the subsequent ones are allowed to be much shorter.


Chris F: If we do not have 89 done, we should not go to public review.  Other, non consequential issues may not be as important.


Paul C: If we are going to the public for review, it is not good to do that with outstanding issues, (with perhaps a note to not comment on them because they are being worked).  To avoid excessive effort to track public comments, the editorial issues should already be resolved.


Marc G: I thought that the goal of this meeting was to resolve all issues so we could go to public review.  I always thought we would resolve all issues before putting out for public review.


Chris F: we need to make sure we address all the technical issues, and in preference to resolve the editorial issues. If we scheduled a vote for cd in a week, which prompts a slew of editorial comments, then we are probably not ready.


Jeff M: I hear agreement on the pre conditions for public review.


Chris F: want deadline for TC member comments to be first.


Timeline after discussion

·        N         All issues closed

·        N+1     Next WD x ready for review

·        N+2     Deadline for TC member comment

·        N+4     New WD y

·        N+5     Ballot closed CD / WD y, (with conditional Public review ballot)

·        N+5.14  PR begins

·        M = N+14  PR ends (interop 2 during back end or PR)

·        M+1  Final pre-CS draft ready for review (with non-substantive changes)

·        M+2  CS ballot starts

·        M+3  CS ballot ends, Chairs to run around

·        August 14  Submission to OASIS


Chris F: we might consider a Face To Face in the May time frame (perhaps with the OASIS symposium).  


Paul C: does this schedule give the interop SC enough time for the next interop?


Paul F: from a spec perspective the Interop SC has sufficient flexibility.



Paul F: due to change to adopt w3c addressing, I move we change the namespace for schema in our next CD, seconded by Chris F.

Chris F: we can now pick a namespace for the next CD, and keep it stable until it changes.


§    No objections, motion to change namespace passed.


Ø  Action: have editors get a new namespace for next CD, given the use of ws addressing PR


Anish: there is a possibility for change in w3c from PR to rec.


Jeff M : lets not worry until it occurs, the worst that will happen it we have to change the namespace.


Tom: When will the next F2F be?


Paul F: it should be just before the Public Review.  We cannot set the date at this time.


Paul C: it is possible to get thru to CS without another Face To Face meeting.  This would require action items for each issue to ensure we have proposals for discussion on conference calls.


16   Discussion of issues Resumed




I104  Mixing Soap.


I105 Seq acks after close

I106 Final Deliverable


I107 Acks Nacks Nacks Acks


I108 guidance on fault handling


I109 Description of sequence


I110 Chris Editorial Rant part 1.



16.1I109 Description of sequence



Chris moved, Anish seconded to accept proposal Proposal:

Change line 504 from:


This is the element containing Sequence information for WS-ReliableMessaging.




This protocol element associates the message in which it is contained with a previously established RM Sequence. It contains

the Sequence's unique identifier and the containing message's ordinal position within that Sequence.



§    No opposition, issue 109 closed by accepting proposal.



16.2I107 Acks Nacks Nacks Acks


Amended proposal after discussion and wordsmithing

Ref spec CD03

Insert in line 621 after “by the Nack.”

“Receipt of a Nack by the RMS implicitly acknowledges all message numbers within the sequence lower than the lowest message number contained in the Nack or Nacks.”


Doug B: I am concerned that the RMD can only use the NACK if there is a single gap.


Chris F: the spec allows multiple nack elements.


Doug B: the schema seems to disagree.


Doug D: the schema says max occurs = unbounded.


Doug B: the schema in the PDF version is wrong.


Doug D: the “unbounded” decoration is on the next line, since it wraped.


Sanjay: why cannot nack 2 and nack 4 mean receipt of 1 and 3.


Gil: we were motivated by the rms being able to get a snapshot of the entire sequence, which was resolved by not using Nack.  It seems we might have removed the motiviation for changing the semantics of Nack as already stated.  I think we should close with no changes.


Chris F: I still think there is value in understanding that a Nack explicitly resolves the earlier message numbers.  I am happy with the proposed text above.  I could also see a use case for stating that all non nack messages lower than the highest in the nack list are received.  


Paul F: with the ack requested agreement yesterday, I agree with Gil we do not need to constrain the semantics of Nack in this way.


Anish: I agree with Gil.  A nack just a nack, and should not be constituted as implying receipt of other messages.  This new requirement will cause more complex implementation, in that it takes a freedom away from the RMD.


Bob F: When I read the Nack text it states it allows the rms to do gap analysis.  In the way that it is written, the other messages have been received.  An alternative to the text above, would be to clarify the nack text by removing all words about gap analysis.  Just state that it stimulates the retransmission of the request.  It should not be closed without action.


Paul F: striking the seconde sentence  (lines 616 to 618) does the job.


Anish moved (seconded by Matt) to strike second sentence (lines 616 618 in CD 3) “This element … in certain environments”.


§    No objection to closing issue 107 with proposal to strike sentence on lines 616 thru 618.


16.3Issue I108 Misplaced guidance on fault handling



> Strike sentence beginning on line 566, through line 568.
> Insert, after line 232:
> When processing of an RM protocol element generates a fault and that RM protocol element pertains to a Sequence that is otherwise unrelated to the message in which the protocol element is contained,   (i.e. the RM protocol element is a SequenceAcknowledgement or  AcksRequested element) the receiving endpoint MUST continue normal processing the message unless the generated fault is a SOAP MustUnderstand fault.


DougD pointed out that the same text is present under Request Acks section.


I would therefore amend my proposal to add:


Strike sentence beginning on line 537 and continuing through 539.


There was considerable discussion on the new proposed text.


Ø  Action: Chris F and Anish will propose appropriate text for resolution of I108.


16.4I 110 Chris F Editorials.


Line 141 change agreed as Editorial.


Line 143 change agreed as Editorial


Line 218 change agreed as Editorial


Line 337 change agreed as Editorial.


Line 370 change agreed as Editorial


Agreed to consitently use “S” in word sequence when used as noun.


Agreed to change on RM source to RM Source


Agree on Line 534 issue as editorial.


Paul C moved to accept all proposed changes for I104 as proposed by Chris F, seconded by Bob.


No objection issue 104 closed with proposed change.



16.5Issue 104 mixing soap and/or wsa versions


Title: Mixing SOAP and/or WS-A versions



You may end up with both SOAP 1.1 and SOAP 1.2 across a sequence. The same applies to WS-A versions.




Suppose the RMS starts a sequence in SOAP 1.2. The RMD may initiate messages (e.g. SequenceAcknowledgement). Those could be in SOAP 1.1.

Should we allow mixing SOAP types? Probably not. We could recommend that the SOAP style in place for the CS should used for the rest of the sequence.


Target: core

Type: design




From CD-3.


between lines 241-2 insert new para:


The SOAP and WS-Addressing versions used for the CreateSequence message SHOULD remain in place for all future interactions between the RMS and RMD, including messages initiated by the RMD (e.g. <wsrm:SequenceAcknowledgement> and faults).


Related issues: None


Paul F stated he is not happy with the exact wording of his proposal above.


Chris F: soap 1.2 has a clearly defined fault for this case.  It would be good to nail down what soap version is used for our protocol elements.  However we should strongly discourage supporting multiple soap versions on the same sequence..


Doug D: Since sequence can span multiple client endpoints, there is a use case for multiple soap versions on a sequence.  In a gateway implementation, an rm manager should not have to change soap version for reliable messages its receives and adds rm headers for.


Paul F: I prefer separate sequences for each soap version in this use case.  Do not mix soap versions within a sequence.


Paul C: I propose that all messages in a sequence SHOULD use the same soap version as the create sequence.


Anish: both soap 1.1 and soap 1.2 have version mismatch faults.


Chris F: I prefer to keep a single version of soap for an entire sequence.


"The SOAP version used for the CreateSequence message SHOULD be used for all subsequent messages in and for that Sequence, send by either the RMS or the RMD.”

Tom: why is it a SHOULD rather than a MUST.


Doug D: I want SHOULD, to enable some specific use cases I have in mind.


Considerable discussion ensued on the rationale for SHOULD in the requirement.


Doug D moved, Matt seconded to add new parat: "The SOAP version used for the CreateSequence message SHOULD be used for all subsequent messages in and for that Sequence, send by either the RMS or the RMD.” between lines 241 and 242.


§    No objection motion to close 104 with proposed change approved.


Chair moved to thank IBM, with special recognition to Marc Comer, seconded by Paul C.


§    Unanimous consent to thank IBM for excellent hosting arrangements.


16.6I105 – Sequence acks after close.




From CD-3.

At lines 373-377 replace the above text with:


"Upon receipt of this message, or subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST include a final SequenceAcknowledgement (that MUST include the <wsrm:Final> element) header block on any messages *associated with the Sequence* destined to the RM Source, including the CloseSequenceResponse message *or* on any Sequence Fault transmitted to the RMS."


The added/modified text is within * *.


Chris F moved to accept proposal above to close i105, seconded by Gil.


§    No objection i105 being closed with proposed change.


16.7Owners for proposals on open issues.



I 89 (Paul F, Marc G) next call,

I 96 – (Matt Lovett) next call

I105 – seq acks after close.(proposal already formulated)

I106 – final Ack (Bob)

I108 Guidance on Fault handling (Chris ) next call.


Meeting adjourned at 4:00 PM.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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