[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Prelim minutes of 5/25 ws-rx conf call
When you register the WS-RM headers with the SOAP processor you weren't saying anything about the contents of those headers, only that the SOAP processor should accept them. By surfacing the mU semantics of WS-RM extensions as SOAP headers you are linking the implementation details of a particular SOAP extension to your general SOAP processor. Also, I can't see how extending something like CloseSequence is "extending SOAP" in any meaningful sense. An extended CloseSequence and a non-extended CloseSequence both live inside soap:Body. Why should the SOAP processor care whether a child element of soap:Body has been extended (how would it even know this was an extension w/out access to the schema for that sub-element?) in some "semantically significant" way? - gp > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Thursday, May 25, 2006 3:29 PM > To: Gilbert Pilz > Cc: Christopher B Ferris; tom@coastin.com; wsrx > Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call > > Gil > > RM already has to "register" headers with the SOAP processor. > In fact every SOAP header author does. Thats just what it > takes to write an extension to SOAP. Now you're suggesting > that we create a new mechanism with exactly the same model - > in RM. Hmmm. Its a nice model, but I don't like it enough to > want it twice. > > Paul > > Gilbert Pilz wrote: > > This means that you need to register every WS-RM must-understand > > extension with the general SOAP processor. You're coupling > your SOAP > > configuration (via the Qname of the header that refers to the > > extension) to the internal details of the messages (e.g. a > particular > > extension to CloseSequence) that will be carried within SOAP. > > Extensions to WS-RM-defined messages should be handled at the WS-RM > > layer and not surfaced to the general SOAP processor. > > - gp > > > > > -------------------------------------------------------------- > ---------- > > *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com] > > *Sent:* Thursday, May 25, 2006 3:04 PM > > *To:* tom@coastin.com > > *Cc:* wsrx > > *Subject:* Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call > > > > > > From below: > > Doug B: (from chat) concretely: use a soap:mustUnderstand header > > which is handled using normal SOAP processing model, the given > > element's qname would be associated with semantics > defined in the > > relevant WS-RM extension, the SOAP processor doesn't > have to know > > the details of this extension just that a handler knows > what to do > > > > +1 > > > > I have tried to make this point repeatedly in the past. > The whole > > point of the SOAP header > > with mU=true is just to test that the extension is understood. > > Nothing more, nothing less. It need not > > reference an explicit instance of the extension. It is merely > > there to say: if the processor doesn't > > know what to do with this extension, DO NOT process > this message. > > > > Cheers, > > > > Christopher Ferris > > STSM, Software Group Standards Strategy > > email: chrisfer@us.ibm.com > > blog: > http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 > > phone: +1 508 377 9295 > > > > Tom Rutt <tom@coastin.com> wrote on 05/25/2006 05:40:54 PM: > > > > > Prelim minutes 5/25 attached. > > > > > > Please post any corrections to entire list before > monday morning. > > > > > > Tom Rutt > > > > > > -- > > > ---------------------------------------------------- > > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > > Prelim Minutes of OASIS WS-RX Teleconference > > > May 25, 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 32 of 46 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 May 18, 2006 meeting minutes > > > http://www.oasis-open.org/committees/download. > > > php/18295/MinutesWSRX-051806.html > > > > > > 4) AI Review > > > > > > > > http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item > > s.php > > > > > > > > 5) New issues since last conf-call > > > Watch for Marc's email > > > > > > 6) Review of changes due to i093 > > > > http://lists.oasis-open.org/archives/ws-rx/200605/msg00117.html > > > > http://lists.oasis-open.org/archives/ws-rx/200605/msg00205.html > > > > > > 7) Issue Discussion: > > > a> i121 security threats and requirements > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 21 > > > > > b> i122 security profiles > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 22 > > > > > c> i124 security composition policy > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 24 > > > > > d> i123 security profile agreement > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 23 > > > > > e> i115 "must understand" attribute for extensions to > RM components > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 15 > > > > > 8) Any other business > > > > > > Marc G asked about issue 119. Also 125 seems ready. > > > > > > Sanjay: Doug D is not on the call, but since 125 was > not included I > > > would put it at end. > > > > > > Marc: could 115 be put before the security issues? > > > > > > No objections to place 115 before security issues. > > > > > > 3 Approval of the 5/18 minutes; > > > http://www.oasis-open.org/apps/org/workgroup/ws-rx/download. > > > php/18243/MinutesWSRX-051106.html > > > > > > Tom moved, Marc G seconded to approve 5/18 minutes. > > > > > > § No objection minutes for 5/18 meeting approved. > > > > > > 4 AI Review > > > > > > > > http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item > > s.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 > > reviewcomments > > > Owner: Marc Goodner > > > Status: Still Open > > > Assigned: 2006-05-22 > > > Due: --- > > > > > > > > > > > ---------------------------------------------------------------------- > > ---------- > > > > > > > > #0103: Paul F will address Marc G concerns and > interop concerns in a > > > next version of schedule, including the member ballot > > > Owner: Paul Fremantle > > > Status: Still Open > > > Assigned: 2006-05-22 > > > Due: --- > > > 5 New issues since last conf-call > > > none > > > > > > 6 Review of changes due to i093 > > > > http://lists.oasis-open.org/archives/ws-rx/200605/msg00117.html > > > > http://lists.oasis-open.org/archives/ws-rx/200605/msg00205.html > > > > > > Sanjay: there was considerable discussion on the list > about this. > > > > > > > http://lists.oasis-open.org/archives/ws-rx/200605/msg00263.html > > > > > > Doug B: There seems to be agreement on a small number > of changes to > > > satisfy Marc G. I propose we accept Gils document > with the small > > > number of changes Marc G and I agreed on, and include > this as our > > > base document. > > > > > > Anish: I have a preference for an alternative > proposal that I sent. > > > It might be better to not use the MUST/MAY OPTIONAL keywords. > > > http://www.oasis-open.org/apps/org/workgroup/ws- > > > rx/email/archives/200605/msg00266.html > > > I have an alternate proposal: > > > > > > Replace the offending parts with assertions that do > not contain > > any 2119 > > > key words -- > > > The cardinality of this [element|attribute] is [zero > or more|one or > > > more|exactly one]. > > > > > > -Anish > > > > > > Gil: I agree with Anish, we can use xml schema language for > > > cardinalities, avoiding the rfc 2119 keywords. > > > > > > Marc G: this is inconsistent with the rest of the > document. It would > > > suggest multiple changes elsewhere. I prefer the proposal from > > > myself and Doug. The text that Doug and I propose continues to > > > describe the elements themselves, without cardinality. > > > > > > Anish: you can just get rid of existing improper 2119 > terms, and > > > replace with simple cardinality statements in English. > > > > > > Doug B moved to accept proposal from Marc and himself, Marc > > Seconded. > > > > > > Anish: speaks against it, since it states conformance > > constraints twice. > > > > > > Doug B: in a particular change around wsrm:acksTo, > the rfc 2119 > > > language is about actions rm source must do and > constraints on the > > > type. It is also about how the rm destination must > respond. They > > > are not about cardinality. > > > > > > Vote: > > > 13 Yes > > > 6 No > > > > > > § Motion passed to accept proposal from Marc and Doub > F to close > > Issue 093. > > > > > > Discussion on availability of Next working draft. > > > > > > Gil: if we do not include issues we resolve today, we can be > > ready soon. > > > > > > Sanjay: It should be ok to not include issues resolve > on today's > > call. > > > > > > Marc G: the next wd will include all pending issues. > > > > > > Bob F: also must include issue 93. > > > > > > Gil: we should have one available by cob Tuesday. > > > > > > Anish: do we have exact text for Issue 96. > > > > > > Bob: issue 113 is based on an interim spec from Gil. > > > > > > Tom: those state tables came from an email from the Face to > > Face, from Matt. > > > > > > Bob F: Jacques and I are eagerly awaiting a new draft > which resolves > > > closed issues, to insert clause numbers in the state table. > > > 7 Issue Discussion: > > > > > > 7.1 I 115 > > > > > > Gil: an updated proposal from may 3 is at: > http://lists.oasis-open. > > > org/archives/ws-rx/200605/msg00025.html > > > > > > Gil: if other side does not understand the extension, > the sender > > > must know that. We need some inditcation. This > proposal defines a > > > wsrm specific attribute, to be used at the top level > (only) of an > > > extension element, and we define a > wsrm:mustunderstand Fault to use > > > if the receiver does not understand that extension. I added a > > > statement that the attribute cannot be used below the > top element. > > > > > > Paul C: I am opposed to this. Soap already has a must > understand > > > model, and having wsrm add this is not the way to go. I would > > > rather add a soap header which states there is an > extension element > > > being used, with a soap:mustUnderstand attribute. > > > > > > Anish: I disagree that this is not independent of the soap > > > processing model. This wsrm:mustUnderstand attribute > is checked > > > after the soap model does what it does. > > > > > > Gil: I have a problem with a new empty soap header, > with a reference > > > to an extension used in another place. I think putting wsrm > > > semantics into the soap processing layer is not valid. It is > > > semantically wrong to use soap must understand, since there is > > > nothing wrong at the soap leve. The processing is > better done at > > > the WSRM level. > > > > > > Paul F: you could use a separate entity in a soap > header. There > > > could be work around, but the general soap model > allows the complex > > > case. Since I have not yet seen extensions proposed > yet, I think > > > this is something for version 2. I prefer we defer this issue > > > resolution to a future version of the spec. > > > > > > Sanjay: I agree this should be deferred. > > > > > > Doug B: (from chat) concretely: use a > soap:mustUnderstand header > > > which is handled using normal SOAP processing model, the given > > > element's qname would be associated with semantics > defined in the > > > relevant WS-RM extension, the SOAP processor doesn't > have to know > > > the details of this extension just that a handler > knows what to do > > > > > > Marc G: I agree with Doug B proposal on chat. > > > > > > Gil: with some of our security extensions, it would > be better to not > > > close sequence if the receiver does not understand a > requirement > > > needed by the requester for that sequence. I do not > want to tightly > > > couple a general soap processing engine with the wsrm > > implementation. > > > > > > Sanjay: we should defer this issue since we do not yet have > > extensions. > > > > > > Umit: I would prefer this issue to be deferred to a later > > version ofthe spec. > > > > > > Paul F: Gil stated the security composition profile > might need such > > > a mechanism. Is this intended to be outside the spec. > > > > > > Gil: I want that to be within this spec. > > > > > > Paul F: then I think even more we should defer this. > Why build in > > > features when we do not have a use case in the spec that needs > > them. > > > > > > Gil: It is unfair to require extensions to already > exist before we > > > have such a mechanism. > > > > > > Paul C: I would like to have it be clarified if Gil's > proposal for > > > issue 123 requires this proposed solution. > > > > > > Sanjay: I would like to wait to answer this question > until after we > > > discuss issue 123. > > > > > > Sanjay: I propose we defer resolution of 115 until > after we discuss > > > the security related issues. > > > > > > > > > 7.2 i121 security threats and requirements > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 21 > > > > > > > > Gil: we need to realize that the sequence is a shared > resource which > > > is being protected. I need to make sure the sequence ack comes > > > from the RMD which "owns" that sequence. This needs to be > > explained. > > > > > > Gil: the existing text also has unnecessary details. > I just got > > > around to rewriting chaper 5. at: http://lists.oasis-open. > > > org/archives/ws-rx/200605/msg00096.html > > > > > > Gill review the threats which must be dealt with. > > > > > > Gil: sequence hijacking is not the same as a session > identifier. > > > > > > Gil: the text on message correlation threats (in 5.4) might be > > > better to remove altogether. > > > > > > Paul F: I think this is basically a good rewrite, > although I am not > > > a security expert. It uses terminology "integrity > protected", and > > > it is not clear what this means. Could that be added > to a glossary? > > > > > > Gil: I agree that should be added to a glossary. > > > > > > Paul F: I think we could accept this proposal, with > removal of 5.4. > > > > > > Paul C: The 8 requirements in the proposal in 5.5, do > not correlate > > > back to the text on the 4 or 5 threats. If I only > want to worry > > > about sequence hijacking, I do not know which of the items in > > 5.5 apply. > > > > > > Gil: That is a good point, not everyone is worried about every > > > threat. The relationship between the threats an security > > > requirements needs to be clarified. I would like to > take an action > > > item to come up with a new version which does that. > > > > > > Ø Action: Gill will clarify his proposal for i121 to > clarify the > > > relationship between requirements and the threats. > > > Doug D: I am not ready to make a final decision until > we see the > > > result of this action item. I would like perhaps a > straw poll on > > > whether Gil should bother to carry out this action > item to come up > > > with a new proposal addressing the concerns raised on > this call. > > > > > > Sanjay: straw poll Yes means continue to work, no > means to not have > > > Gill Bother to update the proposal. > > > > > > No opposition to having Gil work on action item. > > > > > > Paul C: he has threats, and requirements (solutions). I would > > > prefer to have three sections, threats, potential > countermeasures, > > > and which countermeasure is used for each threat. The > WSI has a > > > document which demonstrates this. > > > > > > Gil : I agree with Paul C. > > > > > > Sanjay: we should continue post questions to the mail list. > > > > > > > > > Gil: it might not be ready by next week call. The earlier the > > > better for any email to the list. Two weeks is > probable too long a > > > time to wait. It would be better to be done before the next > > meeting. > > > 7.3 b> i122 security profiles > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 22 > > > > > > > > Gil reviewed his proposal posted as http://lists.oasis-open. > > > org/archives/ws-rx/200605/msg00097.html > > > > > > Gil: a profile does several things: > > > How rms and rmd authenticate each other when sequence > is created. > > > For every message in sequence (traffic or control) > how they know who > > > sent the message or inserted the header. > > > > > > Gil: I see three sets of profiles > > > Tls and other authendication > > > Tls and tls authentication > > > Ws secure conversation. > > > > > > Gil: there is different concerns about RMS > authentication and AS > > > authentication. I would like other peoples opinion on this > > proposal. > > > > > > Marc concern on web chat: I don't understand the TLS > uris, aren't > > > you already connected over TLS by the time you are > signaling you > > areusing it? > > > > > > Marc: why does the RMS need to know whether the > security applies to > > > its code or the application's code. > > > > > > Gil: if RMD is a separate node, it must ensure the > identity of AS > > > flows to the AD. It is necessary for composability. > > > > > > Paul C: This proposal for 122 is used in solution for 123. > > > > > > Gil: the ability of two ends to know how to protect WSRM is > > > important. This can be done out of band. 123 is about > the run time > > > agreement for those profiles. 122 is just about > coming up with a > > > way for two people to agree on that they are using for wsrm. > > > > > > Paul C: these profiles are collections of polices > which and be used > > > out of band. Why not use ws-security policy. > > > > > > Ran out of time. > > > > > > Sanjay: continue to discuss security concerns on the list. > > > 7.4 c> i124 security composition policy > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 24 > > > > > no time to discuss > > > 7.5 d> i123 security profile agreement > > > > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i1 > > 23 > > > > > no time to discuss > > > > > > 8 Any other business > > > none > > > > > > ______________________________________________________________ > _________ > > > 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. > > > > -- > > Paul Fremantle > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > http://feeds.feedburner.com/bloglines/pzf > paul@wso2.com > > "Oxygenating the Web Service Platform", www.wso2.com > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]