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

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

Hi Max, comments below:

Max Feingold wrote:

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 agree. I don't have a problem with no action. If you use anon or none your impl will break. Silence on this is cognate to silence on WS-A faults.

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.
  

I agree. I can think of an artificial case where you could deliberately create an e.g. invalid parameters condition (and it's highly artificial), and even then it can be silently swallowed as irrelevant, if the relationship has closed. I wanted to sanity check that conclusion by stimulating someone else to think about it. Thanks for doing so.

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

Here is some proposed text:

'An implementation shall not fail any interoperation test defined in this document solely because it fails to generate and send one of the faults defined in the WS-Addressing SOAP Binding specification, Section 6.4, "Predefined Faults".'

Alastair

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