Prelim
Minutes of OASIS WS-RX Teleconference
July 27, 2006
Start Time:4:00 PM Eastern
Daylight Time
Sanjay 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 Jul 20th, 2006 meeting minutes
http://www.oasis-open.org/committees/download.php/19312/MinutesWSRX-072006.html
4) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
5) New issues since last conf-call
Watch for Marc’s email
6) Issue Discussion:
a> i140 add sub-headings to
fault descriptions
http://lists.oasis-open.org/archives/ws-rx/200606/msg00190.html
b> i143 messages have to be
received for them to be examined: with new highlighting
http://lists.oasis-open.org/archives/ws-rx/200606/msg00200.html
c> i145 Implications of Sequence
Expiration not specified
http://lists.oasis-open.org/archives/ws-rx/200606/msg00216.html
d> i113 Tightening up the state
tables
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i113
7) Ideas/Planning for Next Interop
8) Any other business
Sanjay: Issue 134 was asked to be placed on the agenda at
the end.
Chris F: I would like to have discussion today on the public
review draft progression.
Agreed to put before issues discussion.
Paul F asked that the interop
discussion be moved to a future call.
No objection, Agenda item removed.
3
Approval of the Jul 20th, 2006 meeting minutes
http://www.oasis-open.org/committees/download.php/19312/MinutesWSRX-072006.html
Doug D moved, Chris F seconded to
approve July 20 minutes.
§
No objecton, July 20
minutes approved.
4
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0102: Marc G will prepare to start an issues list for
Public review comments
Owner: Marc Goodner
Status: Still Open
Assigned: 2006-05-22
Due: ---
#0106: Bob address polling in the state tables (once the
first round of state table changes are stabilized)
Owner: Robert Freund
Status: Closed
Assigned: 2006-07-03
Due: ---
#0107: Bob and Anish to develop
proposal for i140 resolution
Owner: Robert Freund
Status: Closed
Assigned: 2006-07-03
Due: ---
#0109: Doug D to provide text to resolve I145
Owner: Doug Davis
Status: Closed
Assigned: 2006-07-24
Due: ---
5
Planning PR and next steps.
Sanjay: 5 open issues are left. We are close to closure on all issues. The editors must create a draft which accommodates
all resolutions, and is voted by the TC.
I has taken 3 weeks for review and vote of
CDs. Thus 3-4 weeks is a target.
Chris F: I think we do not have to wait for all these final
issues. If post PR changes warrant a
subsequent review, we should determine if the remaining issues constitute a
substantive change if deferred to after PR.
I would like to see a PR draft before the end of August.
Marc G: I agree that we need to have PR soon to get out by
the end of the year. I do think we have
a chance of closing outstanding issues soon.
The Editors have been posting frequent updates, so we should not require
a long review.
Chris F: whatever we agree to today should produce a draft which
we can vote by the 10th of August. The security issues were the last significant issue.
State Tables and dotting I’s can be done with public review.
Sanjay: Draft by Aug 3, one week review, then draft by Aug 10.
Candidate draft by 17th.
Bob F: I move we close action towards PR to reflect only issues
which have been resolved today. Chris
Seconded.
Doug D: I think I have a few lower level issues around the
security work. I am not sure they will
not require substantive changes. We may
be able to vote on this at the beginning of next weeks meeting. I speak against the motion.
Martin C: I have sympathy with both views. I am uncomfortable with very little notice of
this motion.
Martin: I move to amend this motion to be as of issues closed
at next week call, Chris F seconded.
Sanjay: Given CD Candidate review from 3-10, would current schedule
be acceptable. A vote could be in week
of August 14th.
Bob: I can accept the modification.
Marc G: the last defined plan for moving to PR was end of
June. There should be no surprises,
given the current state of the issue resolutions.
Gil: Why not vote on this amendment. The discussions seem to indicate a need for
one more week. With focus, we can have a
stable draft soon.
Chris F: anyone can vote no on the PR draft. But if only minor editorials exist, we should
consider it done. PR means we are
basically done, and put it out to community for their comments. We can fix prose after that.
Martin C: end of next week is the final time. Ship as of that time.
Chris F objected to amendment.
Ashok: A 1 week review period seems very short. One week is very short.
Vote on amendment:
11 Yes
12 No
§
Amendment fails
Martin: by closing today we go to public review with open
issues.
Chris F: the issues are not substantive. I did not want an extended discussion.
Glen: I call question
Sanjay: anybody object to call question. No objection
Vote on Motion:
11 Yes
14 No
§
Motion Fails
Agreed to have chairs propose schedule to
TC before next week.
6
New issues since last conf-call
Watch for Marc’s email
6.1
From Gil:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00140.html
Title: Need fault to indicate that
security constraints have been
violated.
Description: There is currently no
mechanism for the RMS or RMD to
indicate
(either to each other or an administrator via either a log file
or some
other mechanism) that the agreed upon security constraints have
been
violated.
Justification: Suppose that the RMS
and RMD have agreed that all the
messages
related to a particular Sequence should be protected by a
specific
Security Context. What should the RMD do when it receives a
message
that contains a Sequence Header with an ID that matches that
Sequence but which is signed by
some other Security Context Token?
Obviously there are a whole range
of answers to that question depending
upon the
environment (production or development), security policies,
etc. but
it seems that most of these answers would include the notion of
generating
a fault to indicate what has happened.
Target: core
Proposal: Add the following fault
to Section 4:
4.x
Security Violation
This fault is generated by either
the RM Source or the RM Destination in
response
to a message that violates the agreed upon security constraints
for the
Sequence to which the message applies.
[Code] Sender
[Subcode]
wsrm:SecurityViolation
[Reason] The received message
violates the security constraints for its
related
Sequence.
[Detail] xs:any
Gil: the text is not complete, since it needs to be included
in text elsewhere in the spec. We should
not mandate that the sequence should be terminated.
Tom: what about attack situations. Do you have to generate this fault.
Gil: that is covered by generate words.
No objection to accepting Gil’s New
issue.
Ø
Action: Gil will draft complete proposal for
this new issue.
6.2
Glen new issue:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00179.html
Need an example for make connection stuff.
No objection to new issue.
Chris F moved to move new issue to pending, with editors to
produce example text, seconded by Glen.
§
No objection, motion to resolve glen new issue
accepted.
7
Issue Discussion:
7.1
i134
Marc G moved to accept proposal for acknowledgements from
Doug D, seconded by Bob F.
§
No objection, issue i134 resolved by Doug D
proposal.
7.2
a> i140 add sub-headings to fault
descriptions
http://lists.oasis-open.org/archives/ws-rx/200606/msg00190.html
http://lists.oasis-open.org/archives/ws-rx/200607/msg00149.html
Anish there was some discussion on
this.
Jacques: there is a need for a minor amendment to this
proposal.
Doug D: I would like to offer amendment to change invalid ack 1 to not close sequence, and to change the action for sequence
close to be close rather than terminate.
Bob: I am fine with the sequence closed amendment, but the invalid
ack is of concern.
Doug D: I am uncomfortable with the demand that it must.
Bob: I would prefer to make it a SHOULD for invalid ack.
Jacques: we need to clarify what triggers these errors in the
text.
Anish: this is reasonable.
Bob F: 1) change sequence close to close.
Bob F: 2) invalid sequences caused by section 6, should they
occur the Sequence SHOULD be closed.
Chris F: what about recovery scenarios. MUST or SHOULD are
too strong. MAY is better.
Bob F: the protocol to live up to the description of
reliable protocol has an error condition where reliable transfer is seriously
in doubt. We need this to have a
concrete protocol.
Matt: I am not convinced “unknownSequence”
return is broken. It could be a
transient failure on other end. The RMD
can continue to send acks back to rms
at words case. Even saying MAY can screw
up some service implementations.
Gil: invalidAck Fault is not even
assured to be send by correct RMD. A reasonable implementation might, if ack looks wrong, send another ack
request, assert it again, and then close sequence. Closing the sequence for invalid ack seems too strong.
Bob F: the ack of message which
has not yet been sent. The RMD might
have received from somebody else. It
will not occur for random comm. Hit, it is likely to
be due to a bad implementation.
Doug D: how about repeating text that the rest of the spec
already has in it.
Chris F: I agree with Gil, if you get spoof acks you might get one that is real that you can deal with
it. I do not think it is necessary for
the spec to make such a statement.
Discussion on state reconciliation.
Anish: If you have global view,
the system goes thru a set of fixed states.
The sender and receiver have views, at any time, of this global
state. In the case Bob is talking about
is if one system has a view of a state which is outside this global schema.
Doug D: I think Bob agreed to accept my amendment.
Doug D: I move to accept proposal with following amendments,
seconded by Chris F.:
seqClosed - change 'terminate' to
'close'
InvalidAck - change action to 'unspecified'
Anish: Bob is worried about a
vague protocol error.
Bob: we can defer that until the state table discussions or
other potential issues.
jacques: invalidAck: "Reason" should be: violate the
invariants stated in 2.3 OR any of the
requirements in 3.6 about valid combinations of AckRange,
Nack and None in a single SequenceAcknowledgement
element or w/r to already received such elements
Doug B: what about Jacques amendment.
Doug B: I move that we add Jacques text somewhere in the
document (perhaps as a note), seconded by Jacques.
§
No objection to amendment,.
§
No objection to accept amended motion to resolve
i140, to move to pending.
7.3
> i145 Implications
of Sequence Expiration not specified
http://lists.oasis-open.org/archives/ws-rx/200606/msg00216.html
Doug D an Bob have come up with
text, in email:
DougD and
I have jointly put together the following proposal for the closure of issue 145
Insert the following text following
line 399 in WD 15 version of July 21
This element, if present, of type xs:duration specifies the amount
of time after which any resources associated with the Sequence SHOULD be
reclaimed thus causing the sequence to be silently terminated. At the RM Destination this duration is
measured from a point proximate to Sequence creation and at the RM Source this
duration is measured from a point proximate to the successful processing of the
CreateSequenceResponse.
Doug D moved to resolve i145 with proposal above, Marc G
seconded.
§
No objection to resolve i145 with proposal from
Bob and Doug D.
b> i143 messages have to be received for them to be
examined: with new highlighting
http://lists.oasis-open.org/archives/ws-rx/200606/msg00200.html
Bob F email http://lists.oasis-open.org/archives/ws-rx/200607/msg00146.html
Marc G moved to accept Bob F proposal to resolve i143,
seconded by Doug D.
Jacques: I have some editorial comments on the list. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00148.html
Doug B: Editors need to take Jacques edits into account.
Agreement to let Editor’s reflect
Jacques edits:
- successfully
accepted à accepted, and: successful acceptance à acceptance (L146,
L147, L201, L305)
- "Receive" definition
can be shorter: The act of reading a message from a network connection and
accepting it.
- I'd say no need to change
"receive" into "accept" in section 3.6, as receive is OK
there and more intuitive. ("accept" is only
needed where a specific RMD behavior is required, as I understood it)
§
No objection to resolve i143 with Bob F
proposal, and editors to reflect Jacques proposed edits.
7.4
d> i113 Tightening up the state tables
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i113
Bob F: I posted a new table.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00142.html
I need to change two cells to reflect
agreements we made today.
Changes needed:
- table to be revised with new headings for the
last two new tables reflecting anon and non anon endpoints
- expiry
behavior will be completed per resolution
- blank
cells indicate where implementations MAY gen seq terminated faults
Marc G: I move to accept Bob’s email to resolve i113 , with the three changes above. Bob F seconded.
Matt: make connection can be uses for non anonymous
endpoints. I would not like to be never
possible.
Marc G: the table headings should be left to the editors to
change to clarify.
§
No objection to resolve issue i113 with amended
state tables from Bob.
Editors agreed to have new editors draft before next week
call incorporating all agreements.
8
Any other business
none