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