RE: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal 2

["Max Feingold" <Max.Feingold@microsoft.com>]

In order:

I wouldn't have a problem with extending the new "physical address" text
as you describe.  That said, it should probably be done as a separate
issue since the motivating problem is independent of i030.  We might
also want to start thinking how to properly value the cost of making
editorial changes that don't really affect interop or correctness.

I'm not worried about the inability to deliver protocol faults triggered
by uncorrelated terminal messages.  I can't think of an example where we
would need to send a protocol fault when we have no state against which
to correlate the message.  Since the semantic content of a notification
message is essentially its signal, there are three possible outcomes:

- The terminal message is somehow malformed (resulting in an
infrastructure fault).
- The terminal message is uncorrelated to state (resulting in it being
ignored).
- The terminal message is correlated to state (resulting, potentially,
in a protocol fault being sent to the registration EPR).

Obviously, if there are examples of cases where we'd need a 'From' on a
terminal message, we'd be foolish to prohibit them.  But I can't think
of any.

Lastly, I agree that the interop documentation is a good place for such
a statement.

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com] 
Sent: Tuesday, May 02, 2006 12:10 PM
To: Ian Robinson
Cc: ws-tx@lists.oasis-open.org
Subject: Re: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal
2

Ian,

I agree that we need to put this to bed. The various points are being 
addressed in your solution based on Proposal 2, and altho' I think it 
isn't quite as simple and consistent as it might have been had we been 
starting from a clean slate, we obviously need to move on. It's 
definitely workable.

In addition, it looks like I will not be able to attend the meeting this

Thursday because of domestic commitments, and I don't want to launch an 
alternative proposal which I won't be able to motivate -- that would 
just make it harder to get a final consensus.

Can I therefore just raise three points that I think the TC might want 
to consider in wrapping this up?

The point about recasting "physical address" as "non-anon, non-none" 
which you have also incorporated in your refinement could usefully be 
added to the description of the three EPR elements 
/CoordinationContext/RegistrationService,  
/Register/ParticipantProtocolService and 
/RegisterResponse/CoordinatorProtocolService, in WS-Coordination.

Also, do you see an issue with inability to deliver Invalid Protocol and

Invalid Parameters in response to the terminal notification messages? I 
think that in extremis these situations could arise with amnesia, so 
perhaps that needs to be taken into account?

In the interop documents, is it worth saying that failure to deliver 
WS-Addressing predefined faults is not a conformance failure? This is 
the only place where the "silence" decision might need to reflected
aloud.

Yours,

Alastair



Ian Robinson wrote:
>
>
> There has been a lot of discussion and some good comments suggesting
> refinement of "Proposal 2" for issue 30. Specifically:
>    Alastair's point that the WS-C spec defines the Coodination faults
as
>    "reply messages" but the WS-AT spec defines AT faults as
"notification
>    messages". The refined proposal clarifies that the specific
messages
>    exchange patterns apply to the protocol rather than to individual
>    messages and that protocol fault messages are constructed according
to
>    the rules of the protocol in which they are used.
>    Bob's objection to the use of phrases like ' "one way" pattern as
>    defined in WS-Addressing '. The proposal replaces this with ' The
>    protocols defined in WS-AtomicTransaction use a "one way" message
>    exchange pattern consisting of a sequence of notification messages
>    between a Coordinator and a Participant. '
>    Joe's observation of the inconsistency in specificity between
references
>    to WS-A from Coordination on the one hand and AT on the other.
These are
>    now uniformly precise. Also the proposed text now refer to the
abstract
>    message addressing properties rather than to soap header elements.
>
> Max and I have updated our proposal to address these concerns.
>
> (See attached file: Issue30_Proposal_2_WSBA.doc)(See attached file:
> Issue30_Proposal_2_WSAT_updated.doc)(See attached file:
> Issue30_Proposal_WSCOOR_updated.doc)
>
> In accrodance with the decision of the TC on the last telecon, the
text
> remains silent on the handling of non-TX fault messages.
>
> We have been discussing this issue for a month now, and we have other
work
> queued up. Could I suggest that any further refinements or
> counter-proposals be written in terms of concrete spec language that
the TC
> would be able to vote upon on the next telecon.
>
>
> Regards,
> Ian