Re: MAPs and SOAP

My conclusion, from trying to define DaveO's request/reply/alternate in 
terms of the current framework [1], is that the current extensibility 
does /not/ support such a scenario in any meaningful way.  I have 
publicly commented on this [2].  Further, despite its broad title, i042 
clearly deals with EPR extensibility and not MAP extensibility.  The 
original issue i042 has been addressed, and adding an AI to a closed 
issue seems confusing at best.

At this point, I would strongly prefer to see the original issue I 
raised [3] formally noted on the issues list in its own right.  There 
have been three proposed resolutions so far, one in the original email, 
one proposed by Marc Hadley [4] and later clarified [5], and a second 
proposal of mine [6]. As far as I'm concerned my second proposal (use 
qnames and keep the wsa:ReplyTo and wsa:FaultTo headers as they are) 
supersedes the original (use IRIs and optionally special-case reply and 
fault to appear as they currently are).  The original proposal may be 
withdrawn unless anyone really wants to keep it around.

I would also welcome any concrete proposal showing how to handle 
interactions outside the request/reply family within the current 
framework, that is, using the current MAPs and SOAP Addressing 1.0 module.

Under the status quo, the only editorial changes I could recommend would 
be on the order of changing the second paragraph of section 3 to begin

    Message addressing properties provide references for the endpoints
    involved in request/reply interactions and other interactions for
    which a reply endpoint and a fault endpoint suffice.  Endpoints
    required for more complex interactions must be handled outside this
    framework by defining separate abstract properties and where
    appropriate mapping them to SOAP properties in some module other
    than that defined in the WS-Addressing SOAP binding.

striking "and any other interaction pattern" from the last sentence in 
the section, and striking any other text suggesting extensibility.  This 
would, I believe, accurately reflect the semantics currently defined and 
minimize the chance of nasty surprises for anyone expecting more than that.

[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0140.html
[2] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0145.html
[3] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0100.html
[4] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0154.html
[5] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0159.html
[6] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0167.html

Mark Nottingham wrote:

> On Mar 17, 2005, at 11:14 AM, Anish Karmarkar wrote:
>
>>>> If that approach is taken, wouldn't the same apply to the 
>>>> [relationship] property? Instead of defining the IRI: 
>>>> http://www.w3.org/@@@@/@@/addressing/reply we would have to define 
>>>> something like a [reply-relationship] property.
>>>
>>>
>>> Are you suggesting the spec is inconsistent and plan on raising 
>>> another issue before or after last call?
>>
>>
>> David Hull has already raised this as an issue. Although, I don't 
>> think this has been logged officially as an issue.
>
>
> We discussed this on Monday, and determined that it should not be 
> added to the issues list, as it seemed to be covered by i042.
>
> Looking more closely at the description and resolution of i042, there 
> is some ambiguity; it's not clear that MAP extensibility was 
> explicitly covered by the resolution therein.
>
> Even so, David agreed that, considering the tenor of discussion on 
> Monday, he could live with a solution that simply clarified how 
> existing extensibility was to be used to achieve his goals, rather 
> than reworking the spec itself. Pursuant to this, he took an AI to 
> work with the editors on some text, which he started to explore at the 
> start of this thread.
>
> The WG seemed to agree that this was the preferable path forward. If 
> you or another WG Member is disputing that, we can discuss the issue 
> again on Monday, and work towards a more formal resolution.
>
> Please contact me if this is the case so that I can make space for it 
> on the agenda. Also, if you plan on supporting this issue's opening, 
> please assure that your preferred proposal is complete and 
> well-described on the list before then.
>
> Regards,
>
> -- 
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
>