[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
But you are effectively *making* it care be requiring the higher-layer to register a unique SOAP header for every mU extension. - gp > -----Original Message----- > From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] > Sent: Thursday, May 25, 2006 4:02 PM > To: Gilbert Pilz > Cc: Paul Fremantle; Christopher B Ferris; tom@coastin.com; wsrx > Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call > > The SOAP processor doesn't have to care. > > The point is it doesn't have to know any of that nesting / > detailed information, Gil. The SOAP processor need only care > that the named mU header is understood. "Understood" only > has meaning to the handler and could easily mean "I can grok > (random) extension foo in element bar when twiddle is false". > Doesn't seem any different from registering the handler for > wsrm:CloseSequence in the first place from a SOAP processor > perspective. > > thanx, > doug > > On 25/05/06 15:55, Gilbert Pilz wrote: > > 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_ite > >> m > >> > >>> 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#i > >> 1 > >> > >>> 21 > >>> > >>> > b> i122 security profiles > >>> > > >>> > >>> > >>> > >> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i > >> 1 > >> > >>> 22 > >>> > >>> > c> i124 security composition policy > >>> > > >>> > >>> > >>> > >> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i > >> 1 > >> > >>> 24 > >>> > >>> > d> i123 security profile agreement > >>> > > >>> > >>> > >>> > >> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i > >> 1 > >> > >>> 23 > >>> > >>> > e> i115 "must understand" attribute for extensions to > >>> > >> RM components > >> > >>> > > >>> > >>> > >>> > >> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i > >> 1 > >> > >>> 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_ite > >> m > >> > >>> 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#i > >> 1 > >> > >>> 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#i > >> 1 > >> > >>> 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#i > >> 1 > >> > >>> 24 > >>> > >>> > no time to discuss > >>> > 7.5 d> i123 security profile agreement > >>> > > >>> > >>> > >>> > >> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i > >> 1 > >> > >>> 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]