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 second day of f2f meeting

Prelim minutes for second day of f2f meeting attached.

Please provide corrections to the entire list.

Tom Rutt

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

Title: Day 2 WS-RX TC Face to Face Prelim Minutes

Day 2 WS-RX TC Face to Face Prelim Minutes


12   Issue Resolutions Continued

12.1I058 State machines

Bob F presented his contribution on State Machines





Bob F stated we continue on the exercise of State tables, deferring the decision about inclusion in the final spec until later.


The safety of sequence termination is in question.


Tom Rutt presented his contribution on State Transition Diagrams.  He stated that there are separate state machines for:

  • RMS view of a sequence
  • RMS view of a message processing
  • RMD view of a sequence
  • RMD view of a message processing


The Group initiated a Discussion of Potential new issues resulting from “?” in Hitachi State Tables.


Column J of Hitachi RMS state table:  can sequence terminated fault be send by RMD after the sequence is terminated.


Ø  Action: Tom R will raise an issue regarding sending Sequence Terminated Fault after the sequence has been terminated.


Row 16: SequenceClosedFault row in RMS table has ? in columns E thru H.


Ø  Action: Matt will raise an issue regarding what RMS does when receiving sequenceClosedFault while in non terminating state (Row 16 in Hitachi State Table).


Row 15: what does RMS do when it receives a sequenceAck(final), when the RMS thinks the sequence is still active?


Action: Tom will raise an issue regarding Row 15 of Hitachi state table.


Discussion of Column I of RMS, depends on the resolution of the new issue 78, 79 on whether Terminate sequence is two way. 


Discussion of what RMS (or RMD in response to a callback) does when UnknownSequenceFault or SequenceTerminatedFault for a sequence which the RMS thinks is active – It should go into sequence terminated state.


Ø  Action: Bob F will raise an issue regarding the rows of RMD and RMS state table for events receiving unknownSequenceFault or SequenceTerminatedFault while it thinks the sequence is active..


Marc G moved, seconded by Chris, to have the TC thanks N Yamamoto San for preparing the Hitachi State Tables.

§    Motion Passed, TC thanks N Yamamoto San for his work on the Hitachi State Tables,


I was agreed to have TC members discuss other aspects of the state tables on the email list.


Ø  Action: Bob F will post the State tables to Kavi as Member document, with an indication of which working draft document revision the tables correspond to.  Also have a section to record issues to be resolved..

13   Interop SC Discussions

13.1Scheduling discussion

Discussion of CD progression activities and Interop event.


Paul F proposal:

  • clockStarts - TC approves next CD
  • +4 wks - send draft scenario doc to TC
  • +2 wks – Final date for feedback from TC on Doc
  • +2wks –Updated based on feedback
  • +6 wks – week of interop event


Paul C: we should wait for initiating Public Review after our interop demonstration.  I think the March TC meeting should be the interop event.


Question of who can participate in interop event.


Jeff M: anyone participating in interop event should be a TC member.


Paul F: what about feedback.


Jeff M: there is an OASIS feedback license, allowing feedback without requiring  participation as TC member.


Paul C: we can give an email address to send public comments to.


Paul F asked if March F2F is feasible for interop event.


Straw Poll:

Number of possible participants in interop event, by company – 9.

Number of possible participants who would likely support March for Interop event -  6


Jan 5 is next TC Teleconf.


Marc G: I can work with Doug D to see if we can have a first draft interop scenario document for TC review by Jan 5.


Refined proposal:

  • 15 Dec - TC approves next CD
  • 5 Jan - First draft scenario doc to TC
  • 19 Jan – TC meeting to discuss feedback on First Draft
  • 2 Feb – Update based on feedback, send out official invites
  • March F2F –Interop event


Chris F: we should have the next CD based on the resolved issues from this F2F.


Paul F: can the scenario doc be written before the CD text is posted?


Marc G: yes, based on the know resolutions of the issues from this F2F, we can work on interop Scenario concurrent with the finalization of the next CD.


Chris F: can we agree to base the interop based on decisions made at this meeting?  I would prefer that we base the interop scenario on a CD version of the spec.


Paul C: we should make one schedule just for interop event.  We could have a second schedule which has the CD publication.


Definition of Successs


