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

 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> Sent: 08 June 2004 12:14
> To: [email protected]; [email protected]
> Cc: [email protected]; Jonathan Marsh; [email protected]; 
> [email protected]
> Subject: 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.

I'm not sure I understand the above. If the WSDL description of an
endpoint says that the endpoint supports MTOM, then that endpoint had
better be able to consume and/or emit MTOM messages ( depending on
whether you can state MTOM support at the binding, operation or
input/output level ).

> 
> 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.

+1. 

Essentially any element in the schema description of the message which
is xs:base64Binary ( or a type derived therefrom ) is a potential
separate MIME part.

Gudge

> 
> Paul
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Hugo Haas
> Sent: 08 June 2004 11:16
> To: Glen Daniels
> Cc: Marc Hadley; Jonathan Marsh; [email protected]; 
> [email protected]
> Subject: Features: required implementation and use (was Re: Describing
> which blobs are to be optimized.)
> 
> 
> * Glen Daniels <[email protected]> [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-reqb
indwaitsta
> te
> -- 
> Hugo Haas - W3C
> mailto:[email protected] - http://www.w3.org/People/Hugo/
> 
>