[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: firstname.lastname@example.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.