Prelim Minutes of OASIS WS-RX Teleconference

Junk 8, 2006

Start Time:4:00 PM Eastern Daylight Time

Sanjay acted as chair.

Textual Conventions

Ų Action Item

Motion

§ Resolution

1 Roll Call

From Kavi:

Over 42 of voting members, 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 Jun 1, 2006 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18625/MinutesWSRX-060106.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> i089 suggest the restricted use of anonymous URI

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089

b> i121 security threats and requirements

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121

c> i122 security profiles

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122

d> i124 security composition policy

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124

e> i123 security profile agreement

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123

f> i125 Protocol precondition requires knowledge of policies

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125

7) Any other business

Sanjay suggested we add Two new agenda items after AI Review regarding

WD schedule
Sponsorship of Teleconf facilities.

3 Approval of the 6/1 minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18625/MinutesWSRX-060106.html

Tom R moved, Marc G seconded to approve 6/1 minutes.

§ No objection minutes for 6/1 meeting approved.

4 Administrative

4.1 AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

#0100: Tom Rutt & Bob volunteered to work on state table revisions with Jacques

Owner: Jacques Durand

Status: Still Open

Assigned: 2006-05-09

Due: ---

--------------------------------------------------------------------------------

#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: ---

--------------------------------------------------------------------------------

#0104: Gill will clarify his proposal for i121 to clarify the relationship between requirements and the threats

Owner: Gilbert Pilz

Status: Still Open

Assigned: 2006-05-30

Due: ---

4.2 WD review

Marc G: the comments that were raised as new issues fix the problems the members found.

Paul C: will the editors revise the document to fix the problems.

Doug D: I have opened up issues on the ones which are not purely editorial.

Sanjay: Have editors have another review draft leaving the minor editorials.

Doug B: why, the editors can point to the email for the editorial comments. As a reviewer I do not see a substantial difference between having to correlate changes with email comments, than with issue resolutions.

Paul F: we expect the editors to do a lot of work over next month, leaving editorials for later gives them more time. Wait till all the new issues are resolved before a new version.

Paul F: I would prefer a next document to include all the new issues raised.

Paul C: I want to ensure the editors have a plan for WG progression.

Sanjay: No opposition to next draft having both changes from issues and comments made, with appropriate annotation as to source of comment.

Doug D: we could make a draft available with all issues accepted today by next week. Our intermediate editor’s drafts will all be made visible to TC.

4.3 Conf Call Hosting Volunteers

BEA

Nortel

Microsoft

Need others for future.

5 New issues since last conf-call

5.1 Proposed 08

From Doug D: http://lists.oasis-open.org/archives/ws-rx/200606/msg00053.html

Title: Make Accept/AcksTo consistent

Description/Justification:

The definition of CS/AcksTo says:

... It specifies the endpoint reference to which messages containing

<wsrm:SequenceAcknowledgement> header blocks and faults related to

the created Sequence are to be sent, unless otherwise noted in this

specification (for example, see Section 3.2).

However, the Accept/AcksTo says:

... The RM Source SHOULD send messages with <wsrm:SequenceAcknowledgement>

header blocks related to the accepted Sequence to the referenced endpoint.

This is a bit inconsistent since the 2nd one doesn't say anything about

sending faults the EPR. Since the Offered sequence should be no different

from a sequence created using a CS we need to align these two

definitions.

Target: wsrm spec

Type: design

Proposal:

Modify the Accept/AcksTo to say:

... Like the wsrm:CreateSequence/wsrm:AcksTo element, this element

specifies the endpoint reference to which messages containing

<wsrm:SequenceAcknowledgement> header blocks and faults related to

the offered Sequences are to be sent, unless otherwise noted in

this specification (for example, see Section 3.2).

Implementations MUST NOT use an endpoint reference in the AcksTo element

that would prevent the sending of Sequence Acknowledgements back to the

RM Source. For example, using the WS-Addressing "none" IRI would make it

impossible for the RM Destination to ever send Sequence Acknowledgements.

I basically stole the CS/AcksTo text.

No objection to accepting proposed 08 as new TC issue.

5.2 Proposed 07

From Doug D: http://lists.oasis-open.org/archives/ws-rx/200606/msg00045.html

