Prelim Minutes of OASIS WS-RX Teleconference

May 11, 2006

Start Time:4:00 PM Eastern Daylight Time

Paul F acted as chair.

Tom Rutt took minutes

Textual Conventions

Ų Action Item

Motion

Resolution

1 Roll Call

From Kavi:

xx of 43 voting members, meeting quorate

2 Agenda Approval

1) Roll Call

2) Review and approval of the agenda

3) Approval of minutes from May 4th 2006

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00057.html

4) Administrative Issues

5) AI Review

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

6) New issues since last conf-call

Wait for email.

7) Issue Discussion:

a> i089 suggest the restricted use of anonymous URI

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

TABLED MOTION:

Marc Goodner moved to accept the minimalist proposal for i089

http://lists.oasis-open.org/archives/ws-rx/200605/msg00023.html

b> i115 Gilbert Pilz "must understand" attribute for extensions to RM components

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

c> i119 Piggybacking

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i119 (Not yet in action)

d> i113 Tightening up the state tables

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

8) Any other business

Colleen asked for a schedule item to be placed on the agenda.

Paul F stated we have new security issues added to the new issues.

Paul F stated three points:

1) when new issues are presented, they should be examined based on the description, not the proposal attached.

2) When a motion is made, we discuss until resolution or tabling. The motion raised is not the end of the discussion.

3) We aimed to get to CS within a year. We are not in the position to do that now. We have to close down the issues list soon. Timing is critical for a standard.

Tom R stated that a tabled motion has no status after closure of the meeting in which it was tabled..

Paul F stated that his reading of the Roberts rules is that the motion is still open.

Colleen: I think that the TC needs to consider grounded concerns about schedule. The chairs should clarify the schedule.

Sanjay asked that the agenda item for 113 be postponed.

Martin: I agree that new issues have to have a high bar of approveal

1 Approval of the past minutes;

5/4/2006 meeting minutes

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

Tom moved to post minutes as posted on Kavi, Matt seconded to approve 5/4 minutes

No objection minutes for 5/4 meeting approved.

2 AI Review

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

#0099: Gill and Doug B will work to carry out resolution of issue 93

Owner: Gilbert Pilz

Status: Gill provided an update to the spec. He wants additional discussion on some details of the resolution. The phrase “this REQUIRED Element” was changed. Cardinality is indicated other places, and Gill stated that there is a reduncancy.

Assigned: 2006-04-17

Due: ---

Doug B thanked Gill for his work, and he agrees with Gill’s proposal. He wants the group to discuss on relying on exemplars.

Umit asked if the text changes are complete now.

Close action item, review will go on action item for next week.

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

Owner: Jacques Durand

Status: Still Open

Assigned: 2006-05-09

Due: ---

3 New issues since last conf-call

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00146.html

Proposed-01 (editorial) misplaced paragraph on action IRI's

http://lists.oasis-open.org/archives/ws-rx/200605/msg00087.html

Lines 120-123 of discuss the use of action IRI's. This seems out of place at this point in the document. This paragpragh should be moved to the first paragraph of Section 3 where we discuss the RM Protocol Elements.

proposal: Move lines from 120-123 to a spot inbetween lines 232-233; fix wording as appropriate to context.

Paul F spoke in favor of the proposal.

Doug B moved to accept proposed issue 1 and immediately close with acceptance of proposal, Seconded by Dave O.

No objection, new issue proposed 01 closed with proposed change.

Proposed-02 security threats and requirements

http://lists.oasis-open.org/archives/ws-rx/200605/msg00096.html

Chapter 5 of the WS-RM spec has a number of problems:

It lacks information specific to WS-RM. What needs to be protected and why?

It is overly general in parts; describing general security concepts that don't have anything specifically to do with WS-RM.

It recommends specific solutions (WS-SecureConversation) in preference to other solutions (e.g. HTTPS).

It lacks the detailed security requirements that are needed by implementers to build secure WS-RM implementations.

Proposal: Replace Chapter 5 with the referenced attached material.

Agreed to accept proposed 02 as new issue.

Proposed-03 security profiles

http://lists.oasis-open.org/archives/ws-rx/200605/msg00097.html

The WS-RX TC Charter requires that WS-RM support the “efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms”. The charter also states that “While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of this TC.” This proposal attempts to satisfy these two requirements by defining a set of non-normative profiles for composing WS-RM with commonly used web services security mechanisms. The purpose is to aid in the implementation and deployment of interoperable services and applications that utilize secure, reliable SOAP messaging systems.

