[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] RE: Issue 115 - mU attribute
Hmm, now where have I read something like that before? ... On 25/05/06 15:32, Gilbert Pilz wrote: > From the proposal: > > > Mandatory RM extension elements are presumed to somehow modify the > semantics of other RM Components. Therefore, for every mandatory RM > extension recieved by an RM node, the receiving node MUST either > process the element or not process the element at all, and instead > generate a wsrm:MustUnderstandFault. Tagging RM extensions as > mandatory thus assures that such modifications will not be silently > (and, presumably, erroneously) ignored by the RM nodes that recieve > the messages containing extended RM Components. > > - gp > > ------------------------------------------------------------------------ > *From:* Marc Goodner [mailto:mgoodner@microsoft.com] > *Sent:* Thursday, May 25, 2006 3:28 PM > *To:* Gilbert Pilz; Christopher B Ferris; tom@coastin.com > *Cc:* wsrx > *Subject:* RE: Issue 115 - mU attribute > > They would be handled at the WS-RM layer, only whether or not they > were understood would be handled by the SOAP layer. The converse, > and what you are seem to be arguing for, is to push the mU > semantics up into the WS-RM layer. That seems more problematic to > me. How much of the message now gets processed before you find the > mU indicating you shouldn’t have processed any of it? > > > > Marc Goodner > > Technical Diplomat > > Microsoft Corporation > > Tel: (425) 703-1903 > > Blog: http://spaces.msn.com/mrgoodner/ > > *From:* Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] > *Sent:* Thursday, May 25, 2006 3:23 PM > *To:* Christopher B Ferris; tom@coastin.com > *Cc:* wsrx > *Subject:* RE: [ws-rx] Prelim minutes of 5/25 ws-rx conf call > > > > 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 <mailto: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 <mailto: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 <mailto:tom@coastin.com>; > trutt@us.fujitsu.com <mailto: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_items.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#i121 > > > b> i122 security profiles > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122 > > > c> i124 security composition policy > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124 > > > d> i123 security profile agreement > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123 > > > e> i115 "must understand" attribute for extensions to RM > components > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i115 > > > 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_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 > 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#i121 > > > > > 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#i122 > > > > > 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#i124 > > > no time to discuss > > 7.5 d> i123 security profile agreement > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123 > > > 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]