- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 16 Jan 2002 17:56:48 -0000
- To: "'Marc Hadley'" <marc.hadley@sun.com>
- Cc: xml-dist-app@w3.org
Marc et al., I would also note the ednote ahead of the table in 8.4.1.1.2 (!)... <quote> Editorial note: JJM/SKW 20011205 This is a large table and it would be good shrink it somewhat. It does not cover all generally possible HTTP status codes and may cover more than it should. This is one that we should be able to address provided the direction and style are to peoples taste. /quote> From my POV as one of the contributors to this part of the spec, the content of that table is at least in part tentative. It provides a framework where we can give account of any SOAP'ish significance that may be attributed to the receipt of particular HTTP status codes. 204 No-content is a good example... do we ever expect it to happen and what should it mean if it does? Would we regard as request/response as having succeeded or failed in such circumstances? To we regard it as a 'null' response (ie... from the MEP POV it was a response, with no value as opposed to no response) and leave the 'application' to decide from it's POV (without having to know about 204 from HTTP or xxx from protocol yyy). Personally, I think that these are some of the corner cases that this style of documenting the binding forces us to visit - the answers in the boxes may not yet be the right ones. On Marc's original point I would take the view that the binding we have defined in the current WD does not support a one-way message exchange pattern. It always does request response as currently defined - or fails. However, it is has been written to be 'tolerant' of empty responses, but you are welcome to regard me as dancing on the head of a pin :-) For me the essential difference is that for a one-way MEP the binding would know a-priori that that MEP was in use and that no-response would be forthcoming. It would likely be denoted differently on the 'wire'. You ought to able to tell without having to know the semantics of message content being exchanged. Regards Stuart > -----Original Message----- > From: Marc Hadley [mailto:marc.hadley@sun.com] > Sent: 16 January 2002 14:38 > To: xml-dist-app@w3.org > Cc: xml-dist-app-request@w3.org > Subject: Re: One-way messaging in SOAP 1.2 > > > My issue is not so much whether "the SOAP spec supports one-way > messages", but whether we are in fact mandating support in > every binding > for a one way MEP that we don't formally define. > > I agree that the HTTP binding can be used to support a one-way MEP, I > just don't think that we define this very well in the current > text. E.g. > section 8.3 states that it supports single request-response, nothing > more; the detail about HTTP response codes 202 and 204 is in "8.4.1 > Single Request-Response Exchanges". > > In general, I don't think the layering is as clear as it might be - > probably because the only instance we have at the moment is a request > response MEP over a request response transport. > > Regards, > Marc. > > John Ibbotson wrote: > > > This issue is an example of how things get blurred at > different levels in a > > stack, We are considering the contents of a SOAP Envelope, not the > > transport that moves the message from one point to another. As Jack > > suggests, a SOAP message can be sent as the contents of an > HTTP request, At > > the transport layer, a 200 response comes back with empty > content. Tha > > response is simply an artifact of the HTTP protocol design. > If I use an > > asynchronous transport (I know some folks may not view it > as a transport) > > such as MQSeries, then I simply PUT a message to a queue and it gets > > delivered. to the destination. There is no request/response > visible at the > > application layer. > > > > I am happy that the SOAP spec supports one-way messages in > that there is no > > mandatory response at the SOAP layer from the ultimate > destination. If you > > think some clarification of this is needed then I support that. This > > clarification must emphasise the SOAP layer and not complicate it by > > transport artifacts. > > John > > > > XML Technology and Messaging, > > IBM UK Ltd, Hursley Park, > > Winchester, SO21 2JN > > > > Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271 > > Fax: +44 (0)1962 816898 > > Notes Id: John Ibbotson/UK/IBM > > email: john_ibbotson@uk.ibm.com > > > > > > > > > > > Marc Hadley > > > <marc.hadley@sun. To: XML > dist app <xml-dist-app@w3c.org> > > com> cc: > > > Sent by: Subject: > One-way messaging in SOAP 1.2 > > xml-dist-app-requ > > > est@w3.org > > > > > > > > > 01/16/2002 11:18 > > > AM > > > > > > > > > > > > > > > > > All, > > > > I'd like to raise a new issue: > > > > In Part 1, section 5.3 we find: > > > > "Every binding specification MUST support the transmission and > > processing of one-way messages as described in this specification. A > > binding specification MAY state that it supports additional > features, in > > which case the binding specification MUST provide for > maintaining state, > > performing processing, and transmitting information in a manner > > consistent with the specification for those features." > > > > This paragraph is potentially confusing, either we mean: > > > > (i) All bindings must support a one-way MEP, in which case > there are two > > issues: > > (a) we currently don't define a one way MEP in the specification > > (b) the HTTP binding we do define doesn't support a one-way MEP > > > > or (my reading) > > > > (ii) All bindings must at a minimum define how to move a > message from > > one node to another, in which case I would propose that we add a > > clarification along the lines of "Note, this does not mean that all > > bindings must support a one way MEP, only that they MUST > define how to > > move a message from one SOAP node to another". > > > > Comments ? > > > > Regards, > > Marc. > > > > > > > > > > > > > > > > -- > Marc Hadley <marc.hadley@sun.com> > XML Technology Centre, Sun Microsystems. > >
Received on Wednesday, 16 January 2002 12:57:29 UTC