Prelim
Minutes of OASIS WS-RX Teleconference
March
09, 2006
Start Time:4:00 PM Eastern
Time
Paul Freemantle acted as
chair.
Textual Conventions
Ø
Action Item
Motion
§
Resolution
1
Roll Call
From Kavi:
xx of 52 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 Mar 2nd, 2006
meeting minutes
4) AI Review
5) Editors update
CD 2 and CD 3 posting etc
6) Raleigh F2F Planning
a> Dial-in sponsorship
b> Update from Doug on
facilities
c> Any
other issues
d> Post F2F timeline
8) New issues since last conf-call
Watch for Marc’s email
9) Issue Discussion:
a> i101 Recommend RMD Close
rather than Terminate
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i101
b> i098 clarify difference
between "sequence" and "non-sequence" faults
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i098
c> i099 Correlating faults to
Sequences using SOAP 1.1
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i099
d> i090 Use of offered sequences
unclear in current spec
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i090
e> i089 suggest the restricted use
of anonymous URI
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089
f> i021 An RM Policy applies
two-way
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021
g> i008 Policy assertions
granularity
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i008
9) Any other business
Paul F stated the implementation SC
had discussion on issue 89. Paul would
prefer to move issue 89 to end of agenda.
Dan Millwood asked that we have a
review of the discussion of the SC on 89 first.
Agreed to limit
discussion on 89.
3
Approval of the 3/2 minutes;
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17061/MinutesWSRX-030206.html
Tom moved and Marc G seconded.
§ Minutes approved by unanimous consent.
4
Action Items
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0056: Ensure that the final WSA specifications include text
for handling of anonymous IRI values for non-WSA EPRs
Owner: Robert Freund
Status: Open
Assigned: 2005-12-13
Due: ---
Bob F: ws addressing group is
proposing final text to w3c. There were
changes around the earlier resolution to issue cr004 from ws-rx
regarding anonymous URI. This will be
sent to the group.
Tom: the ws addressing group is no
longer suggesting reuse of the anonymous uri. However they do not explicitly prohibit it.
#0085: Paul F to write up a more detailed proposal to
Proposed 06 from 3/2
Owner: Paul Fremantle
Status: closed
Assigned: 2006-03-06
Due: ---
#0086: Chris F to provide further rational text for his
proposal for I021
Owner: Christopher Ferris
Status: closed
Assigned: 2006-03-06
Due: ---
#0087: Anish provide explanation
of the desired semantics for I 021
Owner: Anish Karmarkar
Status: closed
Assigned: 2006-03-06
Due: ---
5
Editors update
CD 2 and CD 3 posting etc
Doug D: CD 3 has not been
completed.
Paul F: we need to update our
committee draft folder. It currently
lists cd 1. The public page only lists CD1. We need to ensure CD 2 and CD3 are in the
proper folders in the public and private home page.
Ø
Action: Doug D will post CD2 and CD3 artifacts
on the Kavi Site, with appropriate public page links.
Work with OASIS staff to get public
posting.
Ø
Action: Paul F will give Doug D secretary status
on Kavi.
Paul C: we have to be sure the
namespaces are updated.
Paul C: the namspaces
seem tied to the CD number. We should be
able to keep namespaces constant between CDs.
Ø
Action: Gill will ensure the proper file name
for the namespace document.
6
Raleigh
F2F Planning
6.1
Dial-in sponsorship
TIBCO volunteered for another period for the call.
Shivaji: who do I give the call in
info to.
Paul F: send it to me, also the volunteers from the last
week minutes should send me the call in details.
6.2
Update from Doug on facilities
37 percent has still not voted.
Doug stated there will be continental breakfast, Lunch and afternoon
snack. There is planned to be network connectivity. However there will not be incoming endpoints
available.
Paul C: will this affect interop.
Paul F: Doug should send a note to the interop
SC to see if this may be a problem.
6.3
d> Post F2F timeline
Paul F: we have a tight timeline after this face to face
meeting. We can adjust these dates at
the face to face. We wanted to have a
public review early in April.
Marc G: I have heard about another interop round.
Paul F: the SC has discussed a
public round with identified endpoints, after the public review draft is sent
out. The first interop
is the one which is expected to find issues on the spec.
Marc G: when will we have F2F
agenda, and it should include interop feedback on the
first day.
Paul F: any suggestions for agenda
should be send to Paul F and Sanjay.
7
New issues since last conf-call
Watch for Marc’s email
None
8
Issue Discussion:
8.1
i101 Recommend RMD
Close rather than Terminate
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i101
Paul F posted http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00050.html
Based on CD3/WD10
At Line 365 insert the following
sentence at the period.
For example, a client program may
be in the process of being terminated;
a business
application timeout may mean that there is no reason to
continue
delivering undelivered messages; or a server may wish to
timeout an
sequence that has not been used recently.
At line 367/368 replace the final
sentence of the paragraph with:
To ascertain the final state of the
sequence the RM Source MAY choose to
close the
sequence before terminating it.
At line 381/382 replace the first
sentence of the paragraph with:
In the case where the RM
Destination wishes to discontinue use of a
sequence
it SHOULD close the sequence rather than terminate it, allowing
the RM
Source to ascertain the final state of the sequence.
Bob F: on closure sequenceAckFinal
is sent. I have a concern about “state
of delivery” of messages. If an RMD has implemented ordered delivery, and if
there is a message out of order, there is an expressing of missing message. However the application would not receive all
of that, only up to the gap.
Paul F: I think this is worth point out as a new issue, however it is different than this one.
Tom R: I agree we could file a new issue on clarifying use
with deliver status vs received status. Implementations would likely make the waiting
messages available to the receiving application at termination time.
Doug D moved to accept proposal for issue 101, Tom R
seconded.
§
No opposition, proposal for issue 101 accepted.
8.2
i098 clarify difference
between "sequence" and "non-sequence" faults
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i098
Gil posted proposal at: http://lists.oasis-open.org/archives/ws-rx/200603/msg00063.html
The lines 659-663 in
http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf
(excluding the first word of the sentence starting with "Sequence faults
SHOULD . . .") should be changed to read:
The faults defined in this section
fall into one of two categories; those faults that are the result of messages
or operations within a specific Sequence and those faults that are not. By
their nature the CreateSequenceRefused, UnknownSequence, and WSRMRequired
faults cannot be correlated with a Sequence. All other faults defined in this
section relate to the processing of WS-RM protocol messages or messages
containing WS-RM header blocks targeted at a specific Sequence and are
collectively referred to as "sequence faults".
Chris F moved to accept proposal from Gil to resolve i098,
seconded by Charleton.
Doug B: why are we making this distinction.
Gil: you have to ensure the entity is authorized for the
sequence.
Doug B: I understand why implementations need to treat
messages and faults according to security policy, however I an
not clear where this distinction needs to be made in the spec.
Gil: are you proposing a different solution.
Doug B: I am asking why we need to say anything about
this. Perhaps we can delete the text
referring to sequence faults.
Gil: I would favor this change now, and have future issues
raised as required.
Paul F: the spec already uses the term sequence faults, this adds a clarification of that term.
Doug D: I see this as mostly harmless.
§
No objections, issue i098 resolved with Gil’s proposal.
8.3
i099 Correlating faults
to Sequences using SOAP 1.1
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i099
Gill proposal posted as: http://lists.oasis-open.org/archives/ws-rx/200603/msg00064.html
With reference to
http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf:
After line 710 insert:
<wsrm:Detail> [Detail] </wsrm:Detail>
Change lines 738-741 (<wsrm:SequenceFault> exemplar)
to:
<wsrm:SequenceFault ...>
<wsrm:FaultCode>
wsrm:FaultCodes </wsrm:FaultCode>
<wsrm:Detail>
...
</wsrm:Detail>
?
</wsrm:SequenceFault>
After line 746 insert:
/wsrm:SequenceFault/wsrm:Detail
This optional element is intended
for carrying application specific error information related to the fault being
described.
/wsrm:SequenceFault:/wsrm:Detail/{any}
The application specific error
information related to the fault being described.
(corresponding
changes to wsrm-1.1-schema-200602.xsd left as an exercise for the monkeys)
Chris F moved, Doug D seconded to
resolve I099 with Gil’s proposal.
§ No objection, accept Gill’s
proposal to resolve I099, mark as pending.
8.4
Discussion from interop
SC
Paul F discussed an issue about the interop
scenarios, regarding the anonymous URI.
Paul F: two issues.
In order to get a missing response message, it is required to resend the
actual request messages for which that is a response
to. This is not written down.
Tom R: why does the rms have to
save after it gets an Ack.
Paul F: the problem is the response might be lost. The
request was acked so the rms
could delete the request. However to get
the response again the rms has to resend the request,
even after it acked.
Gil: this is only a problem in synchronous case when rm semantics are applied to response.
Glen D: this raises a concern, if you do not know if
something other than rm machinery will occur. It requires duplicate elminiation
in some business cases. The sender needs
to know if ther will be duplicate detection.
Paul F: how is this different than rm
in a one way case
Glen D: you might resend either way.
Tom R: I agree that to make this work both sides need to
know what is going on. Our sister WSRM
TC has be discussing how to do reliability on synchronous response for a while.
It requires both sides to know there is reliability on synchronous response. We
could add things to our protocol to make such knowledge available. We could use extra information on the Create
Sequence to exchange this knowledge.
Chris F: In this case, the response must be carried on the
http response. To carry the response
again you have to resend the message.
There was considerable discussion on the repercussions of
this apparent dilemma.
Paul F: other points need to be made. The 2.4 scenario from
Microsoft, talks about timing of when acks are
delivered back.
Paul F: regarding Tom’s point, I agree that both sides need
to know what is going on. The offer
cannot be treated as an uncorrelated sequence.
We need to add words that has special semantics
in the request/response binding to soap. The Apache stack cannot yet handle this,
because it deletes on receipt of the ack.
Doug D: if this scenario causes problems, we could take it
out of the test cases.
Dave O: is the question for this upcoming interop event, or the follow on event. If it is only for
this event, the case could be dropped. It
can be added later after the TC has concensus.
Paul C: we need solid pointers to the documents being
discussed. Having this on this interop gains us more data. If we successfully interop on this scenario, we can gain knowledge. Why drop it on this list of things. It does
not have to be implemented by all.
Tom R: this is related to the I021 discussions. If the default on a request response endpoint
is reliability for both request and response, we have to have the mechanisms in
place to make this happen. We could
decide to not require reliability in response.
If reliability in response is required, the sender must do extra
buffering beyond the first ack.
Further discussion ensued on the assumptions on behavior for
this scenario which are not written down, with respect to the interop scenarios taking place.
Meeting closed at 5:32 pm. Eastern time.