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

Hmmm.

This appears to have quite a bit of HTTP content negotiation built into 
it.

On Tue, 9 Nov 2010 20:26:41 +0100, Jean-Baptiste Bugeaud wrote:
> I do fully agree with your statements. And basically, I was simply
> thinking of making sure the specification does not prevent EXI (or
> GZip) from beeing used as a way to encode the content in an
> interroperable way.

Good.

> At this time, there are things that prevent a content encoding (such
> as EXI) from beeing used :
>  - no way to store the exact content encoding used

In fact, JMS headers are a clear extensibility point, as are MIME 
headers in the content of the message.

>  - mandatory alignment of octet and content type

Not too clear on what that means.

>  - no clarification of error scenari

Point.

> To solve those issues, an idea would be to add content encoding
> feature inspired with the existing Content Coding HTTP 1.1 feature.
> 
> Practically, this means add a SOAPJMS property for tagging the feature
> and WSDL property to indicate the content encoding features available
> on the destination.

I can see adding the header (although it's going to be straightforward 
MIME header, since SOAP with Attachments and MTOM both have a composite 
MIME type at the top level, and composite types don't use 
Content-Encoding).

> Doing so, there will be very with minimal impact for implementers but
> clear interroperability and extensibility. If you don't plan to suport
> any content encoding, on the client side you have nothing to do. And,
> on server side, you only need to make sure that you cancel any message
> send with a content encoding (aka not "identity" encoding) according
> to the spec (aka send the specified fault).

ContentEncodingNotSupported, yes.

> Here is the draft of the specification impact for such a proposition.
> 
> ===========================
> 
> Addendum to section 2.2.1 :
> 
> 
> [Definition: soapjms:acceptEncoding] (list of xsd:string)
> 	* Identifies the list of accepted values for content encoding that
> can be set using soapjms:contentEncoding.
> 	* [Definition: Each values indicated as accept content encoding MUST
> be supported by the target destination implementation.†]
> 	* [Definition: A caller SHOULD only use Each values indicated as
> accept content encoding MUST be supported by the target.†]

I think all of this is in the realm of content negotiation, and not 
necessary.

Supply ContentEncodingNotSupported, and if someone sends the wrong 
thing, you shrug, send an error, and you're done.  Supported content 
encodings might be indicated in the WSDL; if there's not already a 
pattern for that, then other folks don't consider it necessary either.

> Addendum to section 2.2.3 :
> 
> [Definition: soapjms:contentEncoding] (xsd:string)
> 	* Identifies the transformation that has been applied to the message
> payload body.

No.  At least, I don't think so.

As I understand EXI, it's part of support for MTOM and such.  It's the 
attachments that are being encoded.  Yes/No?  If yes, then there will 
never be a JMS-layer header indicating encoding.

Now, if EXI can be used for a non-composite SOAP message itself (that 
is, a SOAP message that is not part of a MIME multipart message), then 
perhaps we need this.

>         * [Definition: If the content encoding is specified, it is
> checked to ensure that it matches the content encoding values
> supported. A fault MUST be generated with subcode
> contentEncodingNotSupported if the encoding values do not match.†]

Errrr.  If the Content Encoding contains an unrecognized or unsupported 
value, the client or server should generate a fault with subcode 
ContentEncodingNotSupported.

> 	* [Definition: If no content encoding property is set or no value is
> set, the property MUST be assumed as "identity".†]

Identity is the only thing that our specification is likely to define.

> 	* [Definition: If soapjms:acceptEncoding was set, the contentEncoding
> value SHOULD be set to any of those value.†]

Well, no.  It MUST be set to a value corresponding to the encoding 
used, about which we are not going to say anything.  I hope.

> Update to section 2.4 :
> 
> change
> "The bytes or characters of the JMS Message payload correspond to the
> MIME format as indicated by the definition of the contentType
> property"
> with
> "The bytes or characters of the JMS Message payload correspond to the
> MIME format as indicated by the definition of the contentType property
> and the contentEncoding property".

and if defined, the contentEncoding property.

> change
> "and specifies an appropriate value for the contentType property which"
> by
> "and specifies an appropriate value for the contentType property and
> contentEncoding property which

I'd rather leave contentEncoding mostly-undefined (if undefined, 
identity).

> Alter of 2.4.1 :
>  a new point in the list of consideration for TextMessage :
> 	- Messages using the SOAP JMS content encoding will need to use
> Content-Transfer-Encoding for attachment parts.

I hope this is a typographic error?  You mean Content-Encoding, not 
Content-Transfer-Encoding, correct?  They're very different things; 
Content-Transfer-Encoding is a required MIME property, forbidden by 
HTTP.  Content-Encoding uses the MIME-reserved "Content-" prefix, but 
is defined by the HTTP specification and covers a different form of 
"encoding".  You can't use Content-Encoding in (most) MIME-compliant 
protocols, where Content-Transfer-Encoding is required; you can't use 
Content-Transfer-Encoding in any HTTP-consistent pseudo-MIME supporting 
protocol (it's forbidden to use in HTTP), but can use Content-Encoding.

</network-protocol-geek>

> Addendum to section 2.8 :
> 
>  Add of :
>  - contentEncodingNotSupported
>  - contentEncodingMismatch

Mmmm.  With minimal explanation I think.  Vendors MUST support the 
identity encoding; others will go without mention (my preference).

> Addendum to section 3.4 :
>  Add the element acceptEncoding in the list.

Let's not go there.  We don't need content negotiation; in the first 
iteration of SOAP/JMS, a clear error pattern is perfectly adequate.

> Add of a new section  :
>  X.X Content Encoding
>  Content coding values indicate an encoding transformation that has
> been or can be applied to the JMS message body content.
>  Content codings are primarily used to allow a message body to be
> compressed or otherwise usefully transformed without losing the
> identity of its underlying media type and without loss of information.
> 
>  All content-coding values are case-sensitive.
> 
>  The Internet Assigned Numbers Authority (IANA) acts as a registry for
> content encoding value tokens. Initially the list of valid values is
> taken from the HTTP 1.1 Content Coding values (see
> 
http://www.iana.org/assignments/http-parameters/http-parameters.xml#http-parameters-1
> ).
> 
>  New content-coding value tokens SHOULD be registered to allow
> interoperability between clients and servers, specifications of the
> content coding algorithms needed to implement a new value SHOULD be
> publicly available and adequate for independent implementation, and
> conform to the purpose of content coding defined in this section.
> 
>  An implementation SHOULD support gzip or (and ?) exi content encoding.

I think all of this is superfluous--and tending to lead to a need to 
add more and more references.  Maybe just the pointer to the IANA 
registry, and the requirement to support identity?

Note: throughout the above, I speak for myself (and for my employer as 
its representative on this working group), not for the working group as 
a whole.

Summarizing and rephrasing my responses: Thank you for the detailed 
suggestions; that was very helpful.  I believe that they go too far in 
some directions; we should require no more than identity support, and I 
do not believe that we need content negotiation.  I'm not clear whether 
we need a JMS Header defined, or if we need worry about 
Content-Encoding only for the components of a multi-part message.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 9 November 2010 20:16:40 UTC