- From: Eamon O'Tuathail <eamon.otuathail@clipcode.com>
- Date: Thu, 5 Jul 2001 16:01:03 +0100
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- Cc: <xml-dist-app@w3.org>
>> 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 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
Received on Thursday, 5 July 2001 10:59:14 UTC