Paul C: success defined attaining confidence on the ability to produce interoperable implementations of spec.


Paul C: the issues on the spec which result from the interop should be the primary public output of the interop event.  The individual company problems can remain anonymous.


Anish: If a company does not want to publish result regarding their implementation, that should be considered.


Jeff M: nothing that is done in an OASIS TC is private. 


Chris F: I suggest it be all anonymous, or none anonymous.


Paul F: lets start with assumption that results publication are public, but members can ask later to revisit the decision.


Doug B: do we need to cover all three policy values:

  • Assertion of use of WS-RM,
  • MaxMessageNo,
  • AckInterval


Paul F: we could have a set of tests which do not depend on policy, and specific tests of policy assertions.


Paul C: the interop scenario should make it clear what aspects of the configuration are out of band to the protocol.



  • Minimum bar for success
    • 3 participants
    • Report plus issues
  • Both specs – yes but with clear definition of out-of-band agreement
    • Plus test with and without wsdl wsp
  • Type of event – virtual an f2f
  • Publication of Results – Public
    • Report, Matrix of Results, if fail why?, issues created


There was a question on which days of the meeting in March will be for the interop event, and whether it would require a second meeting room from TC spec discussions.


Chris F: ask for straw poll on who could accept two separate rooms at F2F.


Anish: WS addressing has interop event before the spec meeting, to have the issues discussed directly.


Jeff M: there is a concern about making the meeting 4 days instead of 2.  On the other hand, some companies want to have the same person in both meetings, if they are concurrent.


Paul F: we could have one day of interop SC, one day with both concurrent, final day with just the spec meeting.


Jeff M: that means two two day meetings, with one day of overlap.


Doug D: I would rather do one day interop, the second day on TC discussion, with only one room


Marc G: I would prefer having both days of F2F focus on interop.


Paul C: given that many companies will have different people involved in interop, we need to make the meetings well bounded, so we know which days are for interop, and which days are for spec discussions.  I could accept three days, wed for interop, followed by two days for TC discussions.


Paul F: straw poll on overlap

Cannot accept any overlap – 3 companies


Paul C: how about 1.5, 1.5, over 3 days.


Consensus reached on two 1.5 day meetings.


13.2Discussion of Application notes

Jacques: our engineers have been asking for the Implementation SC to produce an application notes/ implementation guide document.  This would be used by developers who are not directly involved in TC activites.


Paul C: what would be in the document.


Jacques: examples of content could include

  • best practices,
  • implementation scenarios,
  • background for developers,
  • binding examples


Paul C: while I do not dispute that these are useful, I question if they are required to declare success.  The people who can write such a spec are often involved in writing such material in their own companies.  In Microsoft we don not have people who can do such work available to come to the table at the TC.    The public needs guidance at the Product level.


Doug D: would you want this to be an official TC approved document?


Jacques: if this proves difficult, we may have no participation.  We would like to have the implementation SC approve this document.  This has been done in other TCs, such as WSRF.


Paul F: If we had a Wiki, people could contribute to such a document.  We do not have it.  I would prefer that such a document not be an official production of the TC.  Some companies consider such information proprietary, in that it enhances the value of the product.  It might conflict with their proprietary information.


Paul F: could you post a shell of such a document, letting TC members review it to determine what status could be given to the document.

14   March Face To Face Ballot Revisited

Sanjay asked if the kavi ballot should have a way to indicate more than yes. 


Some members want to have a way to say they cannot go to one of the choices.


I can go to both

I can go to Raliegh

I can go to Hursley

I will go to neither


Sanjay will delete the current ballot and will prepare a new ballot which determines whether people cannot attend each choice.


15   Issues Resolutions Resumed

15.1                        I078

Lost terminate sequence message


Bob F proposed that the terminateSequence operation become requestResponse operation. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00153.html


Change oneway TerminateSequence to request-response TerminateSequence so that the RMS can on the same connection determine whether TerminateSequence was successful and thus can retry TerminateSequence if necessary.


There was discussion on whether the response is “synchronous” or could be a callback.


Anish: the existence of a response for Terminate Sequence avoids the lost sequence message.


Matt: the synchronous vs asynch is not critical here.  Having a response does not ensure it will arrive at the RMS. However if the RMS retries the terminateSequence it could either get a response or an UnknownSequence Fault (both of which let it know the sequence if termintated).


