RE: Protocol Bindings

Hi Eamon,

> -----Original Message-----
> From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com]
> Sent: 05 July 2001 16:01
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: Protocol Bindings
> 
> 
> >> 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?
> 
> If the underlying protocol merely transports the bits (e.g. TCP) - who
> describes ... session establishment (where to connect to), how transport
> security is provisioned, what are the rules for authentication, what
support
> is there for intermediaries (e.g. to get through firewalls - [not talking
> about SOAP intermediaries here]), how errors are reported (of the
underlying
> protocol - not SOAP Faults) etc., etc.
> 
> If all this is going to fit inside a binding, and if it is to 
> be described comprehensively, then the binding will get very large.

I don't think you're arguing that things should not be comprehsive, or at
least appropriately detailed... so i think one would presume that some
appropriately detailed or comprehensive description would (ideally) have to
exist in some from. From a spec. pov it then becomes a matter of how that
description is partitioned and whether there are chuck's that are of
'generic' utility to several bindings. f course we're also talking a bit
about two things here... one is a description of a given protocol binding
and the other is implementations of the said binding. 

BTW the intent of Fig 5.1 in the AM (at least as I read it) is to
acknowledge that different underlying protocols provided different service
abstractions (hence the variation in shape on the lower side of each
protocol binding) and that some bindings may be thin and others thick (hence
the different vertical positioning of the boundary between binding and
underlying protocol). The labels underneath each binding are eg. ie. the
diagram is illustrative.

> >> I was under the impression that BEEP was more of a framework for
> >> application protocols rather than a specific application protocol
itself.
> 
> True. This equation gives you an application protocol:
> 
>    application protocol = BEEP + 1 or more profiles
>                         + authorization policies
>                         + provisioning rules (e.g., use of SRV RRs[38])
> 
> The SOAP over BEEP profile could be used on its own, or could be use in
> parallel with other profiles (over the same underlying TCP connection and
at
> the same time).
> 
> 
> > >
> > > 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.

> It sure is.

> Even those people on this list not interested in BEEP should read the
first
> four sections, which describes the various generic properties of
application
> protocols.


> Eamon

Regards

Stuart

Received on Friday, 6 July 2001 08:13:02 UTC