OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: Issue 57: Final protocol message should always be an RSTRC


57...

-----Original Message-----
From: Jan Alexander 
Sent: Saturday, April 01, 2006 10:37 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: New Issue: Final protocol message should always be an RSTRC

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
THE ISSUE IS ASSIGNED A NUMBER.  

The issues coordinators will notify the list when that has occurred.

Protocol:  ws-trust

http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/17403/ws
-trust-1.3-spec-ed-01-r04.pdf
 
Artifact:  spec

Type: design

Title: Final protocol message should always be an RSTRC

Description:

Make the final protocol leg always be an RSTRC (rather than either an
RSTR or an RSTRC as it is currently). So the protocol becomes; RST,
RSTR*, RSTRC. 
Currently a STS can use either RSTR or RSTRC to return the issued
token(s) to the requestor. Even in the simplest case when a requestor
ask for a token and STS immediately responds with a issued token in the
reply, the requestor must be prepared to process both RSTR and RSTRC
style responses because STS can use RSTRC even for a single token.
This change makes the protocol easier to reason about and easier to
implement because a requestor knows that the issued token will be always
returned using RSTRC style response.

Related issues:
This issue is related to the other proposed issue that the final
protocol message should use a distinct WS-Addressing action.

Proposed Resolution:

Change the specification so that the issued token(s) can be returned
using RSTRC only. If intermediary messages are necessary either RSTR or
RSTRC can be used for those intermediary messages.

Section 3.2 needs to be reworded to explain this change.

Section 4.3 can be removed.

All other section need to be updated to use RSTRC instead of RSTR when
talking about final response messages.




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