Prelim
Minutes of OASIS WS-RX Teleconference
Oct
26, 2006
Start Time:4:00 PM Eastern
Daylight Time
Paul F acted as chair.
Textual Conventions
Ø
Action Item
Motion
§
Resolution
1
Roll Call
From Kavi:
meeting is quorate
Tom Rutt agreed to take minutes.
2
Agenda Approval
Agenda
1) Roll Call
2) Review and approval of the
agenda
3) Approval of the Oct 19, 2006
meeting minutes
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/20816/MinutesWSRX-101906.html
4) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
5) Report from the Implementation
SC
6) Discussion of PR Issues
PR004 Editorial comments
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i004
PR005 Sequence Ranges
Overlap
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i005
PR023 CreateSequenceRefused
fault should apply to sender and receiver
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i023
PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001
PR006 Destination of Seq faults
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i006
PR024 When to send CloseSequenceResponse vs. SequenceClosedfault
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i024
PR007 RM Destination lacks a
mechanism for cleanly terminating inbound sequences.
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007
PR008 Underlying protocol bindings
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i008
PR009 "Duplicate Elimination"
and "Message Ordering"
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009
7) Any other business
Bob F will give an addressing update for 5a.
Marc G: I would be good to review planned schedule to CS at
the next call.
Marc G: might want to move discussion to PR001 to end of
call, due to recent posting by Dug.
No objection: PR001 moved to last positionl
3
Approval of the 10/19 Minutes;
http://www.oasis-open.org/committees/download.php/20751/MinutesWSRX-100506.html
There was confusion abut the next call date, which was
incorrectly listed as Next Tuesday.
Also, the date on the top was 10/10..
Tom moved to approved 10/19 minutes, Paul C seconded.
§
No objections, minutes of 10/19 approved.
4
AI
Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0111: Paul and Bob to work out joint WS-RX/WS-Addressing
forum for further discussion of pr001 issue.
Owner: Paul Fremantle
Status: Open
Assigned: 2006-10-05
Due: ---
Continue to defer.
Ø
ACTION: paul
F to add explanation for use of piggybacking.
5
Reports
5.1
Report from the Implementation SC
Paul F: running at 30 % coverage of tests. The group seems to run out of focus. No spec issues have been found yet.
Dug D: more lack of momentum than spec issues.
Marc G: we have been busy lately, and have not devoted
enough resources.
Paul F: Lets note the: target for Monday the 6th of
November to finish the tests.
5.2
WS-Addressing update
Bob presented the latest discussions from the ws-addressing group. There are two new markers proposed
for addressable and non
addressable return eprs.
Bob: If either of two options in proposal succeed,
it will take the wsdl binding back to last call
(minimal 4 week).
Paul C: where is testing status of wsdl
binding.
Bob: there has been testing. It has been suspended.
Tom: what about wsdl 2.0 availability.
Bob: we are dealing with all available wsdl
versions, as they become available.
Paul C: status on CR
stated testing would be in phases, wsdl 1.1 followed
by wsdl 2.
Anish: w3c allows specs to be one
step ahead of other specs. WSDL 2 is in
CR. Only if WSDL 2 does not go to pr
there could there be a problem.
6
Discussion of PR Issues
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml
Ø
Action: Marc G to keep people on public comment
list notified of the current issue numbers.
6.1
PR004 Editorial comments
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i004
Mail from dug: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00109.html
Leaving the boundaries of being
just a monkey I started to work on these nits and Gil's (all part of PR004):
Some comments:
- Quite a few of the refs to
sections 3.x were wrong, so I had to change most of those - if people are
inclined please check those, esp. in the state tables
- soap1.1 is a Note not a Member
Submission - I know they changes the term but when you follow the link it still
says "Note" so I'm leaning towards not changing that one
- Schema references - any one have
any opinion on which version we should point to?
- can't see the odd bold stuff you
mention in point 25
- 26: did it for WSRM and WSRMP
WSRMP
- 1 - don't see the italic issue you
reference
All other changes are applied but
not checked-in yet.
thanks,
-Doug
Paul: 4th editition for
XML, 2nd edition for schema
Motion to accept proposed changes by Gil and Marc in the PR
Issue 004, to resolve 004, seconded by Marc G:
§
No objection issue 4 closed by accepting changes
form Gil and Marc.
6.2
PR005 Sequence
Ranges Overlap
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i005
Description
The RM spec says, w.r.t.
Seq
Ack Ranges:
The ranges SHOULD NOT overlap.
Why isn't this a
MUST NOT? It smells like an interop issue if we don't know if the other side can deal
with it.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Doug Davis
Proposal 12006-10-19
Change it to a MUST NOT
Motion by Dug to accept proposal 1, seconded by Marc G.
§
No objection, Issue PR023 resolved by accepting
proposal 1.
6.3
PR023 CreateSequenceRefused
fault should apply to sender and receiver
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i023
Description
In section 4.6 the CreaetSequenceRefused fault is defined as a sender fault.
This fault should apply to sender or receiver.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Marc Goodner
Paul F: No clear proposal.
Agreed to postpone for discussion next week.
Marc G: I need to work some more on this.
6.4
PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001
deferred
6.5
PR006 Destination of Seq
faults
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i006
Description
From spec: Line 893
RM Destinations that generate
Sequence faults SHOULD send those faults to the same [destination] as
Acknowledgement messages.
The text is a bit unclear. Does it mean that sending it is optional or
is the EPR it sends it to optional? I
think the intent was just the act of sending it is option, but it must go to
the AcksTo EPR.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Doug Davis
Proposal 12006-10-19
RM Destinations that generate Sequence faults SHOULD transmit those
faults. If the fault is transmitted, it MUST be transmitted to the same
[destination] as Acknowledgement messages.
General agreement.
Chris F moved, Matt seconded to
accept proposal to resolve PR006.
Jacques: what if there is a soap fault along with a sequence
fault. A soap fault for a received
message is going on the soap back channel. Soap faults might go over the request back
channel, rather than the AcksTo EPR.
Anish: you made distinction
between soap faults and sequence faults.
The soap must understand , version mismatch etc
will go over back channel However the
proposed text is scoped to sequence faults, so I am ok with the text as
proposed. Sequence faults are defined in
section 4. If you generate rm faults, the address to send them is the acksTo address.
Bob: these rm “faults” are really
protocol control messages to the acks to, it it not a fault in the sense of other application specs.
Paul: we do not define sequence fault yet. We should define sequence fault as “any of
those faults defined in this spec”.
Paul F: I do not agree to change the name from “fault” is
acceptable.
Marc G: we are using soap faults to transmit these, so they
are faults.
Dug: lets add new term sequence
fault.
Paul F: I propose that we amend Dug proposal by also adding
a new definition for Sequence Fault as “any of those faults defined in this
spec”.,
Paul C: if text refers to named text fault, is that a
sequence fault.
Dug G: sequence create refused is sent to acks to, so it is not a sequence fault.
Chris F: it “sequence fault” is only used twice, why not
change those two places to be clearer.
Chris change text on lines 892 and 893 from “sequence faults”
to “such faults”
Paul C:
Rm destination that generate faults related to know sequences SHOULD transmit those faults. If these faults are transmitted, they MUST be transmitted to the same [destination] as Acknowledgement messages.
Dug moved to amend motion to use the following text,
seconded by Chris F: “Destinations that generate faults related to known
sequences SHOULD transmit those faults. If transmitted, such faults MUST be
transmitted to the same [destination] as Acknowledgement messages.”
§
No objection to amendment.
§
No objection to accepting proposed amended resolution
to resolve Issue PR006.
6.6
PR024 When to send CloseSequenceResponse
vs. SequenceClosedfault
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i024
Description
In section 4.7 describing the SequenceClosed fault one reason the fault must be returned
is that an RMD is “…asked to close a Sequence that is already closed.” However,
in section 3.5 that describes CloseSequence it says
that for a closed sequence the RMD must process all Sequence Lifecycle messages
including CloseSequence. It also says that subsequent
CloseSequence messages have no further effect.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Marc Goodner
Proposal:
Strike the text in section 4.7 saying the SequenceClosed fault should be returned when the RMD is
asked to close already closed sequences.
Chris F: we also have to change the state tables.
Dug D: the editors could update the state
tables.
Dug D moved to accept Marc G proposal, with change to state
tables, Seconded by Marc G.
§
No objection, Issue Pr024 closed with accepting
Marc G proposal and changing state table.
6.7
PR007 RM Destination lacks a mechanism for
cleanly terminating inbound sequences.
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007
Description
Stipulate the following scenario: a
client and server communicate using asynchronous, two-way, reliable messaging.
During the initial sequence creation the client offers a sequence to the server
and this offer is accepted. Some number of requests and responses are exchanged
using the requested and offered sequences. At some later time the user of the
client application causes that application to exit. It is obvious that the
client-side RMS should
clean up the outgoing, client-to-server sequence by sending a wsrm:TerminateSequence message (possibly preceded by a wsrm:CloseSequence message) to the server-side RMS. What is
not clear is what steps the client-side RMD should take to clean up the
incoming, server-to-client sequence. There are three basic courses of action:
1.) The client-side RMD could do
nothing to clean up the incoming sequence. From a distributed systems viewpoint
this seems less than optimal as it leaves the server-side RMS with a
"dangling sequence". If the server-side RMS ever tried to use this
dangling sequence it would engage the entire RMS machinery for messages that
would never get through (send, retry, request acks,
retry, request acks, etc.).
2.) The client could wait for a length
of time sufficient for it to consider the inbound sequence to be
"inactive", then exit. There are a couple of
problems with this. Firstly the user that caused the client to exit may grow
impatient and attempt to terminate the client by other means. Secondly, outside
of the optional expiration time, there is no mutually agreed upon inactivity
period for a sequence.
3.) The client-side RMD could send
a message to the server-side RMS to indicate that the inbound, server-to-client
sequence is being cleaned up. Since the direction of the wsrm:TerminateSequence
message is specified by WS-ReliableMessaging 1.1 as
being from the RMS to the RMD only, this leaves either the wsrm:SequenceTerminated
or wsrm:SequenceClosed faults as the only viable
messages for the client-side RMD to use. This brings up all
the problems attendant with using faults/exceptions to indicate
"normal" application behavior. The server-side RMS may construe the
appearance of a fault as an indication of some lower-level problem, etc.
Note that, although this issue is
discussed in the context of a client application attempting to exit, it is
applicable in any situation where the process/VM that "contains" an
RMD must exit in a relatively short period of time for whatever reason.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Gilbert Pilz
Proposal 12006-10-19
Amend the wording of section 3.6
(Sequence Termination) to indicate that a wsrm:TerminateSequence/wsrm:TerminateSequenceResponse
exchange may be initiated by the RMD.
Dug: why not use close sequence?
Chris F: any RMS or RMD can issue terminatedSequence
Fault at any time. Issueing
a sequence terminated when done would be alright.
Marc G: you are asking for clean shutdown when you are
exceptionally going down. It does not
sound right to me. I worry about other
implications allowing an RMD to terminate a sequence like this.
Jacques: the fault works, unless there is a need to
guarantee common view of state. It would
be good to cleanly terminate sequence from RMD. Terminate sequence might be sufficient.
Chris F: two situations:
1)
client wants reliable
bi dir. When it is done it is done, it does not care about the other side. Final state cleanup is not required. The acks speak for
themselves.
2)
The things fall over dead, let things clear
themselves up.
If client is happy because it got all acks
Tom: why is it not enough to rely on acks. At worst case the sender will think that
messages were not received, when in fact they were. If this is the only state synch issue, I do
not see a reason to go beyond use of sequenceTerminated
fault.
Gil: It would be helpful if an rmd
that knew it was going down, to help the rms get a
better knowledge of the state of the sequence.
Would like to distinguish clean tear down from
catastrophic failure.
Paul F: since this is about helping, perhaps a final
sequence ack could be used to allow the server to
clean up. We can do this without change
of protocol, but could just make a recommendation.
Gil: annotating a sequenceTerminated
fault with a final sequence ack, might suffice.
Gill: a sequenceTerminated Fault sounds
too drastic for a shutdown.
Dug: how about a sub element of terminated
fault to indicate this case.
Paul F: a sequence terminated fault after the final Close.
Gil: an RMD cannot send close sequence or terminate
sequence. However the RMD can send an ack with the Final marker.
Ø
Action: Gil and Paul will work on a new proposal
for Pr0008.
6.8
PR008 Underlying protocol bindings
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i008
Marc G moved (seconded by Dug) to close PR008 with no
action, since underlying protocol bindings are outside of charter.
Jacques: the Authors need to know how to bind to an underlying
protocol.
Marc G: perhaps we should clarify that while this is beyond
our charter, RSP group might be able to deal with
underlying protocol bindings.
§
Issue Pr008 closed without change, and sending
notice to issue author that protocol bindings are out of scope of this group,
but could be dealt with in WS-I RSP group.
6.9
PR009 "Duplicate Elimination" and
"Message Ordering"
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009
Description
2.1 This specification dose not define how to realize "Duplicate Elimination" and
"Message Ordering".
It is a serious issue for industry
organizations in Japan and Asia to adopt the specification.
We strongly recommend to define them to make various implementations
interoperable.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia
Committee
Discussion on closing without action.
Jacques pointed out that we could clarify how you can do
duplicate elimination and message ordering.
Paul F: how about us working on a primer. I could take some clarifications from the
past and produce a first cut at a primer.
Tom: I thought we still have a sentence in the document that
the protocol supports duplicate elimination and message ordering.
1
Any other business
Meeting closed at 5:30 PM Eastern.