OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Preliminary Minutes of wsrx 7/27 teleconf

Prelim minutes are attached.

I cannot post corrections to these draft minutes before next week's 
call, since I am going on vacation friday morning.

Tom Rutt

Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Minutes of OASIS WS-RX Teleconference

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




1         Roll Call

From Kavi:


, meeting is quorate


Tom Rutt agreed to take minutes.

2         Agenda Approval


1) Roll Call


2) Review and approval of the agenda


3) Approval of the Jul 20th, 2006 meeting minutes



4) AI Review



5) New issues since last conf-call

Watch for Marcs email


6) Issue Discussion:

a> i140 add sub-headings to fault descriptions


b> i143 messages have to be received for them to be examined: with new highlighting


c> i145 Implications of Sequence Expiration not specified


d> i113 Tightening up the state tables


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



Doug D moved, Chris F seconded to approve July 20 minutes.

    No objecton, July 20 minutes approved.


4         AI Review



#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 Is 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 Marcs email


6.1      From Gil:


Title: Need fault to indicate that security constraints have been



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 Gils New issue.


  Action: Gil will draft complete proposal for this new issue.


6.2      Glen new issue:



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





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



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



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 Editors 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



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 Bobs 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



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]