RE: Describing which blobs are to be optimized.

Glen,
As I discussed before in the specific case of optional MTOM
optimization, I prefer the client and server to behave symmetrically
with respect to optional features declared at the operation level,
unless otherwise explicitly specified. So I support your questioning of
current asymmetric assumptions regarding optional features.

Ugo

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Glen Daniels
> Sent: Monday, June 07, 2004 8:49 AM
> To: Hugo Haas; Marc Hadley
> Cc: Jonathan Marsh; [email protected]; [email protected]
> Subject: RE: Describing which blobs are to be optimized.
> 
> 
> 
> 
> Hi Hugo, Marc:
> 
> The interesting part of this, if you interpret it as Hugo has 
> below, is that a feature marked optional at the operation 
> level might imply that the response from the server is in a 
> format that a client who does not understand that feature 
> cannot accept.  With respect to MTOM/XOP over HTTP, I would 
> think we could use the "accept" header to indicate the 
> client's ability to accept optimized responses, but the 
> general case is perhaps more interesting.
> 
> The way we've been talking about it up until this point is 
> that optional features are optional in that the originator 
> may or may not engage them, but the server must support them. 
>  In other words, if a WSDL specifies that a security feature 
> is optional for a given SOAP binding, and you want to 
> implement a service that uses that binding, you must 
> understand and accept whatever rules are specified by the 
> security feature.  No such requirement exists on the client, 
> though - that guy is free to simply ignore the feature 
> declaration if it's optional.  This way of looking at it is 
> focused on the originator making the decision to engage the 
> feature, not the server.
> 
> If we want to allow "server engaged" optional features, I 
> think we get into the same kind of pattern which might 
> require the client to understand them in order to claim full 
> understanding of the WSDL.  If I can say that the server 
> *might* send back an encrypted response, then mightn't the 
> client need to understand the encryption mechanism in order 
> to successfully communicate?
> 
> We can deal with this in a number of ways.  First, the simple 
> way - optional extensions may be ignored by clients, but 
> failures may always happen at runtime, perhaps as a result of 
> a server engaging something which was marked optional.  To 
> some extent this can happen anyway, in that a given service 
> may decide to use an extension that wasn't mentioned in the 
> WSDL, but putting in optional extension declarations at least 
> gives both sides more of a clue as to what is supported.  I 
> think this is pretty much status quo.
> 
> 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.
> 
> In general, I think we need to be as crystal clear as we can 
> be about which kinds of extension declarations might affect 
> which portions of an interaction described by WSDL.  That 
> said, a third option entails making sure we have the 
> expressive capability to indicate that a particular extension 
> may be in use, and which side(s) of an interaction may use it
> - which probably involves the kind of things Hugo discusses 
> below (i.e. it's pretty clear that an optional feature on the 
> <output> of a given request-response interaction is going to 
> be something the server may do), combined with clear text 
> which tells us what it means when extensions are used at the 
> higher levels.
> 
> This is just some off-the-cuff thinking.  We probably want to 
> talk about this on a call soon or at the F2F.
> 
> --Glen
> 
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Hugo Haas
> > Sent: Monday, June 07, 2004 10:16 AM
> > To: Marc Hadley
> > Cc: Jonathan Marsh; [email protected]; [email protected]
> > Subject: Re: Describing which blobs are to be optimized.
> > 
> > Hi Marc.
> > 
> > * Marc Hadley <[email protected]> [2004-06-04 16:03-0400]
> > > On a related note I'm unclear on the semantics implied by
> > marking the
> > > MTOM/XOP feature as optional. I can see several interpretations:
> > > 
> > > (i) a service will never use it but a client may
> > > (ii) a service will not use it unless client does first
> > > (iii) a service will always use it but a client isn't obliged to
> > 
> > Section 2.7.1[1] specifies:
> > 
> > | The presence of a feature component in a WSDL description 
> indicates
> > | that the service supports the feature and may require a requester 
> > | agent that interacts with the service to use that feature.
> > 
> > When the use of the MTOM feature is not required, it just
> > means that the service supports it, which means that the 
> > requester agent or the provider agent may use it, depending 
> > on the direction of the message
> > 
> > Your interpretations can be described with:
> > 
> > (i) the input message description has an optional MTOM
> > feature component associated with it, and the output 
> message doesn't.
> > 
> > (iii) the input message description has an optional MTOM
> > feature component associated with it, and the output message 
> > has a required MTOM feature component associated with it.
> > 
> > If an optional MTOM feature were specified on an operation,
> > both the requester and provider agent may use it.
> > 
> > I don't believe that (ii) is describable with WSDL 2.0. It
> > goes into the domain of policies, I think.
> > 
> > Regards,
> > 
> > Hugo
> > 
> >   1. http://www.w3.org/TR/2004/WD-wsdl20-20040326/#Feature_details
> > --
> > Hugo Haas - W3C
> > mailto:[email protected] - http://www.w3.org/People/Hugo/
> > 
> 
>