Re: CR20 proposal (consistent wording)

I meant to propose that my text go in Section 3.5 right before 3.5.1, as
Jonathan suggests.


As for the SOAP 1.2 and its abstract features, the problem we have now is
that the transport (HTTP) lacks the concept of anonymous destination for a
request message. This is is not going to change because SOAP 1.2 defined
set of abstract concepts. Let's just be clear about it and be done with
this issue (and CR18 as well).


Paco



                                                                                                                                  
                      David Hull                                                                                                  
                      <dmh@tibco.com>          To:       Jonathan Marsh <jmarsh@microsoft.com>                                    
                                               cc:       Francisco Curbera/Watson/IBM@IBMUS, public-ws-addressing@w3.org,         
                      02/13/2006 02:38          public-ws-addressing-request@w3.org                                               
                      PM                       Subject:  Re: CR20 proposal (consistent wording)                                   
                                                                                                                                  




Jonathan Marsh wrote:
      Dave,

      Perhaps it’s just me, but the sense of what we’re trying to say gets
      lost by the time you’re crafted it into a proposal.

      3.5.1 looks accurate, but starts the reader on a treasure hunt
      instead of directly giving them the answer to this question.  3.5.2
      seems to apply restrictions to SOAP request-response beyond the
      desired definition of the HTTP binding.

      I prefer Paco’s formulation – directly state that for HTTP, anonymous
      means no more and no less than the HTTP response.  I’d put his
      proposed text directly into the (currently empty) 3.5.  And declare
      victory.


In that case, strike "and no less", which is just a new complication.  That
leaves the semantics unchanged, and we can declare victory without firing a
shot.  I would much rather declare victory this way.

Special-casing HTTP for SOAP 1.2 is only victory if you abandon the idea
that features and properties can apply across protocols.


      From: public-ws-addressing-request@w3.org [
      mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
      Sent: Sunday, February 12, 2006 10:08 PM
      To: Francisco Curbera
      Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
      Subject: Re: CR20 proposal (consistent wording)

      Francisco Curbera wrote:
      As I said in my earlier mail, this would be the text to include in
      section
      3.5:

      "When the HTTP transport is in use, the anonymous URI is only used to
      indicate the use of the HTTP reply channel so it can only appear as
      the
      value of the [destination] property in reply messages."

      To be more concrete (insertions in italics):
      3.5 Use of Anonymous Address in SOAP

      3.5.1 SOAP 1.1/HTTP

      When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified
      for the response endpoint then there is no change to the SOAP 1.1/
      HTTP binding. The URI
      "http://www.w3.org/@@@@/@@/addressing/anonymous" MUST NOT be
      specified
      for the [destination] property of an HTTP message, except when
      required
      as a result of the rules in section 3.4 of the core.

      3.5.2 SOAP 1.2

      When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified
      for the response endpoint and the request is the request part of a
      SOAP request-response MEP [soap 1.2 adjuncts ref], then any response
      MUST be the response part of the same SOAP request-response MEP [soap
      1.2 adjuncts ref].  The URI
      "http://www.w3.org/@@@@/@@/addressing/anonymous" MUST NOT be
      specified
      for the [destination] property of any message in a SOAP
      request-response
      MEP, except when required as a result of the rules in section 3.4 of
      the core.
      This could be sharpened by saying the server/receiver MUST fault on
      receiving a message with such a [destination], instead of saying that
      such a [destination] MUST NOT be used but not saying what happens if
      it is.


      Paco



                            David Hull
                            <dmh@tibco.com>                 To:
      Francisco Curbera/Watson/IBM@IBMUS
                            Sent by:                        cc:
      public-ws-addressing@w3.org
                            public-ws-addressing-req        Subject:  Re:
      CR20 proposal
                            uest@w3.org
                            02/12/2006 02:22 PM





      Francisco Curbera wrote:


            As per Bob's request, and for easier reference, this is a more
            detailed
            version of the proposal for closing CR20 that we discussed on
            the last
            call:

            Middle of the road approach: retain the defaulting of the To
            header to
            anonymous, but re-state (in section 3.2 of the Core spec) that
            the use of
            the anonymous URI in the destination field is actually
            dependent on the
            interpretation that the transport binding gives to the
            anonymous URI. Add

      a

            note in Section 3.5 of the SOAP spec indicating that for the
            case of the
            HTTP transport the anonymous URI is only used to indicate the
            use of the
            HTTP reply channel so it can only be used in reply messages.



      Could you please state this in the form of an amendment to the text
      accepted for section 3.5 in the resolution to CR 15 [1]?  While this
      text has not yet been incorporated into the editors' draft yet, I
      believe it represents the latest draft of that section.

      [1]
      http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0085



            Paco

Received on Monday, 13 February 2006 20:59:12 UTC