[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 5133Title: Day 2 WS-RX TC Face to Face Prelim Minutes
|
Day 2 WS-RX TC Face to Face Prelim Minutes 12 Issue Resolutions Continued12.1I058 State machinesBob F presented his contribution on State Machines http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00152.html http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00150.html 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:
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 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 §
Motion Passed, TC thanks N Yamamoto San for his
work on the 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 Discussions13.1Scheduling discussionDiscussion of CD progression activities and Interop event. Paul F proposal:
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:
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:
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. Questions:
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 notesJacques: 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
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 RevisitedSanjay 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 Resumed15.1 I078Lost 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 I079SequenceClosed fault and SequenceAcknowledgement(Final) Description 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.
Justification 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/SteveResource Directory Description Language (RDDL) for WS-RX specifications: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00149.html 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. 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 PlanningAgreed 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 PlanningSanjay presented his current view of CS timeline.
Sanjay presented the following PR criteria.
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.
19 Issue Resolutions Continued19.1 I075 Re-reviewAnish 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 elements. 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:CreateSequenceResponse> <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> ? ... </wsrm:CreateSequence> a) Is it optional for the RMD to include wsrmp:RMAssertion? yes b) Is the wsrmp:RMAssertion in the CSR definitive? yes c) Can the wsp:optional attribute be present in the CS/CSR messages on wsrmp:RMAssertion? no ----- 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 I079Email from Chris F: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00167.html 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. 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 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 ItemsThe 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 Su1 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. Su3 Action: editors to remove wsse namespace prefix from Table. Su4 Action: Doug D to add RM source back into the glossary. Su5 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.. Su8 Action: Tom R will raise an issue regarding sending Sequence Terminated Fault after the sequence has been terminated. Su9 Action: Matt will raise an issue regarding what RMS does when receiving sequenceClosedFault while in non terminating state (Row 16 in Hitachi State Table). Su10 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. Su12 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]