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: Re: [ws-rx] compromise proposal for i122-4


Paul Fremantle wrote:

>Tom
>
><member>
>As a member I'm afraid I like this proposal less than either of the
>individual proposals. I know this looks a little like what we did around
>polling, but in fact I think there are key differences.
>Firstly, the dual approach in polling (sequenceid or address) allows for
>some very different models that meet different needs. The sequenceID
>model allows a client to carry on without modifying the WS-A headers and
>work very composably with existing code. The Address based model allows
>n-m on sequences and endpoints which supports more complex use cases.
>The result was that although the compromise proposal was more complex,
>it also satisfied a wider set of use-cases.
>
>I believe this proposal satisfies no more use cases, while still
>requiring both sides to support code they don't want to. In other words,
>the polling compromise was a compromise through making each side happy,
>this looks like a compromise through making each side unhappy!
>  
>
I am not going to push this compromise, however I would like to explain 
where I was coming from:

Many of the complaints last week seemed to be focused on the sending 
side. Perhaps I did not understand that the same problems
exist on the receiving side.

There was a concern against the Oracle/SAP proposal that some wss 
implementations would not let the rms querry its wss implementation
for a token with a given usage attribute value.  If the problems 
discussed last week pertain to the receiving rmd and receiving wss 
implementations as
well as the seding implementations, then I agree that my compromise does 
not help.

Tom

></member>
>
><chair>
>If you'd like this voted on can I ask you to produce a concrete
>(change-bar style) proposal that the TC can review before this week's
>call. I'd also like to see the IBM/MSFT and Oracle/SAP proposals amended
>to include Gil's amendment. As I stated if we don't resolve this on the
>call then I expect to start a ballot straight away, and I'd like the TC
>to have text they can evaluate and the monkeys^D^D^D^D^D^D editor's have
>something clear they can work to once the ballot is closed.
></chair>
>
>Paul
>
>
>Tom Rutt wrote:
>  
>
>>Paul Fremantle wrote:
>>
>>    
>>
>>>I'm trying to understand the latest "concrete" proposals for the
>>>security issues.
>>>
>>>Based on Doug Buntings note last week, and the discussions since then.
>>>
>>>1) latest from Microsoft and IBM
>>><http://lists.oasis-open.org/ws-rx/200607/msg00036.html> modified by Gil
>>>-  http://lists.oasis-open.org/ws-rx/200607/msg00070.html, and agreed to
>>>at least by Marc.
>>>
>>>2) latest from Oracle and SAP
>>>http://lists.oasis-open.org/ws-rx/200607/msg00075.html also modified by
>>>Gil's http://lists.oasis-open.org/ws-rx/200607/msg00070.html
>>>
>>>3) Close no action from Doug Bunting.
>>>http://lists.oasis-open.org/ws-rx/200607/msg00088.html
>>>
>>>Can the owners of these proposals (and any others I missed) please
>>>confirm these are the latest that you support.
>>>
>>>Thanks
>>>Paul
>>>
>>> 
>>>
>>>      
>>>
>>I have a new compromise proposal to discuss.
>>
>>Let the sending side pick either Oracle or Microsoft way to send STR. 
>>(some implementations seem to be able to support one way better over
>>the other).
>>
>>The receiving side would have to accept create sequence messages with
>>the str in either place (i.e., in security header with usage
>>attribute, or directly in
>>createSequence element in body).
>>The receiving implementation would look in both places if the
>>wsrm:UsesSequenceSTR element is present as a soap header.
>>
>>Tom Rutt
>>
>>    
>>
>
>  
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




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