W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

RE: Protocol Bindings

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 5 Jul 2001 13:12:17 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192512@0-mail-1.hpl.hp.com>
To: "'Krishna Sankar'" <ksankar@cisco.com>
Cc: xml-dist-app@w3.org
Hi Krisna,

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: 05 July 2001 07:49
> To: xml-dist-app@w3.org
> Subject: RE: Protocol Bindings
> Mark/William/Henrick,
       ^^^^^^ it's Stuart BTW, our exchange server insists on emitting our
names in reverse!

> 	Couple of quick observations:
> 	1.	Agreed. Binding is encapsulation and nothing 
> more, nothing less. And yes, protocol implies more.

Not sure I agree... we have prefixed the word binding with the words
'protocol' or 'transport', 'encapsulation' and 'nested' or 'nestable'. I
think that makes it hard to attribute meaning to the word without one of
these prefixes.  Your comment seems to suggest 'binding' == 'encapsulation

> 	2.	Before we get to binding, I assume we will 
> articulate an essential set of what XMLP would need and use. 
> (Which I think is the main theme of Stuart's e-mail)


> As Mark 
> pointed out, we can only say what XMLP needs and any other 
> initiatives like normalizing features provided by other transports
> is outside the scope and is a Herculean task. It would be a good
> undertaking, though.

Agreed, barring the one or two transports the the XMLP-WG commits to
defining. However, I believe that we should provide a transport binding
abstraction that we believe is convenient and encouraging of the definition
(by others) of further transport bindings.

> 	3.	Which also means, if there are more "features" 
> available at the transport layer, (like the multi-channel 
> capability of BEEP or the publish capability of UDP) XMLP 
> wouldn't use them. Of course, implementations can
> make use of the extra "features" as an optimization.
> 	4.	Would the XMLP specification have the actual 
> bindings (and examples) for popular transports like TCP, 
> HTTP, BEEP, ... ?
> Stewart,
> 	The paragraph, "NB: This proposal makes the assumption that the
purpose of
> a binding is to create a common abstraction across all underlying protocol
> that 'hides' the functional differences between different underlying
> protocols."
> 	*could* read something like
> 	"The purpose of binding is to create the minimum abstraction
required by
> XMLP to successfully operate across all protocols and provide
> as a mission statement

That seems ok... I think that we (self included) need to be a little careful
with the universal all. I think we probably need to be meaning all
underlying protocols that we would reasonably expect to bind SOAP/XMLP to.
That's probably what we both mean... and I think that limits the herculean
effort :->

Anyway, I think working toward a statement of the purpose/role of a
transport protocol binding (to use two prefixes) would be a good thing.

> and then add the requirements Mark
> has in his e-mail.

Yes... probably modulo some further discussion of purpose and requirements
that stem from that purpose.

> cheers
> <snip ../>


Received on Thursday, 5 July 2001 08:12:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC