RE: Protocol Bindings

Eamon,

> -----Original Message-----
> From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com]
> Sent: 05 July 2001 11:07
> To: xml-dist-app@w3.org
> Subject: RE: Protocol Bindings
> 
> 
> To get interoperability, surely we need to define both the envelope
> encapsulation *AND* how it gets exchanged over an application 
> protocol.

I have some trouble with the various prefix's we use in front of the word
'protocol' particularly prefixes like 'application' and 'wire'. I'm ok with
prefixs like 'data-link', 'network'... and even 'transfer'. Application
certainly suggests to me specific application centric purpose like SMTP
(transfer of email messages), LDAP (directory access), FTP (transfer of
files) etc.

So if I can change your 'application protocol' to 'underlying protocol' I'd
agree 100%.

> There may be many (M) encapsulations (text, binary, multi-part) and there
> may be many (N) application protocols (BEEP, HTTP, Custom over TCP) and it
> is better to define each just once, so rather than M*N definitions, we
have
> M+N definitions.

I'd be quite happy with that. I still regard it as the role of a binding to
callout what encapsulation mechanism is being used and it's quite ok, even
desirable, that it can callout/reference an encapsulation mechanism that
gets defined once and gets shared across a bunch of bindings.

> If you want to send me a SOAP envelope, it is no good us agreeing on the
> layout of the octets if we can't agree on how to decide where one message
> stops and the next begins (framing).  This, and a number of other
services,
> are provided by an application protocol.

Certainly need to do framing (in a binding) for underlying protocols that
are not message oriented.

I'd also be interested in which "other services... provided by an
application protocol..." you would call out for inclusion somewhere between
the bottom of SOAP and the top of an underlying protocol?

> We can argue whether BEEP or HTTP or whatever is better as an application
> protocol, but the general services they provide are needed - and some
piece
> of functionality must provide them.

I'm not going to argue the relative merits of BEEP and HTTP, actually I
rather like BEEP.
I was under the impression that BEEP was more of a framework for application
protocols rather than a specific application protocol itself.

> Hence I think the diagram at:
>
http://www.w3.org/2000/xp/Group/1/04/23/XMLProtocolAbstractModel.html#Sec5.1
.1
> is wrong.
> 
> The TCP column (left-most column) is completely missing an application
> protocol. TCP is not providing you with framing (etc.) - so which
component
> is?

The definition of a protocol binding, either by reference or by inclusion.

The binding (by reference or inclusion) has to define all those things that
fill the gap between what SOAP expects of the underlying infrastructure and
what a specific underlying protocol provides.

> There should be a small box in that column identifying this component,
> with a name such as "custom". Both you and I might be able to handle TCP
> connections and might be able to understand SOAP XML 1.0 envelopes - but
> that still does mean we can communicate - we also need to agree the
details
> in the middle - how the encoding is carried in the transport.

I think that you're suggesting that there may be more substructure to a
protocol binding and that it might be worthwhile to elaborate on that some
more in Fig 5.1, particularly if that sub-structure is common across a
number of bindings.

> 
> Eamon
>
> P.S. Check out the paper "On the Design of Application Protocols"
> (http://www.ietf.org/internet-drafts/draft-mrose-beep-design-03.txt)

Yep... I've read it (or the earlier version)... it's a great paper.

Thanks,

Stuart

Received on Thursday, 5 July 2001 10:20:42 UTC