Title: define unspecified IncompleteSequenceBehavior

Description/Justification:

When CSR/IncompleteSequenceBehavior is not present the spec is

silent on what the default value might be. We should be clear

that there is no default value.

Target: wsrm spec

Type: design

Proposal:

Add the text in bold:

/wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior

This optional element, if present, specifies the behavior that the RM Destination will exhibit upon the

closure of an incomplete sequence. If omitted, there is no implied value.

Doug D: Matt has pointed to the correct text in the document. I would like to withdraw this proposal.

Matt we should put the line number in.

Doug D: Line 317 has the text which I missed before.

Doug B: I move to accept proposed 07 as new issue, and to close with no action, since line 317 covers what is missing. Seconded by Marc G.

§ No objections, proposed 07 closed with no action, since line 317 is acceptable.

5.3 Proposed 06

[NEW ISSUE] Define "discard" Doug Davis

Title: Define "discard"

Description/Justification:

In WD13.pdf section 3 - line 308++ - should we define "discard" - its not

clear to me that we mean the discarded messages will NEVER (and have

never) be delivered to the AD, instead of just "from now on the RMD

won't deliver them".

Target: wsrm spec

Type: design

Proposal:

Modify the text for IncompleteSequenceBehavior to be (new stuff in bold):

(Chris/Bob is this new stuff consistent with what you guys wanted?)

/wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior

This optional element, if present, specifies the behavior that the RM Destination will exhibit upon the closure of an incomplete sequence. For the purposes of defining the values used, the term 'discard' refers to the RM Destination never delivering a particular message to the AD.

A value of “DiscardEntireSequence” indicates that the entire sequence will be discarded by the RM Destination if the sequence is closed when there are one or more gaps in the

SequenceAcknowledgement/Final. Note, this means that the RM Destination will not deliver any messages to the AD until the final SequenceAcknowledgement is determined and there are no gaps in it.

A value of “DiscardFollowingFirstGap” indicates that messages in the sequence beyond the first gap will be discarded by the RM Destination when there are one or more gaps in the SequenceAcknowledgement/Final.

The default value of “NoDiscard” indicates that no acknowledged messages in the sequence will be discarded by the RM Destination.

No objections to accepting Proposed 06 as new TC issue.

5.4 Propose 05

[NEW ISSUE] What does ack interval refer to Doug Davis

Title: what does ack interval refer to

Description/Justification:

In WD13.pdf section 3 - line 301 - defines the AckInterval element as:

This element, if present, specifies the duration after which

the RM Destination will transmit an acknowledgement. If

omitted, there is no implied value.

'after' what? It isn't clear when this mystery timer is kicked off.

- "...specifies the duration after which the

RM Destination will transmit..."

After what?

It should say 'after receipt of a message' or something like that.

Target: wsrm spec

Type: design

Proposal:

Replace the above text with:

This element, if present, specifies the maximum duration, after

receipt of a reliably sent message, which the RM Destination will

wait before transmitting an acknowledgement. If omitted, there is

no implied value.

This still allows the RMD to send it sooner if it wants to.

Doug B: I think the proposal changes the semantics, however I am in favor with accepting as a new issue.

No objections to accepting Proposed 05 as New TC issue.

5.5 Proposed 004

[NEW ISSUE] Remove sections 1.1 and 1.1.1 Doug Davis

Title: Remove sections 1.1 and 1.1.1

Description/Justification: there's no text in there so there's no reason to keep 'em

Target: wsrm spec

Type: design

Proposal: remove sections 1.1 and 1.1.1

No objection to accepting as new issue.

Marc G moved to accept proposal to resolve proposed 04

§ No objection, proposed 04 closed with proposal to resolve

5.6 Proposed 003

NEW Issue: Change default value of fault uri Marc Goodner

Title: Change default value of fault uri

Description: The default value for the fault uri is set to the default value of the WS-A faults. WS-A Rec says this value should only be used for WS-A faults. We need to define our own default uri for faults.

Target: core

Type: design

Proposal:

In section 4 change:

Entities that generate WS-ReliableMessaging faults MUST include as the [action] property the default fault action IRI defined in WS-Addressing. The value from the W3C Recommendation is below for informational purposes:

