issues related to bindings

All,

Since I volunteered... ;-)

I've trolled through the issues list and have pulled out
the relevant issues for transport bindings. I've listed each
with its description.

I've also copied out the glossary description of XMLP binding
from the Requirements document.

In addition, I've pulled the related requirements together
just so that they are all freshly imprinted on our
minds.

Cheers,

Chris

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x4
Lack of clarity and design choices in SOAP's HTTP protocol binding.

[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x11
[3] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x12
[4] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x13
Lack of clarity and design choice in SOAP protocol binding to HTTP, 
for example, use of port 80, HTTP status codes, and use of
MUST/SHOULD/MAY 
is inconsistent.

[5] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x22
There is nothing that says what to do in the HTTP protcol binding 
if there is a SOAPAction header field but no SOAP in the HTTP 
request entity body

[6] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x41
[RPC1] The target (program, service or object) URI (TBD) is not
mentioned 
in any normative way in the SOAP envelope. While this does not conflict 
with the requirements, I believe it's an important (and possibly
debatable) 
decision. This decision precludes sending an RPC invocation through an
intermediary that uses different protocol bindings for sending and 
receiving XP messages.

[7] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x44
correlation when not supported in binding

[8] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x50
The SOAP 1.1 specification defines a binding to HTTP only. 
Therefore it only partially supports requirement R501.

[9] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x56
R600 SOAP 1.1 has an implicit dependency on a synchronous
request/response 
transport protocol to achieve correlation. It has a further implicit 
dependency on SOAP processor endpoint information being transport
protocol 
endpoint information.

[10] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x57
R604 usage scenario over multiple transports

[11] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x58
R608 Not specifically addressed by SOAP 1.1, although limited 
extension facilities may be used to help achieve this goal.

[12] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x60
R612 A binding to a synchronous request/response protocol is 
implicit in the SOAP 1.1 specification, so a normative binding 
to HTTP is not addressed.

[13] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x67
SOAP 1.1 provides a fault entity, but also has an implicit dependence 
on HTTP for delivery, so it partially satisfies this requirement. 
Again, it is in a fairly unsophisticated manner as the
faultcode semantics are limited.

[14] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x69
R803 The relationship between the transport binding and message 
is implied in " Using SOAP in HTTP " SOAP doesn't have a firm 
conception of a protocol binding or the requirments placed upon 
it - HTTP is assumed.

[15] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x72
SOAP provides error and status reporting through SOAP Faults The
'faultactor'
subelement satisfies this requirement. See notes in R806 regarding the
value 
of this element. Also, it should be noted that the mechanism for
communicating 
a SOAP Fault is necessarily transport binding-dependent.

[16] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x95
Use of the SOAPAction Header field. There has been several discussion
on the lists regarding the use of SOAPAction header field. This issue 
is to ensure that we clarify the use of this header field in the spec

[17] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x103
Precisely describe message path semantics

[18] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x104
Use Infoset to define messages?

[19] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x105
Clarify message patterns (e.g. Request/Response)

[20] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x109
The specification preserves the HTTP Extension Framework binding 
although it is an experimental specification of the IETF with no
standing. 
I'd like to see this binding removed as I believe that
it has the potential for creating interoperability problems. 

Glossary definition:

XMLP binding 
	The formal set of rules for carrying an XMLP message within or 
	on top of another protocol for the purpose of transmission. Typical 
        XMLP bindings include carrying an XMLP message within an HTTP
message, 
	or on top of TCP.

Related requirements:

R300
	The requirements that XMLP support the use of layering and be modular, 
	extensible, and transport independent imply that there is an 
	architectural design model behind XMLP. This architecture and 
	the extensibility framework must be explicitly defined (R308 
	references modularity, R302 and R700 series reference extensibility, 
	R502 and R600 reference transport neutrality).

	In this context, layering refers to both XMLP's support of XMLP 
	modules (the layer(s) "above") as well as the capability of XMLP 
	to define services required (the layer(s) "below") for 
	implementation across a variety of underlying protocols.

R501
	The specification will make reasonable efforts to support (but not
define)
	a broad range of protocol bindings between communicating peers.


R600
	The XMLP specification must not mandate any dependency on specific 
	features or mechanisms provided by a particular transport protocol 
	beyond the basic requirement that the transport protocol must have 
	the ability to deliver the XMLP envelope as a whole unit. This 
	requirement does not preclude a mapping or binding to a transport 
	protocol taking advantages of such features. It is intended to 
	ensure that the basic XMLP specification will be transport neutral.

R604
	The XMLP specification must consider the scenario where an 
	XMLP message may be routed over possibly many different transport 
	or application protocols as it moves between intermediaries on the 
	message path. This requirement implies it must be possible to apply 
	many transport or application protocol bindings to the XMLP
	message without information loss from the XMLP message content.

R608
	The XMLP binding mechanism should not preclude the possibility of 
	constructing bindings to protocols that provide a security mechanism.

	Typical examples of such protocols are SSL providing a secure channel,
	and S/MIME which provides a secure wrapper. It should be possible to 
	specify XMLP bindings for such security protocols.

R612
	The XMLP specification must provide a normative description of the 
	default binding of XMLP to HTTP. This binding, while normative, is not 
	to be exclusive. The binding provided by the Working Group will respect 
	the semantics of HTTP and will demonstrate that it can co-exist with 
	existing HTTP/1.0 and HTTP/1.1 implementations.

R803 
	XMLP must not preclude the use of transport bindings that 
	define transport intermediary roles such as store-and-forward, 
	proxy and gateway.

Received on Tuesday, 17 July 2001 11:43:52 UTC