The Default Binding of SOAP onto HTTP submitted by Chris Ferris was discussed. 1) URI as id - good idea 2) Message flow description defined as one way or request response. Comment - How does this impact RPC communication, what about non-RPC calls? Binding vs. Message exchange pattern; is a binding just how you place SOAP content in an HTTP message? 3) General concern regarding Upper Case Requirements SOAP and Bound Protocol should be treated separately (ex - error code/SOAP Fault communication) Generally speaking a 500 error scenario was described where the HTTP code was a level above a SOAP fault. The HTTP 500 code could be used as a hint to look further in an enclosed SOAP Block. This block would include further information regarding a SOAP fault. ISSUE. Do we or don't we need a consistent/detailed processing model for SOAP/HTTP ? HTTP's protocol binding will be different than a binding to TCP or SMTP? HTTP is at the Application level. Will error codes - SOAP faults - be processed automatically (machine readable) or manually (human readable)? David Fallside - Code 500 could happen due to a number of different things. ? A robot will have to open the message to determine next action. Henrik - Another status code, 4xx - representing a SOAP processing fault, could be registered, thus modifying HTTP. David Fallside disagrees. 409 exist and may potentially be the correct code for SOAP faults. David Fallside - We need priority feedback from SOAP builders and public at large. Highland - Use cases are needed to run through possible scenarios to determine best course of action across protocol bindings. Apache implementations use 200 as a fault in current implementation. Henrik - IETF has strong feelings regarding http usage. SOAP is going beyond this. SOAP over HTTP actually augments HTTP to allow additional parameters that HTTP can't transport. HTTP and SOAP can be "friends" in a sense that they operate in the same mode. Keith Moore has a draft on the correct usage of 500 status codes. IETF needs to be brought into this discussion. There are 2 distinct approaches to bindings being discussed, one being an extensive approach and the other a tightly coupled approach. The group needs to reconcile these approaches. (Examples are the 2 SOAP/HTTP Bindings from Chris Ferris and Mark Nottingham) Chris's work takes the approach that http is independent from SOAP. HTTP codes are guidelines, shalls not musts. Rely on SOAP fault information. Chris's comments. Implementers will need to know what to expect from any arbitrary server. Hugo - Anything besides 200 code and we are getting away from the semantics of HTTP. Implementers should expect a SOAP message on any HTTP message, but the enclosed message could be open to interpretation. General comment - Our specification should assume that the reader has read and understood the associated protocol spec to be bound. Highland - This is a dangerous assumption. Could cause interoperability down the road. Hugo - Our group or resulting spec cannot prevent people from doing the wrong thing. Chris Ferris - Should the spec contain info on what needs to be done vs. an open app framework protocol binding. David - Wording in charter states that we will describe a mandated way to use SOAP, which is preferred but not normative. - Other people may come up with other bindings not stated in the spec. Our group's requirement is to come up with a normative binding not exclusive. We give direction to shepherd implementers along, Henrik - Proposal for TF's next step - HTTP binding is a "funny" binding - What if we create a general binding description by picking 2 other binding and focus on those. These other 2 bindings are TCP and SMTP, since binding proposals exist. TCP is a bit more complicated. We need another call to continue this discussion. Tentatively scheduled for Monday, July 23.
Hugo and David - Set up next Telecon. Completed
Highland - Resend SOAP/SMTP Binding Proposal in HTML format. Completed