Re: TIBCO objects to last call (resend)

Comments inline

Martin Gudgin wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org 
>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
>>Sent: 24 March 2005 00:52
>>To: public-ws-addressing@w3.org
>>Cc: Mark Nottingham
>>Subject: TIBCO objects to last call (resend)
>>
>>This message details TIBCO's reasons for objecting to the 
>>WS-Addressing core and SOAP binding documents going to last 
>>call.  There are several specific reasons, all of which 
>>center around the Message Addressing Properties (hereafter 
>>referred to as MAPs), and particularly around issues i050 and 
>>i054, which we consider to have been closed hastily.  We have 
>>no objection to the current formulation of EPRs and indeed 
>>believe that WS-Addressing would provide considerable value 
>>on the basis of EPRs alone.
>>
>>We have made our opposition to the current resolution of i054 
>>known and have formally voted against this resolution.  We 
>>are prepared to formally object to the core and SOAP binding 
>>specifications as they currently stand on the basis of this 
>>issue.  We also note that a new proposed resolution for this 
>>putatively closed issue has appeared since the vote 
>>concerning last call was taken.  
>>
>>Whatever the final resolution of i050 and i054, there 
>>currently remain significant questions as to the meaning of 
>>MAPs in the specification.  Many such questions, including 
>>those relating to the objections above, have been raised in 
>>public discussion over the past two weeks but have so far 
>>gone unanswered.  It is our opinion that several of these 
>>questions are of such a nature that if there is any 
>>significant doubt concerning them the specification is not 
>>sufficiently well-defined to be useful.  We do not claim that 
>>none of them can be answered, and in fact we hope that many 
>>of them can be answered quickly.  However, until they are, we 
>>cannot consider the discussion of the specification to be 
>>materially complete and cannot recommend putting the document 
>>out for public comment.
>>
>>These questions include
>>
>>
>>*	Whether the MAPs are considered to contain only those 
>>properties defined in the WS-Addressing specifications or 
>>whether other specifications may amend them 
>>    
>>
>
>I don't really understand why this question is relevant. Consider two
>scenarios;
>
>1.	WS-Addressing defines a set of properties and explicitly states
>that the set is extensible. A subsequent specification defines a set of
>extra properties that augment the set in WS-Addressing.
>
>2.	WS-Addressing defines a set of properties and explicitly states
>that the set is not extensible. A subsequent specification defines a set
>of extra properties for SOAP messages. 
>
>What is the practical, technical difference between the two approaches?
>In both cases a SOAP message can contain headers from the WS-Addressing
>spec and the subsequent spec. And be processed accordingly.
>  
>
I think part of the disconnect here is that I'm talking about endpoint 
properties in particular, and I gather that you may be thinking of 
properties in general.  If someone wants to define a "favourite 
ice-cream" property for a message, then it doesn't really matter.  But 
if someone wants to define an "alternate reply" or "urgent processing" 
endpoint that participates in some MEP and generally acts largely like 
reply and fault endpoints, then there are two cases to consider:

    * Having reply and fault defined in the core as part of the MAPs
      provides some value.  In that case, we have an obvious case for an
      extensibility point, and whatever value is provided should apply
      equally well to properties describing other endpoints
      participating in MEPs.
    * Having reply and fault defined in the core as part of the MAPs has
      no value.  In that case, remove them from the core.  It has been
      repeatedly asserted that it's not onerous to define endpoint
      properties outside the core.  In that case, there should be no
      problem with removing fault and reply from the MAPs and leaving
      their description completely to the WSDL binding.  I would most
      likely be fine with that, particularly since it would provide a
      proof by example of our extensibility story, which proof is so far
      utterly lacking.

At this point I'd like to explicitly add "What value does having reply 
and fault defined in the core MAPs provide?" to the list of open questions.

>  
>
>>*	If other specifications can amend this set, in what 
>>sense may it be said to be specified by WS-Addressing 
>>    
>>
>
>Any additional properties are defined by those other specifications, not
>WS-Addressing.
>
>  
>
>>*	Exactly how a future specification requiring endpoints 
>>beyond the presently defined reply and fault endpoints should 
>>define these 
>>    
>>
>
>A future specification can define things however they like. I don't
>understand how we can even constrain how people would write such specs (
>or why we would want to ).
>  
>
Can it?  Would such definition be compatible with ours?  Would there be 
any technical issues owing to the absence of, say, an [alternate reply 
endpoint] pre-defined in the MAPs?  So far I've seen only proof by 
assertion on this point.  I'll ask yet again for anyone who has made 
such an assertion to provide a worked through example upon which to comment.