http://schemas.xmlsoap.orgwww.w3c.org/ws/20045/08/addressing/fault

To:

Entities that generate WS-ReliableMessaging faults MUST include as the [action] property the default fault action IRI defined below:

http://docs.oasis-open.org/ws-rx/wsrm/200604/fault

Marc G: someone has asked that the word “default” be removed. I can agree with that.

Doug B: I agree with Peter N comments on email. If this is a MUST, why is it a default.

Marc G: I agree with striking the word default.

No objection to accepting as new issue.

Tom R moves to accept the following replacement to resolve new issue proposed 02, Gil seconded.

Entities that generate WS-ReliableMessaging faults MUST include as the [action] property the fault action IRI defined below: http://docs.oasis-open.org/ws-rx/wsrm/200604/fault

§ Motion to resolve proposed 03 resolved.

5.7 Proposed 02

NEW Issue: Duplicate text in fault section Marc Goodner

Title: Duplicate text in fault section

Description:

In Section 4 of WS-RM the first two paragraphs of this section are practically duplicates of each other.

Target: core

Type: editorial

Proposal:

The first paragraph can be stricken by adding a one sentence description of WSRMRequired after the second sentence of the second paragraph in Section 4.

Agreed to accept proposed 02 as a new issue.

5.8 Proposed 01

NEW Issue: Update acknowledgements Marc Goodner

Title: Update acknowledgements

Description:

In the Acknowledgements, Section E of WS-RM and Section A of WS-RM Policy, the TBD needs to be updated to reflect the individuals who contributed to developing the spec in the TC.

Target: core, policy

Type: editorial

Marc G: we could assign this to an owner, and perhaps Defer.

No objections to accepting as a new Issue.

6 Issue Discussion:

6.1 i089 suggest the restricted use of anonymous URI

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089

Sanjay: Doug D posted the combined proposal on the list.

Doug D: I posted a compromise proposal last week. We also had some discussions on the mail list.

Jacques: I do not have strong concerns about the proposal, however the corner cases might need clarification. I would like to take another week to nail down the remaining loose ends to resolve my comments on the list.

Sanjay: Are your concerns substantive, or are they editorial corrections. Could we accept this today, and work you changes as new issues or comments.

Jacques: While I do not want to hold back this issue too long, I am not sure my concerns are editorial. If anyone moved to accept I would abstain, and would submit new issues to resolve any concens.

Marc G: I would like another week on this proposal as well. We have been looking at this proposal with our security team. The URI plus UUID method has problems on being secured. We still view this proposal and the entire issue as outside the scope of this TC.

Doug B: I agree with both Jacques and Marc G. There have been answers provided on the list to several concerns expressed, but they are not reflected in the text proposed by Doug. This needs to happen to make the text clear. We may need a special majority vote to change the Charter to add this new soap binding.

Dave O: If the changes were made, would that make you be in a position to get you to vote yes on the resolution.

Doug B: I am pretty sure that there is inefficiency to work on this before we change our charter.

Anish: I feel that our use cases put this mechanism within the scope of the charter, particularly the suport a sender behind a firewall.

Doug D: I am ok with postponing a week, but forms of the proposal have been out there for quite some time. It is depressing to wait to day of TC call to get any serious comments on it.

Sanjay: I agree with Doug D, and ask all TC members to have their comments sent soon on the list.

Paul C: lack of email on list does not mean that there is no activity going on. There are lots of out of band discussions and work going on.

Jacques: I do not think we should be pressured. This is the major issue we have to deal with, and it deserves sufficient time to resolve properly. I am not sure that this polling must not be visible outside the RM component.

Dave O: We could have a number of comments made on this proposal that would make it better. I am leery to put off the vote on this thing, If the comment resolutions will not change anyone’s vote. We know the opinions of Doug B and Marc G, but others seem to be silent.

Umit: I move to accept the Compromise proposal from Doug D http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00310.html to Resolve Issue 89, seconded by Martin C

Paul C: to Reiterate our concerns, we have spent time to analyze in detail, we are working with our security team and the co-authors to come up with an acceptable solution. I speak in opposition to the motion.

Glen D: I have not had sufficient time, I would like another week, while I am in general agreement with the direction.

