Below is my summary of the binding thread. I skipped parts that were in my opinion not directly related to the problem. Note that the summary is mine and is therefore the result of the interpretation of what the author said. Please send comments to xml-dist-app@w3.org.
The complete thread can be found in xml-dist-app's July archive.
Below is a list of questions that were asked:
From: Mark Jones <jones@research.att.com> Date: Fri, 29 Jun 2001 14:57:37 -0400 (EDT) Subject: infoset and bindings Message-Id: <200106291857.OAA13879@glad.research.att.com>
A message should be abstractly viewed as an infoset comprising ALL of the relevant information to be carried along the wire. The role of a binding is to determine how to convey that information to the next hop.
In practice, a binding is selected to transmit the required parts of the message to the next node. The binding specifies an underlying transfer/transport protocol, (optionally) content-carrying formats (e.g., for attachments), and the XML envelope.
From: "Williams, Stuart" <skw@hplb.hpl.hp.com> Date: Tue, 3 Jul 2001 15:25:36 +0100 Subject: Protocol Binding Message-ID: <5E13A1874524D411A876006008CD059F19250A@0-mail-1.hpl.hp.com>
Provide rules for the transfer of XML Protocol messages over some specific underlying protocol.
Two views:
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Date: Wed, 4 Jul 2001 18:53:34 -0700 Subject: RE: Protocol Bindings Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDAA@red-msg-07.redmond.corp.microsoft.com>
Purpose: define how to stick a SOAP message in an underlying protocol.
From: "Mark Nottingham" <mnot@mnot.net> Date: Thu, 5 Jul 2001 06:04:38 -0800 Subject: Re: Protocol Bindings Message-ID: <065901c1055b$8ad32220$8401a8c0@mnotlaptop>
A binding provides a means of encapsulating a SOAP message, with the following guarantees:
Binding definitions must describe restrictions they impose upon the SOAP layer, if any. Bindings might provide additional services.
From: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com> Date: Thu, 5 Jul 2001 11:06:43 +0100 Subject: RE: Protocol Bindings Message-ID: <NCBBIFBIECFPOABMKKBDAEBDDPAA.eamon.otuathail@clipcode.com>
Transport binding = envelope encapsulation + transfer over an application protocol (needs framing).
From: christopher ferris <chris.ferris@east.sun.com> Date: Wed, 11 Jul 2001 17:56:03 -0400 Subject: Re: Protocol Bindings Message-ID: <3B4CCB73.93722CC0@east.sun.com>
Binding software can be considered as an intermediary and hence modify the message.
Correlation, sequencing, etc; all extra-mechanisms provided by an underlying protocol must appear in the envelope.
From: Mark Nottingham <mnot@mnot.net> Date: Thu, 12 Jul 2001 10:15:57 -0700 Subject: Re: Protocol Bindings Message-ID: <20010712101553.A1810@mnot.net>
From the SOAP message's point of view, encapsulation and transport binding are the same: it is something which is underneath it. Bindings are only charged with layering SOAP into another format; not with mapping that format's semantics into the envelope.
It will be difficult (if not impossible) to represent as a module the semantics of a feature provided differently by many protocols.
From: "Williams, Stuart" <skw@hplb.hpl.hp.com> Date: Thu, 5 Jul 2001 12:15:38 +0100 Subject: RE: Protocol Bindings Message-ID: <5E13A1874524D411A876006008CD059F192510@0-mail-1.hpl.hp.com>
"The purpose of an XML Protocol Binding is to describe how to *make use of* the communication services of particular underlying protocol to transfer an XML protocol message."
Describing how to stick messages into the underlying protocol is not enough: also needs to describe how the actions of sending and receiving a SOAP message are mapped on to the operations/services of the underlying protocol.
From: Yves Lafon <ylafon@w3.org> Date: Thu, 12 Jul 2001 19:28:44 +0200 (MET DST) Subject: RE: Protocol Bindings Message-ID: <Pine.GSO.4.33.0107121905570.20090-100000@tarantula.inria.fr>
S810 says that information in the XMLP message helps choosing the transport adequatly.
From: "Williams, Stuart" <skw@hplb.hpl.hp.com> Date: Thu, 5 Jul 2001 12:48:45 +0100 Subject: RE: Protocol Bindings Message-ID: <5E13A1874524D411A876006008CD059F192511@0-mail-1.hpl.hp.com>
The SOAP/XMLP application should not have to be aware of the capabilities of what it is underneath: need to provide a clear and consistent messaging abstraction.
Separation between development and deployment is important: development of SOAP applications, not SOAP+HTTP or SOAP+BEEP applications.
From: "Mark Nottingham" <mnot@mnot.net> Date: Thu, 5 Jul 2001 18:50:39 -0800 Subject: Re: Protocol Bindings Message-ID: <087801c105c6$70882a80$8401a8c0@mnotlaptop>
Enabling the use of any protocol regardless of its capabilities at the core level would involve abstracting out a taxonomy of the services provided by whatever protocols we wish to support and then providing modules for all of those services to make them available when run across a protocol that doesn't provide them.
Applications will be designed to take advantage of the most appropriate transport, and specify which binding is in use.
From: Noah_Mendelsohn@lotus.com Date: Thu, 5 Jul 2001 13:05:39 -0400 Subject: Re: Protocol Bindings Message-ID: <OF179D32AA.A71C1F9F-ON85256A80.005D2CB5@lotus.com>
The message patterns supported over a given (binding to) a transport should not be limited to those obviously inherent in the transport.
Message patterns should be named, and should each have precise specifications.
Our spec should provide one way and request response, with users able to create names and specifications for their own patterns such as conversation, multicast, etc.
Bindings should advertise the set of named message patterns they support, and should be free to choose to support patterns that do or don't naturally reflect and exploit the underlying characteristics of the transport vs. augmenting it.
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Date: Thu, 5 Jul 2001 11:08:14 -0700 Subject: RE: Protocol Bindings Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDB8@red-msg-07.redmond.corp.microsoft.com>
It is not the purpose of a SOAP binding to hide differences between underlying protocols.
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Date: Thu, 5 Jul 2001 12:04:51 -0700 Subject: RE: Protocol Bindings Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDB9@red-msg-07.redmond.corp.microsoft.com>
Use of different underlying protocols because they provide different levels of functionality.
If extra functionality is needed, can be done: as part of an underlying protocol or as a SOAP extension.
Advertisement of underlying protocols' services has to be done out-of-done (service description, spec, etc).
Message description and message exchange pattern descriptions are important but neither seem to be within scope of what the core SOAP specification is supposed to do according to our charter.
From: "Eamon O'Tuathail" <eamon.otuathail@clipcode.com> Date: Fri, 6 Jul 2001 14:58:30 +0100 Subject: RE: Protocol Bindings Message-ID: <NCBBIFBIECFPOABMKKBDEEENDPAA.eamon.otuathail@clipcode.com>
Layering is important/obvious: the binding is the boundary between the application protocol and the messaging protocol.
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Date: Fri, 6 Jul 2001 08:24:21 -0700 Subject: RE: Protocol Bindings Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDC9@red-msg-07.redmond.corp.microsoft.com>
SOAP doesn't have any notion of what the endpoint is: SOAP cannot define the transfer of the messages. No semantics should be defined by the binding.
From: "Jean-Jacques Moreau" <moreau@crf.canon.fr> Date: Wed, 11 Jul 2001 10:26:50 +0200 Subject: Re: Protocol Bindings Message-ID: <3B4C0DCA.B7DD9D57@crf.canon.fr>
Should we produce something in the spirit of Mapping the BEEP Core onto TCP (RFC3081).
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Date: Sun, 8 Jul 2001 13:59:09 -0700 Subject: RE: Protocol Bindings Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDD8@red-msg-07.redmond.corp.microsoft.com>
SOAP is not merely a content type, it is an application layer protocol. SOAP can be bound to various underlying protocols including some other application layer protocols in order to extend those applications. However, there is no functionality that these applications provide that is inherently required by SOAP.
From: "Williams, Stuart" <skw@hplb.hpl.hp.com> Date: Mon, 9 Jul 2001 16:03:34 +0100 Subject: RE: Protocol Bindings Message-ID: <5E13A1874524D411A876006008CD059F192529@0-mail-1.hpl.hp.com>
Bindings can alter the message delivery semantics performed by the SOAP core (e.g. a nestable reordering binding on top of UDP) by taking care of operations which need to happen before processing.
From: "Williams, Stuart" <skw@hplb.hpl.hp.com> Date: Wed, 11 Jul 2001 13:21:59 +0100 Subject: RE: Protocol Bindings Message-ID: <5E13A1874524D411A876006008CD059F19253E@0-mail-1.hpl.hp.com>
We should write something in the spirit of section 2.5 of the BEEP core specification.
From: "Williams, Stuart" <skw@hplb.hpl.hp.com> Date: Thu, 12 Jul 2001 12:41:59 +0100 Subject: RE: Protocol Bindings Message-ID: <5E13A1874524D411A876006008CD059F192548@0-mail-1.hpl.hp.com>
Is a binding allowed to insert/remove things in the SOAP envelope?