Chris F: I do not have a problem with the response, except I do not want to have a requirement for the RMS to resend if it does not receive the response.  There will always be cases where the RMS will not explicitly terminate the sequence, where the RMD will have to clean up resources upon some sequence expiry time.  If the expiry time is infinite, there will still be management actions to clean up “dead” but non terminated sequences.


Paul F: given changes to “last message” it is now appropriate to have the terminateSequence operation have a response.


Sanjay: we need a concrete proposal, with the actual syntax.


TC consensus was reached to add a response to the terminate sequence.


Ø  Action: Marc G will work with Bob F and Anish to draft a concrete proposal for terminateSequence Response message.


15.2                        I079


      SequenceClosed fault and SequenceAcknowledgement(Final)



            When the RMD autonomously closes a sequence while the RMS is sending

            messages, messages that the RMD has already received cause SeqAck(Final)

            but other messages cause SequenceClosed fault or SeqAck(Final). Which is

            to be returned is unclear.


            The SequenceClosed fault is not useful for the RMS to determine the

            maximum message number that the RMD had accepted.




            Provides the RMS correct ending status on autonomously closed sequences.


    Proposal 12005-11-30


            We propose that SeqAck(Final) be piggybacked on the SequenceClosed fault


Doug B: is this disallowed in the current spec?   Are you trying to make something that is possible now to become required behaviour?


Bob F: if it is not piggybacked, it requires the introduction of another State, thus complicating the protocol.


Doug D: CloseSequence Response has the seqAck Final, so this proposal is consistent with that.


Chris F: how about having every message sent by RMD after sequence is closed would be accompanied with the seqAck(final).  Chris F: whenever the RMD closes the sequence, every message subsequent to that has the seqAck(final) message.


Doug D: that seems to be a better way to accomplish what Bob F wants.


TC reached consensus to adopt the approach suggested by Chris F.


Ø  Action: Chris F will propose exact text to resolve i079.


16   RDDL Presentation by Gil/Steve

Resource Directory Description Language (RDDL) for WS-RX specifications:



Paul C: I do not think the examples should be included.


Chris F presented a way to store and display spec metadata using “micro formats”, to serve as a directory of links to resources related to the specification.


Paul C: what about specs which have more than one namespace?


Sanjay: we never had a issue on this.


Paul F: we should add an issue to having a RDDL document to be a formal deliverable of the TC.


No disagreement.


Concensus was reached that RDDL document is a new deliverable for the TC.


Action: Marc G will add RDDL document as a new deliverable for the TC.


Acton: Gill will post RDDL document to the editors’ drafts folder on Kavi.


Steve W: we should  decide on whether Version 1 RDDL or Version 2 RDDL should be used.


Gil: we used version 2 in our first draft, so we will post a RDDL version 2 doc in the Kavi folder.  Members can comment or propose new issues if they want to use version 1.


17   CD Planning


Agreed that Editors are to incorporate resolutions into new WD by Jan 5. 2006.


One week TC review and feedback will occur between Jan 5 and Jan 12 to review.


A 1 Week CD 2 ballot will initiate on Jan 16, with document incorporating changes from Jan 12 Review.


Paul C: we could change this if things get delayed.


This is in parallel with the Interop Scenario.  In fact the TC review for both documents will be in the week between Jan 5 and Jan 12.


Gil: For subsequent CDs the editors change the namespace.  This is in Namespace evolution policy for TC.  The namespace will not change on subsequent WDs.


Paul F: when can the RIDL document be completed by.


Gil: we have to figure out how to factor in the microFormat stuff from Chris, as well as RDDL version 1 as opposed to Version 2..


Paul C; we can waid for the RDDL stuff to be published.


Paul F: I can ask OASIS staff what their requirements are for RDDL.  We should target the RDDL to be available by Jan 1.

18   Committee Spec Planning

Sanjay presented his current view of CS timeline.


  • First PR review is 60 days.
  • X weeks to incorporate feedback.
  • 1 Week to make next CD, and decide on need for second PR review.
  • 15 day second PR review.
  • Assuming no significant feedback in second PR review, we can start CS ballot.
  • CS ballot Ends after one to three weeks.
  • Ballot to submit to OASIS for review as OASIS standard could be conditional concurrent ballot with CS ballot.


Sanjay presented the following PR criteria.

  • No substantive open issues
  • TC ballot for sending CD for PR has passed
  • An Interop event has occurred.
  • Normatively referenced specs are “far enough along in standardization process” or abstracted out.


Chris F asked if the interop event before first PR is required.


Tom R: while it is a good goal to have interop event before first PR, if Interop not done, we could have the interop occur during first public review.  If any changes are required from interop, there would be a second PR required.


Paul F: this decision depends on whether we plan ahead assuming two public reviews.


Marc G: It is important to do interop before public review.  We should find issues ourselves thru the interop, before inflicting the public to review.  Make the time available to ensure the interop event occurs before the first public review.


Chris F: By my calculations, assuming 1 week TC ballots for CDs and CSs, we can deliver an OASIS standard in August, with one public review.  Adding another public review gives us another month for OASIS standard.


Chris F: Given the amount of interops which already occurred in the submission, I do not anticipate significant issues coming from interop.  The issues, if any, will arise during implementation phase before the interop event.  We may have advantage to pull up the dates as short as possible.


Umit: there have been changes to the protocol, so I am not as optimistic as Chris.  What is the problem of an extra month.


Paul C: we have given ourselves an amazing amount of work for January, assuming the editors will do their work before Jan 05.  There is no problem if the TC has nothing to do during the 60 day public review, we can just have less meetings during that period.


Paul C: if the PR ballot occurs after April 1, we can still have an OASIS standard by Aug 31 2006.


General agreement to proceed on assumption that first PR will occur after March Face to Face interop.


Resulting General agreements.

  • April 1 for WD/CD 3 ballot and vote to issue as PR
  • April 8 to initiate 60 Day PR.


19   Issue Resolutions Continued

19.1                        I075 Re-review

Anish email proposal:

Matt, PaulF, Jacques and I discussed the ideas that were on the whiteboard yesterday (options 1 thru 4) and came up with the following proposal to resolve issue i075.



Section 2.1 add new text to follow line 109:

"When a RM Destination provides RM services for more than one endpoint

it is RECOMMENDED that all the endpoints should have the same values for

RM Policy parameters.  If the RM Policies are not the same then the RM

Policy parameters in effect for each Sequence is governed by the

endpoint that was used for the <wsrm:CreateSequence> message."


This is option I and option II from first day discussion.  Paul C asked for more time to review this proposal.


We also propose a new issue, to aid the RMS/RMD/AS/AD in cases where

policies/WSDL are not advertised, or the RMS is not WSDL/policy aware.

The advantage of this would be that now we have a mechanism for RMD to

specify the RM assertion for the Sequence as opposed to per port/endpoint.


New issue (not formatted to the new issue template -- will do that in a separate email so that it is easier to track):


The following new issue proposal corresponds to Option III from first day discussion.


1) An RMD is allowed to optionally assert in CSR message the policy

assertion associated with the Sequence. This policy assertion may

contain parameter that we have defined in WSRMP and/or extensibility



2) Similarly, the RMS is allowed to optionally assert in the wsrm:Offer

part of the CS message the policy assertion associated with the Sequence

in the opposite direction.


The CSR/CS  message will now be:


<wsrm:CreateSequenceResponse ...>

  <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

  <wsrm:Expires> xs:duration </wsrm:Expires> ?

  <wsrm:Accept ...>

    <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>


  </wsrm:Accept> ?

  <wsrmp:RMAssertion ...>... </wsrmp:RMAssertion>?




<wsrm:CreateSequence ...>

  <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>

  <wsrm:Expires ...> xs:duration </wsrm:Expires> ?

  <wsrm:Offer ...>

    <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

    <wsrm:Expires ...> xs:duration </wsrm:Expires> ?

    <wsrmp:RMAssertion ...>... </wsrmp:RMAssertion>?


  </wsrm:Offer> ?




a) Is it optional for the RMD to include wsrmp:RMAssertion?



b) Is the wsrmp:RMAssertion in the CSR definitive?



c) Can the wsp:optional attribute be present in the CS/CSR messages on





Discussion of  the proposal for issue 075


