See also: IRC log
<trackbot> Date: 02 December 2008
<scribe> scribe: mphillip
<Roland> http://www.w3.org/2002/ws/soapjms/tracker/actions/open
Action 19 - No progress
<trackbot> Sorry, couldn't find user - 19
Roland: no progress on actions 32
and 48
... or 51 and 53
close action-54
<trackbot> ACTION-54 Send email to secretary general to progress the IETF spec closed
Roland: Eric has forwarded a note containing the options to the list
http://lists.w3.org/Archives/Public/public-soap-jms/2008Dec/0004.html
Roland: In Last Call - no comments received yet
Roland: No test cases created yet, no nothing else to discuss at this time
Phil: On the subject of
assertions, in our spec. we are prescriptive about the format
of the message body
... i.e. If the message contains attachments, it will be a mime
multipart message
Phile: otherwise it will be a regular SOAP envelope
Phil: However it is not the
transport's responsibility to determine the format of the
message - this happens higher in the stack by the SOAP
serialiser
... The spec. might be easier to implement if we alter some of
the assertions in the spec so that they do not impose these
message formats
Roland: The most important consideration is interoperability - how would changes like this affect interoperability
Phil: This *shouldn't* affect
interoperability - the content type of the payload should be
passed up the SOAP stack for the higher levels to
interpret
... In the Apache Axis 2 JAX-WS implementation, if MTOM is
enabled then every message is created as a mime-multipart
message regardless of whether it has an attachment
Roland: We need to work through the implications of how this might affect interoperability
Roland: The point of testing is to find issues like this and we may have to react to them
Phil: The JMS content type property and the SOAP or other payload of the message must match but do we need to be more prescriptive than that?
Roland: We need to look at the SOAP with Attachments spec. to see if these are the requirements from that spec.
action Phil to look at the relevant specifications e.g. SOAP with Attachments to assess whether SOAP/JMS binding spec. needs the assertions regarding content type
<trackbot> Created ACTION-55 - Look at the relevant specifications e.g. SOAP with Attachments to assess whether SOAP/JMS binding spec. needs the assertions regarding content type [on Phil Adams - due 2008-12-09].
Phil: From the standpoint of
interoperability, the content type doesn't matter to the
SOAP/JMS transport - it just has to be relayed between the SOAP
sending and receiving nodes
... HTTP and JMS should work the same way
Roland: That was our intent
Peter: SWA spec mentions SMTP - JMS is in similar situation