Re: Amended proposal for i059

Yalcinalp, Umit wrote:

> David,
>  
> We need to approach this from the perspective of problem solving.

I'll bear that in mind.

> You seem to be changing the doc so that SOAP 1.1 and SOAP 1.2 have
> equal footing.

I don't that I'd put it that way.  Certainly the text falls out
differently for 1.1 and 1.2.  What I had meant to do was to pull out
text that applies to /any/ version of SOAP(or possibly beyond the
context of SOAP; see below) and state it once instead of repeating it. 
The full structure is:

   1. What are the rules for the WSDL markup (UsingAddressing,
      Anonymous)?  This clearly has to go in the WSDL binding.  The WSDL
      markup defines (among other things) when the anonymous endpoint is
      allowed to occur in a response endpoint.  This is section 3.1, and
      3.1.1, which I think is basically OK, modulo the changes regarding
      response endpoints, which we seem to agree on.
   2. What does the anonymous endpoint mean in general?  If this goes
      beyond the scope of SOAP messages (e.g., SOAP request, binary
      response, etc.), then this can't go in the SOAP binding.  This
      would be the ideal place to set out the key idea of having
      anonymous tie the inbound and outbound messages to a request
      response /MEP/, instead of trying to define a "response channel"
      and just tie the individual outbound message to it.  Though a
      purely technical point, it looks to make the definitions
      considerably shorter and clearer.  Unfortunately, the only places
      I know of where "request-response" is defined concretely
      concretely are in HTTP and in the SOAP adjuncts.  This is where
      introducing a transport-level MEP, independent of SOAP, could come
      in handy (if anyone would like to advocate this, please jump in :-)
   3. What does the anonymous endpoint mean in the context of SOAP, in
      general?  If we can say anything in general about SOAP, but not
      beyond SOAP, it would go here.  My feeling is that we probably
      don't need anything in this slot, though right now it currently
      holds the material that would ideally go in slot 2  (section 3.1.2
      in what I sent out).  I agree that this and what follows is
      somewhat redundant with the definition of anonymous in the SOAP
      binding.  Leaving potential process issues aside, I lean toward
      taking the section (3.5) out of the SOAP binding.  I don't believe
      it's concrete enough to be useful on its own.  To make it concrete
      enough to use, you have to talk about binding MEPs, and that's not
      only necessary, but sufficient.
   4. What does anonymous mean for SOAP 1.1/HTTP and SOAP 1.2?  I
      believe what I put in 3.1.2.x is what belongs there.

>  
> (a) I like that you are more inclusive about response endpoints and
> they should be extended to other response endpoints, to cover acks to
> help other specifications. This is aligned with the CR issue we result
> wrt the definition of anonymous in the SOAP binding.
>  
> (b) I do not follow why we need yet another definition of anonymous
> address here in Section 3.1.2. We already have the definition which we
> tinkered with in the SOAP binding document. I really can not follow
> what it adds in the WSDL document as stated.

See above.

>  
> The last paragraph of this section, however, is in the right direction.
>  
> (c) You changed the slant by adding Section 3.1.2.1 which de-couples
> of the usage of the "Anonymous" marker and coupling it with the usage
> of "anonymous" on the wire.
>  
> I think first the wg has to decide whether the semantics of the
> binding is with the extension and whether it is coupled with the WSDL
> document as an extension or it is defined in the SOAP binding.
>  
> This change presupposes that we actually move this section to the SOAP
> binding document. If we were to do this, the writeup would make more
> sense  as it talks about the behaviour from the perspective of the
> presence of the anonymous addresses on the wire (to be added to SOAP
> binding document) and then relating the semantics of the markup
> <Anonymous> to constrain the behaviour (in WSDL binding document),
>  
> For example:
>  
> {When the anonymous address is used, the outbound message MUST be sent
> over the same HTTP connection as the inbound message}.
>  
> What does this usage apply to? What happens if the Anonymous marker
> was "prohibited" in WSDL?

This is an error condition.  A compliant processor that advertises
Anonymous "prohibited" will not send an application-level message
anonymously.  Stepping back a bit, there is a clean split between
whether an anonymous endpoint is used, which depends both on the WSDL
markup and the behavior of the sender, and what it means /if/ it is
used.  There's no need to talk about the markup in the context of the
behavior.

There /is /a separate issue of how we model the handling of the SOAP
fault that MUST be generated.  We'll have to deal both with SOAP's
generate/send distinction and probably WSDL's notion of "fault replaces
message" and "message triggers fault".  I think any problems in both
cases are basically to do with terminology.  However, dealing with this
has little to do with the Anonymous marker per se.  A "anonymous
prohibited" fault must be handled in the same way as a mustUnderstand
fault, or any other fault that occurs before WSA is engaged.

>  
> I really think that we should first answer the where the SOAP binding
> extension goes before we go there...
>  
>  
> Thanks,
>  
> --umit
>  
>  
>  
>  
>  
>
>     ------------------------------------------------------------------------
>     *From:* public-ws-addressing-request@w3.org
>     [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
>     *Sent:* Friday, Dec 16, 2005 2:23 PM
>     *To:* public-ws-addressing@w3.org
>     *Subject:* Amended proposal for i059
>
>     In line with the discussion on Monday's call and the email I just
>     sent out, here is an amended version of the proposal for
>     UsingAddressing.  My additions and changes are shown in green. 
>     Deleted text has been quietly omitted.  Points of interest:
>
>         * I have substituted "response endpoint" for [reply endpoint]
>           and wsa:replyTo, and defined "response endpoint" as "[reply
>           endpoint] or [fault endpoint] as the case may be".
>         * I have tried to consistently use "inbound message" for
>           "request" and "outbound message" for response, in line with
>           WSDL use of "in" and "out" and in contrast to "request" and
>           "response" in the SOAP and HTTP context.
>         * In combining my proposal with the existing proposal, I
>           noticed that much of the text in each was actually
>           independent of which version of SOAP is in use.  I have
>           combined these and boiled them down a bit, shortening both
>           in the process.
>         * I completely removed the text about anonymous being
>           "required" etc. from the SOAP section.  I believe this is in
>           line with Marc's comment about repeated text.  The first
>           section discusses /when/ the anonymous URI can appear, the
>           following sections discuss what that means, and as far as I
>           can tell the two are independent.
>         * All this notwithstanding, the core of the original proposal
>           for SOAP1.1/HTTP is basically intact.  In generally, I
>           believe this latest version has essentially the same
>           semantics as the previous one, but is briefer, (hopefully)
>           clearer, and applicable to both SOAP 1.1 and SOAP 1.2
>
>     As always, comments are welcome.
>

Received on Monday, 19 December 2005 16:49:18 UTC