OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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
>>>>
>>>>
>>>>     
>>>>         


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]