W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

Re: Amended proposal for i059

From: David Hull <dmh@tibco.com>
Date: Mon, 19 Dec 2005 14:21:06 -0500
To: David Orchard <dorchard@bea.com>
Cc: public-ws-addressing@w3.org
Message-id: <43A70822.4010009@tibco.com>
David,

My concern with the reworded text, "/When the anonymous address is not
used, then any outbound message is part of a different MEP than the
inbound message/," is that it may be too restrictive.  There appear to
be a number of possibilities, notably holding the return message for a
later poll, that call in to question "just what is a MEP, anyway?"  In
such a case, I don't really care whether holding a message for a later
poll and the client later picking it (and possibly others) up in
response to a poll request constitutes a MEP, as implied by "part of a
different MEP".  All I care about is that it /didn't/ come back as the
transport-level response.

For similar reasons, I'm concerned about dictating (as opposed to
allowing) any particular kind of acknowledgment.  As I've said
elsewhere, I prefer "You have to send something back.  If you don't have
anything else to send, use an empty 202."  The 1.1 text still seems a
little restrictive in this regard (but we can fix that by making sure
that the scope is appropriately narrow).  The 1.2 text is  fine from
that point of view; saying the response is part of a separate MEP
doesn't constrain the transport-level response of the first MEP.

Otherwise, the text-tightening in general looks OK to me.

David Orchard wrote:

> Isn't this ironic.  I was just working on a rewrite that did much of
> the same.  The one thing that I had done, which I won't propose at
> this time, is that WS-A create a simple MEPs to be SOAP version
> agnostic, then map the simple MEPs to SOAP 1.1 or the appropriate SOAP
> 1.2 MEPs.  However, let's try to rally around this text..
>
>  
>
> I have a few amendments I'd suggest, mostly involving shortening up
> the wording a fair bit..  A significant technical change is removing
> the requirement for an empty soap envelope.  The presence of the
> wsaw:UsingAddressing element does not necessarily change the SOAP
> 1.1/HTTP binding, particularly if anonymous is used.  So I suggest
> saying nothing rather than specifying something that effectively means
> "keep it the way it was".  I've removed the discussion about the
> wsaw:UsingAddressing element to say just WS-Addressing changes it when
> anon is used.  If WS-A isn't engaged, then the text doesn't apply... 
> The soap 1.1 wording for inbound/outbound can also be collapsed to
> just "receiver of a message" to cover 2 one-ways and avoid confusion
> about whether the outbound message is recursively an inbound message. 
> There is an interesting proposal in XMLP land to make request-response
> equivalent to request-optional-response, so I've tried to take that
> into account by saying "part of a single MEP" rather than "MUST comply
> with ..." because DH's wording leaves that open to the question of 1
> or 2 MEPs.  I also changed the negative wording (MUST NOT) of the soap
> 1.2 anon not used to be +ve wording. 
>
>  
>
> I'm not sure what the heading #s should be as I'm not sure which
> document and where these bindings should appear, so I removed the #s. 
> This does feel like it has a real affinity for section 3.5 of the ws-a
> soap binding doc, a natural "3.6 Anonymous Address not used in SOAP". 
> It could also be in a separate WS-Addressing document.
>
>  
>
> I hope that moving from 11 lines of description to 5 helps progress
> things.  I think it would be hard to get to 4 or fewer lines :-)
>
>  
>
>  
>
> *SOAP 1.1/HTTP binding*
>
>  
>
> WS-Addressing changes the SOAP 1.1/HTTP binding when the anonymous
> address is not used.  In this case, the receiver of a message MUST
> respond with a 202 status code and an empty HTTP body, aka no SOAP
> envelope.  If a non-anonymous address is used, the outbound message
> MUST be sent using a separate connection using the address value of
> the specified by appropriate response endpoint
>
> * *
>
> *SOAP 1.2 binding*
>
> * *
>
> 1.      When the anonymous address is used, then the inbound and any
> outbound message are part of a single SOAP request-response MEP [soap
> 1.2 adjuncts ref]
>
> 2.      When the anonymous address is not used, then any outbound
> message is part of a different MEP than the inbound message.
>
> * *
>
> Old Text for easy reference
>
> *3.1.2.1 Extension to SOAP 1.1/HTTP binding*
>
>  
>
> The presence of the wsaw:UsingAddressing element in the binding or
> endpoint (port) components of the endpoint description extends the
> semantics of the SOAP 1.1/HTTP binding, by relaxing the requirement
> that the outbound message be sent over the same HTTP connection over
> which the inbound message was received.
>
> 1.      When the anonymous address is used, the outbound message MUST
> be sent over the same HTTP connection as the inbound message. 
>
> 2.      When the anonymous address is not used, the receipt of the
> inbound message MUST be acknowledged with a status message (202) by
> the receiver using the HTTP connection that generated the inbound
> message. The receipt message MUST contain an empty SOAP envelope. /
> (Lets discuss this further)/
>
> a.      If no response is sent, no further action is required
>
> b.      When a non-anonymous address is used, the outbound message
> MUST be sent using a separate connection using the address value of
> the specified by appropriate response endpoint.  If the connection is
> an HTTP connection, the outbound message must be acknowledged as above.
>
> * *
>
> *3.1.2.1 Behavior for SOAP 1.2*
>
> * *
>
> 3.      When the anonymous address is used, then the inbound and
> outbound messages together MUST comply with the SOAP request-response
> MEP defined in section 6.2 of the SOAP 1.2 adjuncts, as bound to the
> transport of the endpoint.
>
> 4.      When the anonymous address is not used, the sending of the
> outbound message, if any, MUST NOT be part of the same SOAP MEP as the
> receipt of the inbound message.
>
> * *
>
>  
>
> Cheers,
>
> Dave
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
> *Sent:* Friday, December 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 19:21:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT