Prelim
Minutes of OASIS WS-RX Teleconference
April
13, 2006
Start Time:4:00 PM Eastern
Daylight Time
Paul Freemantle acted as
chair.
Textual Conventions
Ø
Action Item
Motion
§
Resolution
1
Roll Call
From Kavi:
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
http://www.oasis-open.org/committees/download.php/17668/MinutesWSRX-040606.html
4) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
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
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089
b> i106 SequenceAcknowledgement:Final assumption of deliverability
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i106
c> i111 Sequence state in event
of MessageNumberRollover
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00021.html
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;
http://www.oasis-open.org/committees/download.php/17668/MinutesWSRX-040606.html
Tom R moved Paul K seconded to approve 4/6 minutes
§
No objection minutes for 4/6 meeting approved..
4
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0094: Marc G will produce a detailed proposal for i089 by fixing normal replay mechanism.
Owner: Marc Goodner
Status: Open – still pending
Assigned: 2006-04-03
Due: ---
#0097: have editors get a new namespace for next CD, given the use of ws addressing PR
Owner: Doug Davis
Status: Open – still pending
Assigned: 2006-04-03
Due: ---
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
Jacques
Durand
http://lists.oasis-open.org/archives/ws-rx/200604/msg00026.html
Title: Tightening up the state
tables
Description:
(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.
Target: core
Proposal:
(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
http://lists.oasis-open.org/archives/ws-rx/200604/msg00027.html
Title: Figure
2 (cd3) [1] is out of date with the changes to the potocol
Description:
Figure
2 (cd3) [1] is out of date with the changes to the potocol
Justification:
does
not reflect Close() operation
Target: core
Proposal:
replace
Figure 2 graphic with this one
[1] http://docs.oasis-open.org/ws-rx/wsrm/200602/wsrm-1.1-spec-cd-03.pdf
Cheers,
Christopher
Ferris
STSM,
Software Group Standards Strategy
email:
chrisfer@us.ibm.com
blog:
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone:
+1 508 377 9295
RM
Protocol 20060407.ppt
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
Doug
Davis
http://lists.oasis-open.org/archives/ws-rx/200604/msg00034.html
Title: Add Max Msg
Num to CSR
Description:
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.
Justification:
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
Proposal:
On the CSR add as an optional
sibling to AckInterval:
Pseudo-schema (changes in bold):
<wsrm:CreateSequenceResponse ...>
<wsrm:Identifier
...> xs:anyURI </wsrm:Identifier>
<wsrm:Expires> xs:duration </wsrm:Expires>
?
<wsrm:AcknowledgementInterval
Milliseconds="xs:unsignedLong" ... /> ?
<wsrm:MaxMessageNumber>
wsrm:MessageNumberType </wsrm:MaxMessageNumber>
?
<wsrm:Accept
...>
<wsrm:AcksTo ...> wsa:EndpointReferenceType
</wsrm:AcksTo>
...
</wsrm:Accept> ?
...
</wsrm:CreateSequenceResponse>
and add...
/wsrm:MaxMessageNumber
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.
No objection.
6.4
Proposed-04 "must understand"
attribute for extensions to RM components
Gilbert
Pilz
http://lists.oasis-open.org/archives/ws-rx/200604/msg00036.html
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.
Proposal:
(add to
Glossary section)
1.1 Glossary
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)
4.9 MustUnderstandFault
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.
Properties:
[Code] Client or Server (as
appropriate)
[Subcode]
wsrm:MustUnderstandFault
[Reason] Do not understand the
extension marked as "must understand"
[Detail] xs:any
No objections to accept proposed 04 as new tc issue.
7
Issue Discussion:
8
i089 suggest the
restricted use of anonymous URI
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089
http://lists.oasis-open.org/archives/ws-rx/200604/msg00022.html
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
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00021.html
Paul F: the state tables on rollover do not agree with the
text.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00021.html
Title:
Sequence state in event of MessageNumberRollover
Description:
The
spec doesn't talk about what the continued state of a sequence is
after MessageNumberRollover.
Justification:
The
state tables have an entry that is not clear. We ought to define
what the state is after a
rollover.
Target:
core design
Proposal:
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
MessageNumberRollover fault.
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
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 …
Chris
F:
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.