See also: IRC log
<trackbot> Date: 30 November 2010
trackbot, start telcon
<trackbot> Meeting: SOAP-JMS Binding Working Group Teleconference
<trackbot> Date: 30 November 2010
<scribe> Scribe: Mark
RESOLUTION: Minutes are approved
No changes to agenda
Eric: The workgroup charter was
scheduled to expire this December
... That isn't a problem as long as the WG is seen to be making progress, however Yves has extended our charter to the middle of next year
Eric: No progress on 146, or 202
Derek: Started looking at 222 - still in progress
Phil: 223 still pending
Peter: 225 (testcase mods arising from action 219) - now done
<trackbot> ACTION-225 Apply Action-219 changes to test spec closed
Phil: ACTION-227 is done - http://lists.w3.org/Archives/Public/public-soap-jms/2010Nov/0035.html
<trackbot> ACTION-227 Raise issue on the SOAP/JMS namespace distinction between SOAP 1.1 and 1.2 and present proposal closed
Eric: 228 is done
<trackbot> ACTION-228 Come up with a proposal for Issue-65 closed
Phil: 229 - is done - see: http://lists.w3.org/Archives/Public/public-soap-jms/2010Nov/0036.html
<trackbot> ACTION-229 Come up with a proposal for Issue-65 closed
Mark: Starting to look at whether IBM's WebSphere Message Broker can be tested against CXF (an independent implementation from WebSphere App Server)
Phil: What about pending chages e.g. Issue 65?
Eric: For the purposes of moving to PR, implementations must conform to last published draft.
Phil: JAX-WS provides a value
that can be used by an endpoint developer in the Binding type
annotation to specify the SOAP version and the transport. Our
Binding spec only defines a single namespace, and so is
insufficient to denote both SOAP version(1.1 or 1.2) and
... Proposal is to define 2 values - one for SOAP 1.1 and the other for SOAP 1.2
See proposal in ISSUE-67 following the text "Regarding specific changes to the binding spec to resolve this issue"...
RESOLUTION: no objections - ISSUE-67 is opened
Mark: Do we need to update namespace table etc. in spec.
Phil: No, should keep everything else the same - these are new namespace values
Eric: *Could* add these in as
additional normative values in spec. but can't see any concrete
use cases for that
... Suggest dropping the last paragraph in the proposal (which begins "Ideally, these values would be defined by the JAX-WS specification")
... ...and perhaps amend the previous paragraph to be more generalised - so that it doesn't just apply to JAX-WS
Phil: Perhaps we could replace the final paragraph with some text that acknowledges that there may be some other technologies that would find these values useful
Eric: That might be overkill unless we can think of concrete examples
RESOLUTION: The proposal is approved with the final paragraph removed
action mark to apply the changes for ISSUE-67
<trackbot> Created ACTION-230 - Apply the changes for ISSUE-67 [on Mark Phillips - due 2010-12-07].
Eric: Public comments from the mailing list regarding the use of the API for Setting JMS Header properties
Mark: Good spot - been in the spec for a long time
RESOLUTION: The ISSUE-68 is opened
<scribe> ACTION: mark to come up with a concrete proposal to resolve issue 68 [recorded in http://www.w3.org/2010/11/30-soap-jms-minutes.html#action01]
<trackbot> Created ACTION-231 - Come up with a concrete proposal to resolve issue 68 [on Mark Phillips - due 2010-12-07].
Eric: Changed spec. to point at revision 10 of URI scheme ( http://www.w3.org/2002/ws/soapjms/tracker/issues/27 )
<eric> Issues to discuss: http://lists.w3.org/Archives/Public/public-soap-jms/2010Nov/0032.html
Discussion: No way to find out what encodings a service provider supports.
Eric: HTTP can determine what encodings a web server Accepts but this proposal does not include an equivalent
Amy: We could simplfiy by saying that content-encoding can only be applied to single part messages
Eric: Yes - that's a slightly different issue - do we want to allow this property for multi-part messages?
Amy: In 2.2.3 we would add a bullet point that says soapjms:contentEncoding must not be used for multi-part messages
Phil: If we adopt this as a normative change it will require changes to existing implementations - at a minimum, to check for this new property, and throw the appropriate SOAP fault if encoding is not supported
<alewis> * Restriction: the property is not defined for composite messages (messages with a Content-Type of "multipart" or "message"), only for discrete messages (Content-Type "application" or "text", for this specification).
Eric: we *could* soften the
requirement in the final bullet in 2.2.3 to "SHOULD" so that
existing implementations don't change
... If we keep the hard requirement we would need a new test to send a bogus encoding and ensure we get a fault back
Phil: We shoud make it a MUST if we'e going to put it in at all
Peter: Agree with the discussion - still pondering SHOULD vs. MUST for the fault
Mark: If we add a new fault we will also need to add it to the schema
Eric: If anyone cares strongly
about the MUST then please make a counter proposal
... to revise the proposal with Amy's addition and the fault in the proposal
<scribe> ACTION: Eric to revise the proposal with Amy's addition and the fault in the proposal [recorded in http://www.w3.org/2010/11/30-soap-jms-minutes.html#action02]
<trackbot> Created ACTION-232 - Revise the proposal with Amy's addition and the fault in the proposal [on Eric Johnson - due 2010-12-07].
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) Succeeded: s/propoalin/proposal in/ Succeeded: s/wnat/want/ No ScribeNick specified. Guessing ScribeNick: mphillip Found Scribe: Mark Default Present: padams, +1.919.663.aaaa, Derek, Mark, +1.209.474.aabb, +1.781.280.aacc, alewis, eric Present: padams +1.919.663.aaaa Derek Mark +1.209.474.aabb +1.781.280.aacc alewis eric Found Date: 30 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/30-soap-jms-minutes.html People with action items: eric mark WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]