ACTION-65: clarify Content Type

Hi everyone,
ACTION-65 was assigned to me and I volunteered to make another attempt at 
the re-wording for section 2.4 of the binding spec.
My main goal is to try to relax the wording of section 2.4 somewhat so 
that the spec does not try to be too prescriptive in terms of
the relationship between the existence of attachments and the type of 
payload that might be used.


Currently, section 2.4 of the SOAP/JMS binding spec is worded like this:

The contents of the JMS Message body MUST be the SOAP payload as a JMS 
BytesMessage or TextMessage.† [Definition: Use fault subcode 
unsupportedJMSMessageFormat when the arriving message format is not 
BytesMessage or TextMessage. †]. The encoding will depend on whether the 
payload is simply a SOAP Envelope or whether there are any attachments, 
and the JMS "contentType" property 2.2.3 JMS Message properties will 
reflect this appropriately.
In the case of a message without any attachments, the JMS Message Body 
will contain the properly encoded bytes of the XML SOAP message, and 
nothing else. In this case the Content-type will be "text/xml" (for SOAP 
1.1) or "application/soap+xml" (for SOAP 1.2).†
In the case that there are attachments, the JMS Message Body will contain 
a multipart MIME message. The first thing encountered in byte stream MUST 
be the MIME boundary for the start of the first part — what MIME Part One 
[IETF RFC 2045] section 2.5 calls a "Body Part". The message will be 
encoded using SOAP Messages with Attachments [SOAP Messages with 
Attachments] or XOP [SOAP 1.1 Binding for MTOM 1.0] [SOAP MTOM], in either 
case with a Content-type of "multipart/related".


So, on the surface, this looks like the spec is saying that if there are 
attachments in the message then the SOAP sending node must use a MIME 
multipart message and if there are no attachments, then the SOAP sending 
node must use a simple SOAP envelope.      However, it's really not up to 
the SOAP/JMS layer to determine this, as there are potentially properties 
and configuration settings that are supported by the SOAP serialization 
engine that control this.  For example, in JAX-WS if the user sets the 
"enable MTOM" property to true, then the request message will be formatted 
as a MIME multipart message regardless of whether or not there are any 
attachments in the request.   Also, if the "enable MTOM" property is 
false, then a simple SOAP envelope will be used even if attachments exist 
(the attachments would be included inline using base64 encoding in that 
case - not optimum but yet still supported).
With this in mind, my proposed wording tries to relax the requirement to 
tie together the existence of attachments and the formatting of the SOAP 
payload, but yet still retain the requirement that the payload, if 
formatted with a MIME multipart message, starts with the MIME boundary, 
etc.

The contents of the JMS Message body MUST be the SOAP payload as a JMS 
BytesMessage or TextMessage.[Definition: Use fault subcode 
unsupportedJMSMessageFormat when the arriving message format is not 
BytesMessage or TextMessage. †]. The formatting of the SOAP payload is 
determined
by the SOAP node, and should follow the same rules as for the SOAP/HTTP 
binding, 
as described in the following specifications:  SOAP 1.1 specification, 
SOAP 1.2 specification, RFC 2376, RFC 2045.
The primary requirement is that the value used for the Content-type 
property must be 
consistent with the formatting of the SOAP payload.   For example, if the 
SOAP payload is formatted as a simple SOAP envelope, the Content-type 
property should be specified as "text/xml" (for SOAP 1.1) or 
"application/soap+xml" (for SOAP 1.2).  On the other hand, if the SOAP 
payload is formatted as a MIME multipart message, the Content-type 
property should be specified as "multipart/related".   In this way, the 
SOAP node determines the proper formatting of the SOAP payload 
irrespective of the underlying JMS message, and specifies a corresponding 
value for the Content-type property which appropriately describes it to 
the receiving SOAP node.  Note also that if the payload is formatted as a 
MIME
multipart message, then the first thing encountered in the JMS Message 
Body's 
byte stream MUST be the MIME boundary for the start of the first part — 
what MIME Part One [IETF RFC 2045] section 2.5 
calls a "Body Part". The message will be encoded using SOAP Messages with 
Attachments [SOAP Messages with Attachments] 
or XOP [SOAP 1.1 Binding for MTOM 1.0] [SOAP MTOM], in either case with a 
Content-type of "multipart/related".


Comments???
Phil 
__________________________________________________________________________________________________________ 

Phil Adams
phil_adams@us.ibm.com
WebSphere Application Server
Office: (512) 286-5041 (t/l 363)
Web Services Development
Mobile: (512) 750-6599
IBM - Austin, TX