Chris F: change “recommended” to lower case, and ‘SHOULD” to upper case.


Paul C: where is normative definition for “RM policies are not the same”.


Matt: we can fix this by rewording


Jacques: what does it mean “endpoint used for create sequence message”.  How does RMD know which final endpoint the create sequence is intended for?


RMS will set up sequence, and RMD implementation decides what endpoint to send each message on that sequence to.


Paul F: there is a policy attached to the endpoint to which the createSequence is targeted


Gil: I see a problem with removing the text about “RM Policies are not the same”.  It is helpful to offer advice that you do not want to have different policies across the endpoints served by an RMD.  I could take an action to specify what it means for policy to be the same.


Gil: Assume we have 4 ports with different policy, and a single sequence spanning all 4 ports.


Stefan B: the rm assertion is not on an application endpoint, it is on the RMD.


Paul C: why not put this on line 147 and 148?


Matt: section 2.1 has general guidance, before specifying specifics.  We could change where it is placed if TC members want it as such.



Chris F: have RMD notify the RMS as to what parameters are in effect (and not have them a policy.


Jacques: +1 to Chris.


Paul F: I think the only policy should be the assertion that rm is in affect.  The parms AI, and MaxNum could be defined in the spec for return in createSequence response only.


Anish: I would like to see a bag in the CreateSequence response, rather than the exact two parameters.


Paul F: I do not see these as policies as defined by WS-Policy, they are “what RMD is doing with a sequence”. While we have the extensibility for policy, we can move these parameters explicitly in the create sequence response.


Anish: what about use of security, such as STR, which we removed.  What if a user wants to put in DAs as extensions in the CreateSequence exchange.


Paul F: the designers of an extension need to specify all these things.


Paul F: based on what I have heard, I now believe that we should only do option 1 and option III.  Thus I have a different proposal for i075, and I will write this up.


19.2                        I079

Email from Chris F:



line 375-377 replace: Upon receipt of this message the RM Destination MUST include a

SequenceAcknowledgement header block in the CloseSequenceResponse

message. Note, this SequenceAcknowledgement MUST include the <wsrm:Final> element.




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 each message destined to the RM Source,

including the CloseSequenceResponse message and any faults related to the Sequence.  


Doug D moved to accept Chris F proposal for i079, Gil seconded.

Paul C: the symmetry on either side of the and , why is “faults” plural.


Chris F moved to amend replacement text, seconded by Tom R, to

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 each message destined to the RM Source, including the CloseSequenceResponse message and on any Sequence Fault transmitted to the RMS.  


§    No objection to amended motion.


§    No objection to passing motion, issue i079 closed with Chris F amended proposal.

20   Review of Action Items

The group reviewed the action items from this meeting, Items which are completed will not be added to the Kavi Action Database.


Action Items List from Sunnyvale Face To Face



         Action: Editors will report on the mailing list those procedures they use before posting a WD.


Su2 - completed

         Action: Paul C will send out an email with a set of criteria for updating our references to the latest version.



         Action: editors to remove wsse namespace prefix from Table.



         Action: Doug D to add RM source back into the glossary.



         Action: editors shall determine whether the resolution to i010 has been fully reflected in the text.


Su6 - closed

         Action: Anish and Paul F will produce a more detailed proposal on i075 for discussion tomorrow.


Su7 - closed

         Action: Gill will do concrete proposal for option 3 in straw poll for Issue 21..



         Action: Tom R will raise an issue regarding sending Sequence Terminated Fault after the sequence has been terminated.



         Action: Matt will raise an issue regarding what RMS does when receiving sequenceClosedFault while in non terminating state (Row 16 in Hitachi State Table).



         Action: Bob F will raise an issue regarding the rows of RMD and RMS state table for events receiving unknownSequenceFault or SequenceTerminatedFault while it thinks the sequence is active.


Su11 - completed

         Action: Bob F will post the State tables to Kavi as Member document, with an indication of which working draft document revision the tables correspond to.  Also have a section to record a change log.



         Action: Marc G will work with Bob F and Anish to draft a concrete proposal for terminateSequence Response message.


Su13 – completed

         Action: Chris F will propose exact text to resolve i079.


The non completed action items will be added to the Kavi List.


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