RE: Features: required implementation and use (was Re: Describing which blobs are to be optimized.)

this crystallises my POV on this subject:

1) that setting the MTOM feature for a message indicates that a
   sender may optionally send soap+xml or a mime package, but the 
   receiver mustUnderstand MTOM messages regardless of the state 
   within an MEP. If a receiver is unable to process MTOM messages 
   then it should use another endpoint, binding or interface.

2) i see little or no value in WSDL describing which parts of a
   message will appear as a separate MIME section. This is best
   left to run time and the discretion of the sender.

Paul


-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Hugo Haas
Sent: 08 June 2004 11:16
To: Glen Daniels
Cc: Marc Hadley; Jonathan Marsh; www-ws-desc@w3.org; xml-dist-app@w3.org
Subject: Features: required implementation and use (was Re: Describing
which blobs are to be optimized.)


* Glen Daniels <gdaniels@sonicsoftware.com> [2004-06-07 11:49-0400]
[..]
> Second, we could add something like a "mustUnderstand" attribute to
> feature/module declarations, which indicates that anyone using the
WSDL
> must understand the given extension, but that the usage of that
> extension is still optional unless "required='true'" is specified.
> Required extensions would remain as they are - where both usage and
> understanding are mandated.  This would allow specifying features
which
> may or may not be used, but whose use affects the syntax/semantics of
> the exchange enough that failure to understand them would completely
> screw things up in the event they were used.

It raises interesting questions when considering MTOM.

When the HTTP Transmission Optimization Feature is in use, the media
type of the entity received changes from application/soap+xml to
mime/multipart-related, which means that an agent not supporting the
feature is going to be seriously confused, and return a 415 according
to the SOAP HTTP binding[1] if it's the provider agent, or probably
just discard the message it's the requester agent.

That means that if MTOM is used, MTOM has to be understood by the
message receiver to process the message. There is no such thing as a
mustUnderstand=false for MTOM, which could be the case for other
features too.

That means that there are two cases to avoid runtime failures in such
a scenario:
- the mustUnderstand attribute you are proposing would always need to
  be set to true for MTOM.
- if the use of MTOM was not required and the requester agent didn't
  want to provider agent to use it as it doesn't support it, it would
  need to indicate it at runtime, e.g. with Don't Use MTOM (DU-MTOM)
  SOAP feature which could appear with an HTTP/1.1 Accept header or a
  SOAP header.

It would be described as follows, for an input-output MEP:

    output:	MTOM required=false mustUnderstand=true

or:

    output:	MTOM required=false mustUnderstand=false
    input:	DU-MTOM required=true

Avoiding runtime errors for MTOM without mustUnderstand will mean
either requiring the HTTP Transmission Optimization Feature or not
using it. We are basically approaching the domain of constraints and
capabilities.

Note that this required/mustUnderstand issue also applies to the SOAP
module component in our SOAP 1.2 binding, as a SOAP module may provide
features or headers that always need to be understood.

Regards,

Hugo

  1.
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-reqbindwaitsta
te
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Tuesday, 8 June 2004 07:15:41 UTC