Proposal: Add the referenced attached text as a new chapter to the WS-RM specification following Chapter 5 (Security Threats and Requirements)

Paul F asked for clarification of the issue, outside the proposal itself.

Doug B: I do not have a question about the issue, however the way the solution described as a full set of profiles. Why not define a small set of required profiles.

Gill: I would agree with that change to the proposal.

Tom R: Is the issue acceptable?

Marc G asked about the issue: is it not an incorrect title for the actual issue.

No objection to accept as a new issue.

Proposed-04 security profile agreement

http://lists.oasis-open.org/archives/ws-rx/200605/msg00098.html

In order for an RMD to perform the processing necessary to protect the Sequences for which it is responsible it must be aware of the particular security composition profile in effect for each Sequence. In order for the RMS to be certain that the RMD is actually protecting the Sequence in the desired manner the RMS must have a specific indication that the RMD understands and will conform to the particular security composition profile being used by the RMS for that Sequence. Both of these requirements mandate a mechanism by which the RMS and RMD can communicate the desired and effective security composition profile for a particular Sequence.

Proposal: Add the referenced attached material as a new chapter following Chapter 6 (Security Composition)

Doug B: I thought we ruled profile negotiation out of scope of the specification. This is beyond what we need to do in this TC.

Anish: we decided that on DAs not all policy matters.

Marc G: I do not see this as an issue on the current spec, it will only apply given a particular solution to another issue.

Doug B objected to this being added as a new issue for this TC.

Vote on acceptance of Proposed 04 as a new issue:

16 Yes

3 No

Proposed 04 accepted as a new issue.

Proposed-05 security composition policy

http://lists.oasis-open.org/archives/ws-rx/200605/msg00099.html

Although it may be possible for an RMS to determine at runtime what supported security composition profiles it may share with an RMD (through, for example, a series of <wsrm:CreateSequence> messages that are extended with the <wsrmsp:SecurityComposition> element) in general it is operationally more efficient if services can advertise which security composition profiles they support. This information can be used by development, configuration, and component assembly tools to decrease the amount of manual, out-of-band communication necessary to establish reliable, secure message exchanges between two endpoints.

Proposal: Add the attached material to WS-RM Policy specification as a new chapter (Security Composition Policy) after Chapter 2 (RM Policy Assertions)

Bob F asked that these issue are interdependent, the order should be carefully considered.

No objection to accept Proposed 05 as new issue.

4 Issue Discussion:

a> i089 suggest the restricted use of anonymous URI

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

TABLED MOTION:

Marc Goodner moved to accept the minimalist proposal for i089

http://lists.oasis-open.org/archives/ws-rx/200605/msg00023.html

Paul F stated that the tabled motion is still on the meeting,

Tom R: we would need a motion to un-table the motion.

Doug D: Dave O has given some new options on the email. I would like to have discussion of these new proposals, and postpone decision until the next meeting.

Anish: There are now 6 or 7 proposals on the table. I welcome Dave O to explain his new proposals. We need to decide how to progress on this. I recommend we use single transferable vote to move forward. It allows voting for preferences, when multiple options are on the table. I encourage the TC to consider using STV to resolve I089.

Paul F: I think this is a good idea in general.

Doug B: I want to ensure that discussions do not impact the tabled motion.

Tom R: new motions can be made, a tabled motion is just that. Taking it off the table is the same as any new motion.

Dave O: I gave a proposal on using ws transfer to get the delayed message. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00104.html

Dave O summarized his proposal. RMD must mint an epr which must be transferred before connection breaks. RMS does ws-transfer Get on this epr.

Issues from email:

1. This requires the RMD mint an EPR, which does not cover the scenario where the connection is lost before the EPR is returned. It could be possible to stream the response, so the first thing the RMS sees is the “SendTransferGetTo”

2. The messages are “embedded” inside the Body. This means that a receiver has to know about both “embedded” and non-embedded messages. Obviously this is confusing. Perhaps a different GET is needed, the “GET” with No GETResponse.

3. It may be that “GET” semantics are insufficient. In some sense, the RMD may want to “delete” the message after “GET”ting it. A new transactional operation of “GET+DELETE” may be the appropriate operation. It is possible that any type of GET Operation, beit a GetMessage or GetMessageForEPR will have this tx problem.

