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