[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 4/13 Teleconf
Prelim minutes are attached. Please post corrections on the list before next monday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: firstname.lastname@example.org; email@example.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Minutes of OASIS WS-RX Teleconference
Prelim Minutes of OASIS WS-RX Teleconference
April 13, 2006
Start Time:4:00 PM Eastern Daylight Time
Paul Freemantle acted as chair.
Ø Action Item
1 Roll Call
xx of 4? voting members, meeting quorate
Tom Rutt agreed to take minutes.
2 Agenda Approval
1) Roll Call
2) Review and approval of the agenda
3) Approval of the Apr 06, 2006 meeting minutes
4) AI Review
5) Update from Editors
6) New issues since last conf-call
Watch for Marc’s email
7) Issue Discussion:
a> i089 suggest the restricted use of anonymous URI
b> i106 SequenceAcknowledgement:Final assumption of deliverability
c> i111 Sequence state in event of MessageNumberRollover
8) Any other business
Bob F proposed to defer issue 106. Chris F have published proposals, but further work is required.
Doug D: can be move 111 before 89
No objection to changes.
Tom Asked that the Microsoft patent notice be put on the other business discussion. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00038.html
Paul C: the statement is clear.
Doug D: I think we might want to discuss this if we have time.
Tom R: we might be better to read the notice and discuss it later.
3 Approval of the 4/6 minutes;
Tom R moved Paul K seconded to approve 4/6 minutes
§ No objection minutes for 4/6 meeting approved..
4 AI Review
#0094: Marc G will produce a detailed proposal for i089 by fixing normal replay mechanism.
Owner: Marc Goodner
Status: Open – still pending
#0097: have editors get a new namespace for next CD, given the use of ws addressing PR
Owner: Doug Davis
Status: Open – still pending
5 Update from Editors
Doug D: all the resolved issues have been added to spec, except for issue 93.
Gil: we had no confidence in carrying out the resolution for issue 93. We need help from Doug B.
Doug B: where are the problems.
Ø Action: Gill and Doug will work to carry out resolution of issue 93.
6 New issues since last conf-call
From Marc’s email http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00037.html
6.1 Proposed-01 tightening-up the state tables
Title: Tightening up the state tables
(a)- RMD table: there is no way to transition from " none" to "connecting" state (event "CreateSequence receive" is missing)
(b)- RMD table: In the "event" entries: for events that concern "Faults", (e.g. Unknown Sequence Fault, Terminated Sequence Fault), and when either RMS or RMD could generate such Faults, it should be mentioned in table if the event is about receiving or generating such a Fault (assume it is "receive").
©- RMS table: mention that either the case of offered sequences is not handled, or add this case.
(d) "connected" state a bit ambiguous a name - too much transport related.
(e) these tables are more about sequences state than RMD/RMS states (as the same RMD/S can find itself in many states w/r to many sequences.
Justification: tables could be misleading to users if incomplete. Some developers might actually use them to implement an automaton that might miss some cases.
(a) add CreateSequence receive even that lead to connecting state.
(b) Qualify each event as either "(internal)" or "(received)".
(c) Add a line with event "offered sequence (received)" that transitions directly from none to connected.
(d) Replace "connected" with "active", and "connecting" with "activating".
(e) "This appendix specifies the non-normative state transition tables for RM Source and RM Destination." Replace with: "This appendix specifies the non-normative state transition tables for RM Source and RM Destination, relative to the management of a particular sequence."
No objection to accept proposed 01 as new issue.
6.2 Proposed-02 figure 2 out of date
Christopher B Ferris
Title: Figure 2 (cd3)  is out of date with the changes to the potocol
Figure 2 (cd3)  is out of date with the changes to the potocol
does not reflect Close() operation
replace Figure 2 graphic with this one
STSM, Software Group Standards Strategy
phone: +1 508 377 9295
Marc G: the final proposal also has to update the surrounding text.
No objection to accept proposed 02 as new issue.
6.3 Proposed-03 Add Max Msg Num to CSR
Title: Add Max Msg Num to CSR
The createSeq/createSeqRes handshake already passes back the AckInterval which can be useful information to the RMS. Knowing the max msg number that the RMD will support could also prove useful since not all impls will support the large # we mention in the spec.
By the RMS knowing this information it may choose to use it to avoid getting the Message Number Rollover Fault and be able to deal with this situation in a much more graceful manner.
Target: core design
On the CSR add as an optional sibling to AckInterval:
Pseudo-schema (changes in bold):
<wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
<wsrm:Expires> xs:duration </wsrm:Expires> ?
<wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... /> ?
<wsrm:MaxMessageNumber> wsrm:MessageNumberType </wsrm:MaxMessageNumber> ?
<wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>
This element, if present, specifies the largest message number that the RM Destination will accept for the specified Sequence. If omitted, the implied value is 9,223,372,036,854,775,807.
Update schema accordingly.
Paul F: I had proposed a note so solve this in issue 86. I proposed all implementations should support the number (9trillion). However I support this as a new issue.
Doug B: is this reopening a closed issue. I am not sure we should open an issue that has been closed in the past.
Jacques: this issue is close to I13 closed. It might be a reopening of I13.
Sanjay: I recall we had this discussion in the past. However there have been changes to policy. It may be reasonable to look at this as a new issue.
Sanjay: are there objections.
Doug B: I object, we have discussed this issue already.
Sanjay: lest carry on discussion for this new issue on the mailing list. Defer discussion until future call.
Doug D: my single negative vote should not postpone.
Sanjay: I need more discussion, as maybe other members do. I say we take it to email, and defer discussion.
6.4 Proposed-04 "must understand" attribute for extensions to RM components
All of the Sequence Lifecycle Messages (<wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, and <wsrm:TerminateSequenceResponse>) and RM Protocol Header Blocks (<wsrm:Sequence>, <wsrm:AckRequested>, and <wsrm:SequenceAcknowledgement>) define extension points for adding additional elements to the message, however, there is currently no mechanism for the sending party (e.g. the RMS in the case of a <wsrm:CreateSequence> message or the RMD in the case of a <wsrm:TerminateSequence> message) to indicate to the receiving party that it must understand the semantics implied by the extension element(s). The usefulness of these extension points is therefore imited by the fact that, in general, the sending party cannot be certain whether the receiving party understood the extension or is simply ignoring it.
(add to Glossary section)
The following glossary defines a set of terms used to describe some of the different messages related to WS-RM:
Sequence Lifecycle Message: A message that contains one of: <wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, <wsrm:TerminateSequenceResponse> as the child element of the <soap:Body> element.
RM Protocol Header Block: One of <wsrm:Sequence>, <wsrm:SequenceAcknowledgement>, or <wsrm:AckRequested> elements.
RM Component: One of the elements that either make up the body of a Sequence Lifecycle Message or that appears as an RM Protocol Header Block.
Sequence Traffic Messsage: A message that contains a <wsrm:Sequence> header block.
Acknowledgement Message: A message that contains a <wsrm:SequenceAcknowledgement> header block.
(add to Section 3)
3.7 Extension Elements
The definition of each of the RM Components includes an extension point that allows the addition of elements to that RM Component. It is likely that specifications for a wide variety of extensions to these RM Components (termed “RM extensions” for the purposes of this discussion) will be developed over time and that some RM nodes might include the software necessary to implement one or more such extensions. An RM extension is said to be understood by an RM node if the software at that RM node has been written to fully conform to and implement the semantics specified for the XML expanded name of the outer-most element information item of the extended element.
An RM extension element MAY carry a mustUnderstand attribute information item. When the value of such an attribute information item is "true", the RM extension is said to be mandatory.
Mandatory RM extension elements are presumed to modify the semantics of other RM Components. Therefore, for every mandatory RM extension recieved by an RM node, the receiving node MUST either process the element or not process the element at all, and instead generate a wsrm:MustUnderstandFault. Tagging RM extensions as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by the RM nodes that recieve the messages containing extended RM Components.
(add to Section 4)
This fault is generated when an RM node (RMS or RMD) is presented with a Sequence Lifecycle Message or RM Protocol Header Block that contains an extension that is tagged with a wsrm:mustUnderstand attribute with a value of "true" and that node does not understand that extension element.
[Code] Client or Server (as appropriate)
[Reason] Do not understand the extension marked as "must understand"
No objections to accept proposed 04 as new tc issue.
7 Issue Discussion:
8 i089 suggest the restricted use of anonymous URI
Paul F: I proposed a new interaction to allow polling for messages from the client side. This is for cases where the RMD cannot initiate connections with RMS.
Paul F: I proposed a getMessage request, with an identifier for a sequence, with a possible message id qualifier. If no response are available there is a “no message” indication.
Paul F: I also added section 4.2 regarding an offer only model.
Paul F: the decision is whether this is in scope for the TC. Another issue is what the correlation ID would be. My proposal is a balance of simplicity over power. Also there is a concern on whether this is restricted to the anonymous URI.
Doug D proposal: http://lists.oasis-open.org/archives/ws-rx/200604/msg00023.html
Doug D: should we head down this path. Our proposals are similar. Should we solve this problem? I would like a sense of the TC on whether we need a solution.
Sanjay: do we need solution for reliable messaging when RMS is not addressable.
Anish: I agree we need this solution.
Sanjay: whether polling is the preferred solution to this problem is still open. Resend of request is another viable mechanism.
Stefan: a specific solution for anonymous clients, vs allowing the problem to be solved. The spec should not get in the way of solutions. However this problem is broader than rm.
Doug D: are you suggesting close with no action.
Stefan: I would have to review if the spec might need clarification words to allow the scenario.
Doug D: We need a solution in the spec.
Paul F: There are solutions to this problem. JMS has one solution. I want to consider this. If there was a standardized solution that can be used with wsrm I would like to use it.
Sanjay: do we want to have a solution in the spec today, or do we wait to compose. My company needs a solution.
Stefan: anyone in this TC considering this should think about the scenario this is applicable in. We need to ensure it works.
Tom R: We need this, we can define a solution in our “namespace” which might be applied elsewhere. If others can use it they should be able to.
Anish: I would like to move hat we add this functionality to the spec.
Marc G: we need to agree on a specific proposal, not just the need.
Anish: the first question is whether we need this capability.
Sanjay: first question is do we need this. Second effort is on how to realize it. The is a polling approach in both Doug D an Paul F proposal. One question is whether polling approach is acceptable.
Chris F: such a motion cannot be binding.
Doug D: if anish wanted a polling approach I would second it.
Sanjay: is anyone opposed to taking polling approach to solve this problem.
Paul C: I agree we need to solve this problem, but I do not agree it should be rm specific. We need a general solution to this problem.
Doug D: my proposal does solve a broader problem, and I would like it to be considered.
Sanjay: I see Paul C as asking that this might be better done outside this tc.
Paul C: I would like to hear Doug’s proposal in the remaining time.
Doug D gave a summary of his proposal. The proposal has an EPR as the identifier of the originator of the connection which requires a polled return. The Get message as a “me” identifier, which is the value of an epr sent in the reply to. Our solution is more general, in that is allows more use cases.
Doug D: I would ask people to read the material we sent out on this.
8.1 c> i111 Sequence state in event of MessageNumberRollover
Paul F: the state tables on rollover do not agree with the text.
Title: Sequence state in event of MessageNumberRollover
The spec doesn't talk about what the continued state of a sequence is
The state tables have an entry that is not clear. We ought to define
what the state is after a rollover.
Target: core design
At line 519 after the following sentence:
If the message number exceeds the internal limitations of an RM Source
or RM Destination or reaches the maximum value of
9,223,372,036,854,775,807 the RM Source or Destination MUST issue a
Add one of:
(a) In this case the RM Destination should continue to accept
undelivered messages until the Sequence is closed or terminated
(b) In this case the RM Destination should Close the Sequence.
Paul F: I prefer option a.
Doug D: I would like a change to the fault to add this rollover information.
Paul F: I think this is a separate issue.
Paul F: I am not against adding to fault but I prefer it be done as a separate issue.
Aniish: should -> SHOULD
Paul F: it needs to be SHOULD
Bob F: we need to make corresponding changes to the RMD state tables.
Paul F: that should be a separate issue. The RMS would not issue rollover fault.
Bob F: should the cd 03 lines 518 and 519 need to be fixed.
Paul F: yes.
Paul could modifiy his proposal to add this new concern.
Doug D: I do believe an RMS can deliver a fault. The RMS might say the AS is going to far. That is why it was stated the way it is. The text should state “must generate”, not necessarily sent on the wire.
Sanjay: there are differing positions, so it maybe should be a new issue.
Chris F: nothing states an RMS cannot generate faults, transfer is a separate concern
Paul F: The concern is what the RMD does in this situation.
Sanjay: this proposal is aimed at what the desitnation should do when this fault is raised.
Doug D: I disagree. The rest of the spec talks about rms and rmd generating faults. The proposal needs to include both sides of the rm protocol.
Paul F: add “and RMS should continue to deliver …
Bob F: we decided to use “transferred” instead of “delivery”. RMD state table no longer have Rollover as a state. We may need to add the RMD state of rollover reintroduced.
Gil: why would rms generate source.
Doug D: if rms cannot deal with more than 3 messages. If it reaches its limit, is should still send prior messages as a resend.
Considerable discussion ensued on message number limits, and prevention of message numbers allowed on the wire.
Sanjay: what is rmd supposed to do with fault from rms. Could clarify that this fault is defined for rmd to send to rms.
Paul F: if rms wants to close sequence it can. This issue is to state what the RMD should do in the rollover situation. I can accept the chris F proposal above as a friendly amendment.
Doug D moved to accept proposal from Chris F, Chris F seconded. “In this case the RM Destination should continue to accept , and the RM Source should continue to retransmit,undelivered messages until the Sequence is closed or terminated”
Bob: opening another issue for clarification on rms side might be acceptable.
Chris F: this text is regarding when this fault is generated. I does not state which side generates the fault. Assume it gets transmitted from rmd to rms. This gives a clarifiction for that case.
Bob F: there might need to be state table clarificaitions.
§ Issue I111 resolved by accepting proposal from Chris F.
9 Any other business
Meeting adjourned at 5:30 EST.
_______________________________________________________________________ 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]