[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
Gil The arguments you are making need to be put in context. Even if you were right that its hard to handle SOAP mU processing (which I don't buy), I still believe that the extensibility of the RM protocol messages is an advanced feature with no clearcut well-defined use cases at this point in time. I don't think you are arguing that it is impossible to support these use-cases, only that it is hard. I think that it is perfectly acceptable that in a first release of a standard we leave these corner-case situations hard to implement. So I also would like to concur - I believe this should be closed with no action. Paul Christopher B Ferris wrote: > > No, the SOAP processor doesn't *care*, it just does what every SOAP > processor is REQUIRED > to do, mU checking of headers targetted to that node. How the > configuration of the handlers is > managed is irrelevant. > > Paul had it exactly right. You have to do this for the RM elements > anyway (and for every other > SOAP header that might possibly be decorated with a mU=true). > > Seriously Gil, with all due respect, you are making a mountain out of > a molehill and proposing > something that is more complex than is needed. > > I concur with Marc; this should be closed with no action. > > 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 > > "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 05/25/2006 07:06:42 PM: > > > 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 > > > >> > > > >> > > > >> > > > -- 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]