SOAP-JMS Binding Working Group Teleconference

02 Mar 2010


See also: IRC log


alewis, Peter_Easton, eric, mphillip


<trackbot> Date: 02 March 2010

<scribe> Scribe: Mark

1) Appointment of the scribe

<scribe> done

2) Approval of prior meeting minutes

Minutes are approved

3) Review the agenda

All approve the agenda

4) Review action items

<scribe> no progress on 138

Eric: action 142 and 145 are done, believe 143 was complete by Phil, as was 144

close action-142

<trackbot> ACTION-142 Revise test cases 6 & 7 to pick a more sensible property than replyToName to come from thewsdl binding closed

close action-145

<trackbot> ACTION-145 Review the other half of the test cases closed

close action-144

<trackbot> ACTION-144 Review half the test cases (and send a note to Eric saying which ones ) closed

5) URI specification:

action Eric to follow up URI specification with Oracle

<trackbot> Created ACTION-146 - Follow up URI specification with Oracle [on Eric Johnson - due 2010-03-09].

6) Raised issues:


<eric> My apologies, I just hit the wrong button and hung up. calling back.

<eric> Any comments on the issue?

topicReplyToName is missing from a couple of places in the spec.

(XML schema and URI binding)

No objections to opening the issue and to accept the proposed resolution

action mark to apply the resolution to issue 28

<trackbot> Created ACTION-147 - Apply the resolution to issue 28 [on Mark Phillips - due 2010-03-09].


(behaviour of the responding node is too prescriptive about the destination to which the response must be sent)

Eric: 2 concerns:

Seems like the sending node could simply not set the reply to

If WS-Addressing sends the response elsewhere (not the annonymous reply) then this becomes a one-way MEP

Peter: If using WSA with anonymous reply then it uses the JMSReplyTo - it makes sense to honour the WSA musat understand destination if it is not anonymous

Eric: Struggling to see this as anything other than a SOAP one-way - (as opposed to a WSDL req/resp)
... If the reply address is not filled in or not honoured
... Perhaps this need to be addressed in the FAQ rather than the spec.
... We have written our one-way MEP as if it is the initiation of a request rather than (possibly) a response to a request

Peter: Inclined to keep this in the FAQ
... May need to describe in context of WSDL exchange patterns

Mark: Wouldn't an implementation which honours WS-Addressing above the JMSReplyTo in our spec. fail our compliance tests?

Eric: No if it uses one-way... sending a reply elsewhere would not be a SOAP request-response
... But our one-way might need rewording to cover responses as well as requests

Mark: Struggling to understand why MEP is not a SOAP request response when sending request to a replyTo which is not effectively the anonymous back-channel

Amy: HTTP is inherently req-resp

<Yves> SOAP MEP are soap request/responses patterns, WSDL MEP are decoupled from the SOAP one (that are decoupled from the underlying transport ones)

action Mark to review proposal, and debate on mailing list or propose a FAQ change

<trackbot> Created ACTION-148 - Review proposal, and debate on mailing list or propose a FAQ change [on Mark Phillips - due 2010-03-09].


Amy: In WSDL the URI can only come from the endpoint, though it's possible that proporties in the Endpoint could conflict with the URI

Eric: Yes, properties inside the endpoint could be overridden by the URI

Amy: Conflicting properties in URI and Endpoint may need to be flagged up as an error

Eric: This would not be consistent with what we did for Port in WSDL 1

<eric> I'm hearing nothing on the phone....

<eric> Did I drop off somehow?

<peaston> i still hearing

Amy: In WSDL terms Endpoint can't be overridden - it is the most concrete part of the WSDL

<eric> I'll call back then.

Peter: WSA might conflict with the endpoint information - is there an override mechanism that sets a precedence in WSA?

Amy: We have ruled WSA out of scope

Eric: We do seem to have an issue here - whether it is bringing WSDL 2.0 into line with WSDL 1.0 or vice-versa
... Question is how we resolve

Amy: Must stay cosistent with WSDL

RESOLUTION: No objections to opening issue 30


soapjms: isFault typing is ambiguous and value is weakened because it is an optional property

Eric: Don't want the overhead of the header for the 99% non-fault cases
... The 0 or 1 issue is definitely something we need to address - the isFault aspect is more questionable - for instance it may be a security issue - the definitive information that this is a fault is in the body of the message
... You could imagine a malicious responder not setting the fault and flooding a requester with effectively a denial of service attack
... This is an issue which we can talk about

RESOLUTION: No objections to opening the issue

8) Accepting applied resolutions:



RESOLUTION: All accept the application of Issue 18

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/03/02 18:02:07 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: mphillip
Found Scribe: Mark
Default Present: alewis, Peter_Easton, eric, mphillip
Present: alewis Peter_Easton eric mphillip
Agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2010Mar/0000.html
Found Date: 02 Mar 2010
Guessing minutes URL: http://www.w3.org/2010/03/02-soap-jms-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]