ws-rx message

Subject: Re: more on i115 [was Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call]

From: Christopher B Ferris <chrisfer@us.ibm.com>
To: wsrx <ws-rx@lists.oasis-open.org>
Date: Fri, 26 May 2006 06:14:42 -0500

+1

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

Doug.Bunting@Sun.COM wrote on 05/25/2006 07:31:12 PM: > Gil, > > Please read what I'm saying. "Care" from the SOAP processor's > perspective has nothing to do with the extension's details. It's the > same level of caring as any other SOAP header. > > The cardinality you're proposing (one header and registration per > extension element or attribute per extension point it can be inserted) > is a derivative case as well: A 100 page WS-RM extension specification > could be written with 200 MUST, SHOULD, MAY requirements, 300 new > elements and attributes, and 400 ways to attach them to various WS-RM > extension points. One mU header for all seems fine to me. > > thanx, > doug > > On 25/05/06 16:06, Gilbert Pilz wrote: > > 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 > >>>> > >>>> > >>>> > >>>>

References:
- more on i115 [was Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call]
  - From: Doug Bunting <Doug.Bunting@Sun.COM>