[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 5/11 WSRX Teleconf
Prelim minutes are attached. Please provide corrections to the entire list before next monday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Minutes of OASIS WS-RX Teleconference
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 CallFrom Kavi: xx of 43 voting members, meeting quorate 2 Agenda Approval1) 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 Reviewhttp://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-callhttp://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: 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 “SendRMGetTo” 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. 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 businessNone _______________________________________________________________________ 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]