See also: IRC log
<trackbot> Date: 22 June 2010
<eric> Mark - you having difficulty dialing in?
yes, Zakim not recognising the tones
trying the US number
better: -)
<scribe> Scribe: Mark
Minutes approved
Mark: Would like to add new issue regarding landing page and broken like
action Eric to fix borken linkon landing page
<trackbot> Created ACTION-181 - Fix borken linkon landing page [on Eric Johnson - due 2010-06-29].
Mark: See http://lists.w3.org/Archives/Public/public-soap-jms/2010Jun/0025.html
Eric: No progress on actions
Peter: No progress on actions
<scribe> No progress
<eric> http://www.w3.org/2002/ws/soapjms/tracker/issues/39
Amy: Gives overview of issue
<eric> Text of proposal:
http://lists.w3.org/Archives/Public/public-soap-jms/2010Jun/0023.html
<eric> The original rule :
<eric> S MUST copy the JMSMessageID from the original
<eric> request to the JMSCorrelationID of the response
<eric> Becomes :
<eric> if there is no JMSCorrelationId set in the request,
<eric> S MUST copy the JMSMessageID from the original
<eric> request to the JMSCorrelationID of the response.
<eric> else
<eric> S MUST copy the JMSCorrelationID from original
<eric> request to the JMSCorrelationID of the response.
Mark: Very much likes the new 2038 protocol proposed by David in http://lists.w3.org/Archives/Public/public-soap-jms/2010Jun/0023.html - suggest we adopt it
Derek: Makes perfect sense, but concerned that this would be a misuse of correlation ID - could we set another message property rather than re-using correlation Id?
Amy: The proposal effectively makes correlation Id into a conversation Id - it is a really clever trick, and it is in the mainstream of JMS to set the Correlation Id first - uses existing technology rather than inventing new headers
Mark: It is a pretty standard technique.. it is used by MQ as a common correlation pattern (COPY CORRELID). JMS makes it more useful because the MsgId can't be set by the sender
Amy: Worried that a new header starts to open the floodgates towards re-implementing WS-Addressing
Peter: Agree - we should not invent new properties, but curious about how existing JMS bridges support correlId. Generally think it is a good idea
DereK: Definitely agree this
issue raises a legitimate concern
... and the use case raised by David is a good one
All: No objections to opening this as an issue
Eric: If we specify the use of
CorrellationId then it might prohibit using correlation Id for
som advanced patterns, but that's OK because WS-Addressing can
be used in those cases
... The other option is some other message property for
correlation. The disadvantage is that every message has the
overhad of another property
Mark: *Could* be done today with a custom property which would appear in the RequestURI rather than inventing a new property (but I still like David's proposal better)
Eric: Could be done with temporary reply Qs
Peter: and this proposal doesn't preclude temporary Qs
Eric: So is David's proposal flexible enough or do we need more flexibility
Amy: Votes for proposal
Mark: +1
Derek: +1 - does not cater for all fringe use-cases but it's a good solution
Peter: +1 Curious to see how JMS bridges would handle it, but this is good
Eric: in favour too - looked back through archives and didn't find anything to conflict with this
Mark: May be better to add to the
spec as a separate assertion
... and add new tests
Amy: Will this send us back to last cal?
Eric: No, don't believe so
Amy: If this is important enough to go in, then it must be normative and documented as one of the significant differences between CR and PR
<Yves> agree that it should be documented
Peter: Does this get manifested in any new properties that might be included in WSDL etc.?
Derek: No this is behaviour determined solely by the message sender - i.e. whether to set the correlation id or not
Eric: so we are generally agreed on the proposal. Need to check how much of the binding spec. needs to change.
Action Mark to check how much of the binding spec. needs to change and make a proposal
<trackbot> Created ACTION-182 - Check how much of the binding spec. needs to change and make a proposal [on Mark Phillips - due 2010-06-29].
Eric: We will vote on the
proposal next week
... Please discuss concerns or newsuggestion on the list
None
http://www.w3.org/2002/ws/soapjms/tracker/issues/38
<scribe> ACTION: Eric to apply resolution to issue 38 [recorded in http://www.w3.org/2010/06/22-soap-jms-minutes.html#action01]
Action Eric to apply resolution to issue 38
<trackbot> Created ACTION-183 - Apply resolution to issue 38 [on Eric Johnson - due 2010-06-29].
<trackbot> Created ACTION-184 - Apply resolution to issue 38 [on Eric Johnson - due 2010-06-29].
<mphillip1> Eric: So any one of us could submit a patch with the latest changes and if a vendor's implementation passes the CXF tests, then we reach the criteria for PR
<mphillip1> Peter: The test validation is based on JAX-WS clients with validation performed by CXF interceptors
<mphillip1> Peter: uses ACtiveMQ but other JMS providers could be plugged in
<mphillip1> Eric: Should we skip meeting following July 4th?
<mphillip1> All: No vacation plans
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 WARNING: No "Present: ... " found! Possibly Present: All Amy DereK Mark Peter Yves aaaa aabb aacc aadd aaee eric joined mphillip1 peaston soap-jms trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Found Date: 22 Jun 2010 Guessing minutes URL: http://www.w3.org/2010/06/22-soap-jms-minutes.html People with action items: eric WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]