XMLP Working Group Transport Binding Task Force Teleconference: 19 July
2001, 7.30-8.30a PDT



Attendance:

Mark Jones

Henrik Frystyk Nielsen

Oisin Hurley

Highland Mary Mountain

Glen Daniel

David Fallside

Marc Hadley

Mark Nottingham

Chris Ferris

Hugo Haas

Yves Lafon



 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.



Action Items:



Hugo and David - Set up next Telecon. Completed

Highland - Resend SOAP/SMTP Binding Proposal in HTML format. Completed