i050: Characterization of underlying issues and of proposals seen so far

As Jonathan's proposal[1] is the 11th proposal to try to close i050,
and we seem to be making little progress on this issue, I thought it
would be useful to explore all the underlying issues under i050, and
provide some scenarios concretely showing the difference between all
the proposals.

-=- Characterization of the issue -=-

I believe that there are 4 axes detailed below:
- capabilities: c*
- optimizations: o*
- alignments between replies and faults: a*
- levels at which those are expressed: l*

Here is what people have expressed wanting to do:

  c1. be able to specify a reply address
  c2. be able not to specify a reply address
  c3. reuse the rules from the binding and MEP in use

and the optimizations they have been wanting to have:

  o1. always have a reply address specified for a request-response interaction
  o2. not be forced to specify anonymous all the time

o1 is classified in optimizations because of Jonathan's email[5]. It
is worth noting that o1 and o2 seem mutually exclusive: if you want to
use ReplyTo to indicate that a reply is expected, then a defaulting
mechanism is not possible.

Reply address above can be interpreted above as normal reply (ReplyTo)
or faults (FaultTo). So another thing which was requested, and which
originated the issue, was a1, which then prompted a2 from certain
people:

  a1. align what happens for faults and replies
  a2. have FaultTo default to ReplyTo if present
  a3. have replies and fauls not aligned because they are really
      different

Where the discussion gets fuzzy is that those 5 things can be achieved
in different ways in many different places:

  l1. at the abstract level, in the MAPs
  l2. with the XML serialization of the MAPs
  l3. in the SOAP binding of Addressing
  l4. in the rules of how to formulate a reply message
  l5. in the WSDL binding when talking about MEPs

The status quo is as follows:
- c1 + c2 + c3 (by specifying the anonymous URI) + o1 for replies
- c1 + c3 (by specifying the anonymous URI) for faults
- achieved at l1
- a3

Jonathan's proposal adds a2 at the l4 level, which basically removes
a3 and adds o1 for faults.

Tom's proposal 2[2] considered was to add a2 at the l2 level.

I believe that the right way to look at the issue is what it allows
and enables people to do, and how. As we have this magic anonymous URI
whose semantics to basically "there are out of band agreements that
explain what to do if you want to send me a message", I believe that
all proposals allow people to do everything (c*): in some proposal,
you have to explicitly use it, while in others it's the default. Then
there are various optimizations.

To me, it really is the same as choosing when writing some code how to
repeat 4 times the same code. Use a loop or not, use a counter or not,
if so initialize it, test it, increment it where you want, in any
case, you'll manage to do your 4 iterations. Of course, some solutions
will look prettier than others, and it's essentially the debate here.

I'll put my original proposal 1[3], which is essentially a summarized
version of Dave's detailed proposal presented last night[4], on the
table as I still believe that this is the simplest:
- c1 + C2 + c3 (by default), for both replies and faults
- a1
- o2
- minimal at l1, rules of reply expressed at l4 (which makes sense)

-=- Concrete comparison -=-

In order to illustrate that all scenarios can be achieved, here are
some examples in case of request-response; see how the different
proposals deal with them at the abstract MAP level:

- reply by normal channel, faults by normal channel

  Status quo:
    wsa:ReplyTo		anonymous
    wsa:FaultTo		not needed

  Jonathan's:
    wsa:ReplyTo		anonymous
    wsa:FaultTo		not needed

  Hugo/Dave's:
    wsa:ReplyTo		not needed
    wsa:FaultTo		not needed

- reply to URI1, faults by normal channel

  Status quo:
    wsa:ReplyTo		URI1
    wsa:FaultTo		not needed

  Jonathan's:
    wsa:ReplyTo		URI1
    wsa:FaultTo		anonymous

  Hugo/Dave's:
    wsa:ReplyTo		URI1
    wsa:FaultTo		not needed

- reply to normal channel, faults to URI1

  Status quo:
    wsa:ReplyTo		anonymous
    wsa:FaultTo		URI1

  Jonathan's:
    wsa:ReplyTo		anonymous
    wsa:FaultTo		URI1

  Hugo/Dave's:
    wsa:ReplyTo		not needed
    wsa:FaultTo		URI1

- reply to URI1, faults to URI1:

  Status quo:
    wsa:ReplyTo		URI1
    wsa:FaultTo		URI1

  Jonathan's:
    wsa:ReplyTo		URI1
    wsa:FaultTo		not needed

  Hugo/Dave's:
    wsa:ReplyTo		URI1
    wsa:FaultTo		URI1

The status quo and Jonathan's proposal provide o1 (which has had some
push back[6]), and Hugo/Dave's provides o2.

-=- Conclusion -=-

In any case, once again, all scenarios were possible.

I for one like the alignment between faults and reply (a1), and think
that the reply rules (l4) is the right place to talk about constraints
on ReplyTo and FaultTo. Yesterday, Dave's proposal was straw-polled on
as something which would move text to the WSDL binding, but I don't
think it's necessary the case.

Hopefully, this will help us to reach a point of agreement by next
Monday.

My own preference is:
1. Hugo/Dave's proposal[3]
2. Status quo
3. Jonathan's proposal[1]

However, I don't think we should spend much more time on this issue,
as it is not changing the functionality of our spec.

Regards,

Hugo

  1. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0136.html
  2. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0132.html
  3. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0101.html
  4. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.html
  5. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0026.html
  6. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0027.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/