Doug D: I do not want to pressure anyone, however for those who have minor concerns, any text added to the document with a no vote, can be changes by future issues being raised.

Dave O: I asked for comments on needing more time, and Glen D responded. Are there others that need more time to make a yes or no decision? I still recommend a yes vote, since the text could be changed.

Doug B: I like the Idea about calling the motion on the floor to resolve it. The exact text in the proposal vs a vote on continuing in this direction could be separated.

Umit: There are some folks who do not want this approach in the spec at all. I am not convinced that tinkering with this proposal will change their opposition. If we put the text in, we can better deal with resolving specific issues remaining.

Paul C: In our technical view, this compromise is a union of other proposals. There are some security risks in part of the proposal. If we put the entire union in, it will be more difficult to take the problem part out of the document.

Anish: What are the specific security issues.

Paul C: we supplied the comments offline from our security experts to some of the authors of the merged proposal, but have not sent to the TC yet. As soon as our security experts come up with countermeasure for the threat, we could be ready. We could send something to the TC early next week.

Dave O: Lets assume the proposal is modified to deal with your security concerns, and all the merger authors agree with your changes, would Paul be in a position to vote yes on the amended proposal.

Objection to Unanimous Consent from Paul C.

Vote:

19 Yes

9 No

§ Motion to accept compromise proposal posted by Doug D for resolve issue 89 was accepted.

6.2 b> i121 security threats and requirements

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121

Gil: since I have not completed my action item, I would prefer we do not resolve this today. I intend to post a new proposal by Monday.

Sanjay: we should have discussion on the list soon.

Chris F: Gil should remove all forward references to other unresolved issue resolutions

Paul C: can Gil give us an overview of changes.

Gil: For each threat I added expected countermeasures I then discuss soap level security and transport level security, and how each can be used for countermeasures. I also added text relating to “co-ownership” of protection. I also removed section 5.4 and 5.5 from the earlier proposal.

Sanjay: could Gil post a summary of his changes to the list before Monday, to allow comments from members.

6.3 c> i122 security profiles

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122

Gil: there has been a counterproposal for 122, 123 and 124, could the authors review it.

Chris F: this proposal http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00036.html is similar to the earlier security token reference text in the submission. A difference is that this new header can be marked with soap:mustUnderstand. There is also a policy assertion to indicate whether this security token feature is to be used. A conformant endpoint need not do anything to support this mechanism, while it does provide security from issuer that it will be used if requested, or the sequence will not be set up.

Marc G: Bob raised another issue message 62, wd13 missing resolution to issue 106.

Ų Action: editors to determine if issue 106 resolution has been incorporated into the WD.

Paul C: this proposal follows advice from TC vote, in that it uses the soap header and the soap:MustUnderstand to indicate to the receiver that a particular form of security is required.

Gil: Is it required that the lifetime of the session indicated in the STR be greater than the particular sequence?

Marc G: a security context should be less than the lifetime of the sequence.

Gil: I pass a STR that references a security context at create sequence time. When it expires, the sequence can still be alive. When the next message comes on sequence after expiry, how does the receiver behave?

Stefan: the text should clarify that the security context lifetime should be the same as for the sequence itself.

Gil: Then your are saying that the lifetime of the sequence is bounded to the length of the lifetime of the security context.

Doug D: one issue with earlier 122 proposals was the overlap of perceived work of WS-I. I am wondering why this does not run into same kind of issues for us defining any specific security profile.

Umit: does this mean that is must be understood, and as such is a capability required by all rm implementers. This needs to be discussed.

Sanjay: Doug B and Umit should post there questions to the email list.

7 Any other business

none

ws-rx message

1 Roll Call

2 Agenda Approval

3 Approval of the 6/1 minutes;

4 Administrative

4.1 AI Review

4.2 WD review

4.3 Conf Call Hosting Volunteers

5 New issues since last conf-call

5.1 Proposed 08

5.2 Proposed 07

5.3 Proposed 06

5.4 Propose 05

5.5 Proposed 004

5.6 Proposed 003

5.7 Proposed 02

5.8 Proposed 01

6 Issue Discussion:

6.1 i089 suggest the restricted use of anonymous URI

6.2 b> i121 security threats and requirements

6.3 c> i122 security profiles

7 Any other business