See also: IRC log
<trackbot> Date: 02 March 2010
<scribe> Scribe: Mark
<scribe> done
Minutes are approved
All approve the agenda
<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
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].
http://www.w3.org/2002/ws/soapjms/tracker/issues/28
<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].
http://www.w3.org/2002/ws/soapjms/tracker/issues/29
(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].
http://www.w3.org/2002/ws/soapjms/tracker/issues/30
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
http://www.w3.org/2002/ws/soapjms/tracker/issues/31
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
http://www.w3.org/2002/ws/soapjms/tracker/issues/18
http://lists.w3.org/Archives/Public/public-soap-jms/2010Jan/0025.html
RESOLUTION: All accept the application of Issue 18
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]