Re: Restating content

Greeting, what, if anything, should be done with the examples in Appendix 
"C SOAP/JMS Underlying Protocol Binding Examples (Non-Normative)" ?

Regards, Roland
FBCS, CITP
IBM Software Group, Strategy, Software Standards
Tel/Fax: +44 (0)1926-465440



From:
Eric Johnson <eric@tibco.com>
To:
"SOAP/JMS (list)" <public-soap-jms@w3.org>
Date:
14/04/2009 01:42
Subject:
Restating content



As per email of
http://lists.w3.org/Archives/Public/public-soap-jms/2009Mar/0016.html

and the meeting minutes:
http://www.w3.org/2009/03/17-soap-jms-minutes.html

I agreed to revise the message content section (section 2.4):
http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/soapjms.html?content-type=text/html;%20charset=utf-8#binding-message-body


Revising Phil's proposal by sentence:

*** --> unchanged
--- --> old version
+++ --> new version

(1)
*** 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. ?].

(2)
--- 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 formatting of the SOAP payload is determined by the sending SOAP
node, and should follow the same pattern as for the SOAP/HTTP binding.
Based on the sending node's use of [SOAP 1.1], SOAP 1.2 [SOAP 1.2
Messaging Framework], [SOAP Messages with Attachments], and [SOAP MTOM],
the _contentType_ property MUST be set as it would be for SOAP/HTTP, and
the message body MUST use the corresponding format.

(3)
--- For example, if the SOAP payload is formatted as a simple SOAP
envelope, the Content-type value MUST be specified as "text/xml" for
SOAP 1.1 or "application/soap+xml" for SOAP 1.2.

+++ For example, if the SOAP payload is formatted as a simple SOAP
envelope, the contentType property value MUST be specified as "text/xml"
for SOAP 1.1 or "application/soap+xml" for SOAP 1.2.

(4)
--- On the other hand, if the SOAP payload is formatted as a MIME
multipart message, the Content-type value MUST be specified as
"multipart/related".
+++ On the other hand, if the SOAP payload is formatted as a MIME
multipart message, the _contentType_ property value MUST be specified as
"multipart/related".

(5)
--- 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 which appropriately describes
it to the receiving SOAP node.
+++ In this way, the SOAP node determines the proper formatting of the
SOAP payload irrespective of the underlying JMS message type, and
specifies an appropriate value for the _contentType_ which describes it
to the receiving SOAP node.

(6)
--- 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".
+++ Note also that if the payload is formatted as a MIME multipart
message, then the byte or character encountered in the JMS Message body
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".  Likewise, if
the message is formatted as "text/xml" or "application/soap+xml", then
the first byte or character of the JMS Message body MUST be a conforming
XML document.

(7)
--- 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 value of
"multipart/related".
+++

Putting it all together:

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 sending SOAP
node, and should follow the same pattern as for the SOAP/HTTP binding.
Based on the sending node's use of [SOAP 1.1], SOAP 1.2 [SOAP 1.2
Messaging Framework], [SOAP Messages with Attachments], and [SOAP MTOM],
the _contentType_ property MUST be set as it would be for SOAP/HTTP, and
the message body MUST use the corresponding format.  For example, if the
SOAP payload is formatted as a simple SOAP envelope, the contentType
property value MUST 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 _contentType_
property value MUST 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 type, and specifies
an appropriate value for the _contentType_ which describes it to the
receiving SOAP node.  Note also that if the payload is formatted as a
MIME multipart message, then the byte or character encountered in the
JMS Message body 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".  Likewise, if the message is formatted as "text/xml" or
"application/soap+xml", then the first byte or character of the JMS
Message body MUST be a conforming XML document.

=======================================================================

Whew!  I'm guessing we'll have one more round of nitpicks on this, at
least.  I mean for _contentType_ above to be interpreted as a
hyperlinked reference to the "contentType" property.  Likewise, text of
the form [SOAP MTOM] is meant to be a formal reference to our references
section.

-Eric.









Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Received on Tuesday, 14 April 2009 12:51:22 UTC