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