[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Revised proposal for 122, 123, 124
Comments inlined below. -Anish -- Marc Goodner wrote: > inline > > > > *From:* Patil, Sanjay [mailto:sanjay.patil@sap.com] > *Sent:* Tuesday, June 27, 2006 2:49 PM > *To:* Marc Goodner; ws-rx@lists.oasis-open.org > *Subject:* RE: [ws-rx] Revised proposal for 122, 123, 124 > > > > Hi Marc, > > > > Couple of clarification questions. Here is a cut-paste of the concerned > text from your proposal: > > ---------------------------------------------------------------------- > > When a RM Source transmits a CreateSequence that has been extended to > include a wsse:SecurityTokenReference it should ensure that the RM > Destination both understands and will conform with the requirements > listed above. In order to achieve this, the RM Source SHOULD include the > UsesSequenceSTR element as a SOAP header block within the CreateSequence > message. When this element includes a soap:mustUnderstand attribute with > a value of 'true', the RM Source can be assured that a RM Destination > that responds with a CreateSequenceResponse understands and conforms > with the requirements listed above. > > ---------------------------------------------------------------------- > > Questions: > > 1> It seems that the RMS may choose to not include the UsesSequenceSTR > SOAP header block. What is the expected RMD behavior in this case? Can > the RMS infer anything upon receiving the CSR. If nothing, then how > interoperable would be the use of CS/STR without the UsesSequencesSTR > header block? > > MG: This is exactly the concern that caused the introduction of the > header block (and the assertion). Our proposal is not to use the CS/STR > without the header block. I’m afraid that the extensibility point in the > CS makes it difficult to lock this down completely. If there is a > demonstrated interop problem of people using the CS/STR without the > header block I would suggest the WS-I RSP could lock this down. > In that case why not use a MUST? I.e: "... the RM Source *MUST* include the UsesSequenceSTR element as a SOAP header block *along with the soap:mustUnderstand attribute with a value of 'true'* within the CreateSequence message." OR something like that. > > > 2> It seems that the RMS may choose to not include the > soap:mustUnderstand attribute (with a value of "true") on the > UsesSequenceSTR SOAP header block. What are the RMS and RMD expectations > in this case? > > MG: Actually this is something we didn’t think about, that is ambiguous. > I would accept that the mU value of this header should always be true. I > cold either accept that as an amendment to the proposal or I could get a > revision with this change back to the list. Whichever is easier for > people to digest. > See above. > > > -- Sanjay > > > > ------------------------------------------------------------------------ > > *From:* Marc Goodner [mailto:mgoodner@microsoft.com] > *Sent:* Wednesday, Jun 21, 2006 16:31 PM > *To:* ws-rx@lists.oasis-open.org > *Subject:* [ws-rx] Revised proposal for 122, 123, 124 > > All, > > > > This proposal has redline from our last that include changes to: > > · Indicate that the intention of the STR in the CS is to > explicitly identify the token to be used to secure the RM sequence > (as there may be more than one token in the message) > > · Call out that the normal WSS faulting behavior is not effected > > · Update some of the wording per i135 > > > > Regards, > > Marc g >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]