>  
>
>>*	In particular whether such a specification would have 
>>to define a new SOAP module to hold properties parallel to 
>>those defined in the MAPs 
>>    
>>
>
>I don't see much value in *requiring* people to do such a thing, but I
>concede that approach is one way to write such a specification.
>  
>
I'll assert now that, from what I've learnt so far from trying the 
exercise, such an approach /is/ required by the core as it stands, and 
that having, say, reply and alternate reply properties in separate SOAP 
models appears needlessly complex.  At this point this is a best guess.  
Having a fully worked example from someone advocating the current 
extensibility approach would put us in a much better position to 
evaluate whether the core could or should be modified to make such 
extension easier.

>  
>
>>*	How the current definition of MAPs as mandatory 
>>properties would apply to existing SOAP/HTTP interactions 
>>which have no notion of such properties 
>>    
>>
>
>I take it by 'existing SOAP/HTTP interactions' you mean interactions
>that don't use WS-Addressing. Such interactions don't have any
>WS-Addressing defined message properties. The message properties only
>apply if you're actually using WS-Addressing, which in practical terms
>means you have at least one header in the WS-Addressing namespace in
>your messages.
>  
>
At the very least, then, we should make it clear when the description of 
MAPs does and does not apply.  This may be an editorial change, and the 
answer may well already be implied, but making it explicit would be helpful.

Among other things, this makes it clear that any talk of an 80% case is 
spurious.  We simply do not know what portion of future usage of WSA 
will need fault and/or reply endpoints, and what portion will use other 
patterns.  At this point, Notification/Eventing are well along, while 
async request/reply is still in its infancy, so we may as well say that 
Notification/Eventing is the 80% case.

>  
>
>>*	Whether existing specifications would need to be 
>>amended to mention MAPs and/or their corresponding headers in 
>>order to leverage the asynchronous request/reply pattern to 
>>which the MAPs are evidently tailored, as suggested by the 
>>explicit mention of ReplyTo and other headers in 
>>specifications such as WS-Transfer and WS-Enumeration 
>>    
>>
>
>I would think that such amendments are up to the authors of those specs.
>Why is it our concern in this WG?
>  
>
The concern is dependency (the next item after the one I quoted from the 
list describing Last Call).  WSA currently defines an extended 
request/reply interaction allowing for an asynchronous reply.  If a spec 
defining a request/reply operation needs to reference WSA explicitly in 
order to leverage this, then WSA introduces potential dependencies from 
anything that defines an request/reply operation.  If -- as I hope is 
the case -- such a spec need only say "this is a request/reply 
operation" and the option to be asynchronous is introduced in some 
adjunct to WSDL, then there is most likely no need for anything outside 
WSA, WSDL and possibly a small number of other specs to talk about reply 
endpoints and such at all.

At the very least, we need to understand in what way and why specs that 
currently reference WSA are doing so, and what the implications of this 
are going forward.  I've not yet seen any significant discussion of 
this.  We have no doubt that various members of the group have a clear 
picture of how WSA can fit together with other families of specs, and so 
are keen to push toward resolution.  However, this picture is not at all 
clear from the point of view of someone approaching WSA afresh.  Making 
such interrelations clear and explicit is a crucial part of making a 
standard useful and adoptable, and is doubtless a major driver behind 
the requirement that dependencies be addressed prior to Last Call.

We do not yet have any such clarity as to how WSA MAPs will fit into the 
larger picture and so cannot support going to LC.  By contrast, we are 
comfortable with EPRs in this respect.  As I've said, there are 
reasonably well-developed examples of EPR usage in WSN/WSE if not elsewhere.

At the very least, we need to confirm that everyone with a clear picture 
of how WSA fits with the rest of the world has the /same/ clear picture.

>  
>
>>*	What level of MAP extensibility is actually required by 
>>the WS-Addressing charter. 
>>    
>>
>
>It doesn't seem like the charter requires that the set of message
>properties be extensible, but it also doesn't preclude such extension.
>As I have stated before, I don't really see how a spec can make it self
>completely non-extensible, especially given the way SOAP works; any
>header can modify the behaviour of any other header. 
>
>Our current spec acknowledges that the set of properties it defines is
>not exhaustive. Anyone can write a spec to supply properties that they
>consider useful over and above those defined by WS-Addressing.
>  
>
So why define anything at all?  Why define [relationship] extensibly?

Such questions boil down to "what value is this definition adding?".  In 
the case of EPRs, there is a clear need for some notion of a callback 
address.  EPRs fill this and there is no clear significantly different 
alternative.  In the case of MAPs, there are various needs to provide 
for message correlation and destinations for messages produces as a 
result of a given message, but it's not clear whether this is best 
defined in the context of messages or in the context of message 
interactions.  The status quo is a bit of both, with no clear criteria 
for what goes where.

>Gudge
>
>  
>
>>Please consider this listing as a request to open these 
>>outstanding questions as formal issues.
>>
>>While we understand and indeed share the desire of the group 
>>to get to last call as quickly as reasonably possible, given 
>>the current state of the specification and the discussion 
>>around it, we regret to say that we cannot support the 
>>documents going to last call at this point, and so must object.
>>
>>
>>    
>>