Dave O: I am not championing this proposal, the embedding issue is problematic, as are the other issues I outlined. It was presented to help discussion.

Paul F: this give dependence on the member submission, which is not a standard specification.

Dave O: I used the pre submission URIs, however we could use the member submission URIs. If some committee was formed, we might use the new URIs.

Paul F: I do not see 202 with a soap envelope as traditional.

Dave O: this has been brought up. The WS-addressing group has published a WG note which states you can send 202 for soap 1.1 with an envelope. The XML Protocol WG will do work to allow this scenario as an errata to soap 1.2.

Doug D: why not wrapper inside a soap envelope.

Dave O: that might be a better way to do it.

Umit: I am curious as to why you give this proposal, if you do not like it.

Dave O: This is an obvious potential solution to this problem. We have informally talked about it in the past. I volunteered to sketch this as a potential solution. However I find deficiencies in the solution.

Tom R: I do not like dependency on not standard spec. We would have to “abstract” the solution under our charter.

Martin: The charter does not mention ws-transfer, to add it now is inappropriate.

Dave O: if the use of WS transfer was ideally suited, we could talk further about dependency. However I do not even propose that we go with this solution.

Chris F: I move to straw poll to this out of consideration of resolutions for I 089 for the TC. Tom Rutt Seconded.

Paul F stated this motion is not binding, since any other motion could change it.

Doug B: It is useful for discussion.

No objection to accept straw poll to remove the WS-Transfer solution form consideration by TC.

Dave O: The deficiencies around WS-Transfer led to another idea that the RMD would mint EPR, that the RMS would send the get request to. The RMD mints an EPR for sendRMGetTo. The scenario is similar. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/doc00001.doc

Problems outlined in email:

Martin asked that we have more concrete proposals for voting.

Dave O stated this proposal is complete enough for discussion of its merits.

Paul F: an HTTP get using a wsdl 2 binding might do this. Do not need two relatesTo headers. My suggestion is that we do straw poll.

Dave O: the first comment is procedural; the second is to ask immediately for a straw poll. We need further discussion.

Paul F: I would like a TC straw poll on these proposals, as well as the Use cases for them.

Dave O: we are currently discussion my second proposal. I have not even started discussion of the third proposal.

Doug D: There might be an issue about when to remove a message from virtual queue, Is it not just when it is acked.

Dave O: I agree, when message is acked as received, it can be removed from queue, and would not be returned in a subsequent get.

Doug D: Could have Conflicts between reply to of get and the to of original response. That is why we made our proposal one way.

Chris F: Agree with Doug D and Paul’s first point.

Colleen: regarding straw polls and stv, it might be useful if next week we take a straw poll of tc to narrow discussion.

Tom R: has he done his third proposal yet.

Paul F: not het.

Doug D: I see a straw stv vote to get us down to many fewer proposals. Otherwise we could ask the proposers come down to a smaller set of proposals.

Anish: we could combine those. If the proposers cannot combine, we can straw poll what is left.

Dave O third proposal was summarized: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00135.html

Dave O: Doug D proposal has comparison of EPR, which uses ref parms for identity comparison. This is bringing back in the concept of ref properties. Could we do a comparison of eprs which do not bring back ref parms as part of identity. Adding a wsrx:id in the epr as extension is my new proposal. This is used, instead of ref parms, to compare when the address is anonymous.

Ran out of time.

Agreed to take proposals to mailing list.

b> i115 Gilbert Pilz "must understand" attribute for extensions to RM components

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

no time for discussion

c> i119 Piggybacking

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

no time for discussion

d> i113 Tightening up the state tables

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

no time for discussion

5 Any other business

None

ws-rx message

1 Roll Call

2 Agenda Approval

1 Approval of the past minutes;

2 AI Review

3 New issues since last conf-call

Proposed-01 (editorial) misplaced paragraph on action IRI's

Proposed-02 security threats and requirements

Proposed-03 security profiles

Proposed-04 security profile agreement

Proposed-05 security composition policy

4 Issue Discussion:

a> i089 suggest the restricted use of anonymous URI

b> i115 Gilbert Pilz "must understand" attribute for extensions to RM components

c> i119 Piggybacking

d> i113 Tightening up the state tables

5 Any other business