Base proposal Part2: http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html (NM) Editorial Comments EC1) Type: Word tense Target: Table 7, current state = "receiving", the 2nd transition condition, Proposed text: s/send/sent Reference: MB http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0057.html, para 2 EC2) Type: Grammar Target: Table 7 Issue: If an envelope is provided in abstracted in http://www.w3.org/2003/05/soap/mep/OutboundMessage [...]". Proposed text: none Ref: MB. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0057.html, para 3. EC3) Type: New clarifying text Target: 6.2.2 Description. Para 2 Proposed text: From: 'In the normal operation of a message exchange conforming to the Request-Response MEP, a request message is ..' To (1): 'In the normal operation of a message exchange conforming to the SOAP Request-Response MEP, a request message, containing a SOAP envelope, is ...' To (2): "In the normal operation of a message exchange conforming to the Request-Response MEP, a request message is first transferred from the requesting node to the responding node. Following the successful processing of the request message by the responding node, a response message may be transferred from the responding node to the requesting node. ' Refs: (1) CF. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0062.html starting with 'In the normal operation ..' (2) DO. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0092.html (2nd use of >DBO>) EC4) Type, Clarifying text Target: Table 19 Issue: Single out our exception better, cause otherwise our text collides with fault cases Proposed text: From: 'Only if status line is 200, the SOAP message...' To: (1) 'Unless the status line is 202, the SOAP message ... ' To: (2) The response message, if any, may contain a SOAP envelope. If so, it will be serialized according to the rules for carrying SOAP messages in the media type given in the Content-Type header field." Refs: (1) CF http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0062.html (last issue raised) (2) DO. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0092.html (last use of >DBO>) Substantial Comments SC1) Type: Clarifying Semantics. Issue: If we are using 202 as indicated in Table17, there should be clarification on the semantic: that any SOAP envelope would not represent the results of processing the inbound SOAP message. It only indicates an intermediate result, like an ack. Target: Table 17 for status code 202 row Proposed text: From: "The request has been accepted, but no response envelope is provided. Any further application processing is beyond the scope of this use of the 6.2 SOAP Request-Response Message Exchange Pattern***." To: "The request has been accepted, and any information that might be present in the response message, possibly including a SOAP envelope, does not represent the results of processing the request message. Any further application processing is beyond the scope of this use of the 6.2 SOAP Request-Response Message Exchange Pattern***." Ref: MB. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0057.html, para 4) SC2) Type: Clarifying Semantics. Target: 6.2.2 Issue: Removing claim that response message indicates anything (such as an ack as described in SC2). Proposed text: From: 'The response message MAY contain a SOAP envelope, or else the response MUST be a binding-specific message indicating that the request has been received.' To(1): 'The response message is a binding-specific response that MAY contain a SOAP envelope.' To(2): The SOAP Request-Response MEP defines a pattern for the exchange of a message acting as a request optionally followed by a message acting as a response. The messages may or may not carry SOAP envelopes. In the absence of failure in the underlying protocol, this MEP consists of one request message and one optional response message:" Refs: (1) CF. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0062.html, para 1&2, his 1st issue) (2) DO. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0092.html, 1st use of >DBO>) SC3) Type: Possible semantic conflict - OutboundMessage Target: Table 7 in the Transition column on the "Receiving" row and following in the Action column Issue: Does/can OutboundMessage semantics handle the 202/204 case? For compatibility, for an HTTP 202 Accepted response something needs to tell the binding that the message was accepted. I would have thought that that would constitute "other information structures", but maybe not? Does this mean that there's a missing property? Something that indicates to the binding layer the disposition of the received message? Continuing with Action: ***Initiate transmission of response message. If an envelope is provided in abstracted in http://www.w3.org/2003/05/soap/mep/OutboundMessage then include that in the response message. The part that says: "if an envelope is provided in abstracted..." seems to imply that the envelope is optional in the OutboundMessage (in the context of the responding SOAP node), which seems to suggest as I did above, that the disposition is actually a part of the abstraction of OutboundMessage. I think that it will be important that we make this clear and consistent. I personally think that in all cases, there is an OutboundMessage. It may, or may not as the case may be, contain a SOAP envelope. Proposed text: (1) Thus, I think that we could leave the transition column above as: Start of response envelope available in http://www.w3.org/2003/05/soap/mep/OutboundMessage (2) >DBO> I would think that setting a "null" for the response envelope in the OutboundMessage does this. I have purposefully underspecified this. Regarding Action - prefer Noah's formulation. I don't think that a null envelope is a response envelope. It's a response that is in the OutboundMessage but it's not an envelope. Refs:. (1) CF. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0062.html, his 2nd issue - starting with 'In Table 7...' then continuing with 'Similarly, in the Action column...' (2) DO. http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0092.html (3rd & 4th use of >DBO>)