W3C home > Mailing lists > Public > public-soap-jms@w3.org > November 2010

Re: Allow EXI as characterization for XML in the JMS body ?

From: Eric Johnson <eric@tibco.com>
Date: Wed, 10 Nov 2010 18:50:10 -0800
Message-ID: <4CDB59E2.9080906@tibco.com>
To: Yves Lafon <ylafon@w3.org>
CC: Jean-Baptiste Bugeaud <bugeaud@gmail.com>, Amelia A Lewis <alewis@tibco.com>, public-soap-jms@w3.org
Hi Yves, Jean-Baptiste,

On 11/10/10 10:01 AM, Yves Lafon wrote:
> On Tue, 9 Nov 2010, Eric Johnson wrote:
>> b) I couldn't find any documentation/specification that describes how 
>> to use EXI with SOAP/HTTP.  From what I can figure out, there are a 
>> few corner cases even with HTTP, and it would help me to understand 
>> if there was complete documentation of how it would work.
> Same as gzip apart the fact tht it cannot be a Transfer-Encoding.

OK, so I dug for examples of how to to use gzip with SOAP, and find 
myself still a little puzzled.

a) None of the examples I found made any reference whatsoever to content 
encoding negotiation.  For example I found examples related to Apache 
Axis that just set a configuration property.

b) Nothing I saw indicated anything about decorating WSDL to indicate 
that the use of gzip or exi was actually acceptable to the receiving 
node.  Maybe I'm being overly pedantic on this point, but I don't think so.

I'm not sure we should be saying anything about what content-encoding is 
acceptable.  In the same way that we don't indicate on the inbound 
request that use of MTOM is acceptable in the response, I don't think we 
add anything with accept-content-encoding.

I think we can define the way to carry the information 
(SOAPJMS_contentEncoding ?) that EXI is in use, and make reference to 
the IANA registry.  And we can define how to deal with when it is not 
supported, but I don't see adding "accept-content-encoding" support.  If 
implementations need that, then that should be a WSDL policy to support 
that, and not specific to SOAP/JMS.

As to one point from Jean-Baptiste:
"Well, we can link the HTTP header entry at IANA but doing so it means 
that any entry there will be valid for SOAPJMS as well.  I do not find a 
reason the two should diverge, so this point realy
need to discussed between by all the editors."

Well, if we diverge from what HTTP enumerates, then we probably need to 
define our own registration with the IANA.  Yuck.

Received on Thursday, 11 November 2010 02:50:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:22 UTC