NEW issue: WS-C: Remove fault 4.5 ContextRefused

[Alastair Green <alastair.green@choreology.com>]

Issue name -- WS-C: Remove fault 4.5 ContextRefused

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.

Target document and draft:

Protocol:  Coord

Artifact:  spec / schema

Draft:

Coord spec working draft uploaded 2005-12-02
WS-Coordination schema contributed by input authors, not yet uploaded to 
Working Drafts folder

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/15738/WS-Coordination-2005-11-22.pdf

Section and PDF line number:

Section 4.5 "Context Refused", ll. 451-459


Issue type:

Design


Related issues:

Issue [] WS-C: Appropriate categories of fault


Issue Description:

ContextRefused fault relates to application protocol behaviour which 
should not be specified by WS-
Coordination.


Issue Details:

[This issue stems from Choreology Contribution issue TX-19.]

Faults in WS-C should be divided into only two categories: those which 
apply to the process of context
creation and registration (or which apply to the misuse of the 
conversational channel created by
registration), and those which are basic faults available to all 
coordination protocols.

ContextRefused is a fault that relates to an application protocol (an 
exchange between two applications that
are attempting to establish agreed use of a distributed coordination 
protocol). Such protocols should define
their own messages and faults.

The preamble of this fault (l1. 452-453) states:

"This fault is sent to a coordinator to indicate that the endpoint 
cannot accept a context which it was
passed:"

This description evokes the problem perfectly. An application 
communicates a context (by some means) to a
service. The service decides that it does not wish to register any 
participants. This decision may be
important, or unimportant, to the original propagator of the context.

Example A: in an auction, the context has been posted on a secure 
website, accessible by registered bidders.
The fact that registered bidder 43 is not interested in making an offer 
is uninteresting to the auction site.

Example B: a client knows that he cannot proceed with a three-component 
trade unless at least one service for
each component has registered. The client-service contract states that 
the service will either send a quote or
will send a not-interested message, to ensure rapid conclusion of the 
transaction.

Example C: same scenario as B, but the client simply tracks inbound 
quotes, and decides when he has sufficient
to proceed to make a choice and conclude the transaction.

Examples A and C do not require the semantic "not-interested" to be 
communicated: the semantic is not
generally needed, therefore. Example B requires the semantic to be 
communicated from service to client, but
not from the service to the Coordinator. We cannot assume that the 
Coordinator has any interest in presence or
absence of particular participants, or their number ("checking"). 
Indeed, products implementing protocols such
as WS-AT and WS-BA typically leave checking issues in the hands of the 
application.  

These kinds of communications are the property of specific application 
protocols (or perhaps, of some future
coordination protocols) but not of a general-purpose coordination framework.


Proposed Resolution:

Remove ll. 451-459 of the specification.
Remove l. 100 of the schema document.