On Thu, 24 Apr 2003, Martin Stecher wrote:
could you already give some real life examples how OCP over BEEP
will look like? I am not sure how much XML and Content-Type
statements will be necessary to be BEEP compatible.
Here is an example of what XML and MIME exposure is _required_ by
BEEP. The actual exposure to XML and MIME headers (beyond this
example) would depend on us. "C" is for OPES processor. "S" is for
callout server.
* OCP connection (BEEP session) and OCP transaction (BEEP channel)
establishment; the transaction establishment part is missing
OCP control messages (those are given in the next example):
S: <wait for incoming connection>
C: <establish connection>
S: RPY 0 0 . 0 201
S:
S: <greeting>
S: <profile uri='http://www.ietf-opes.org/profiles/OCP' />
S: </greeting>
S: END
C: RPY 0 0 . 0 52
C:
C: <greeting />
C: END
C: MSG 0 1 . 52 133
C:
C: <start number='1'>
C: <profile uri='http://www.ietf-opes.org/profiles/OCP' />
C: </start>
C: END
S: RPY 0 1 . 201 100
S:
S: <profile uri='http://www.ietf-opes.org/profiles/OCP' />
S: END
* Sending an OCP control message over a BEEP channel:
C: MSG 1 0 . 0 50
C: Content-type: application/beep+ocp
C:
C: are-you-there xid ...
C: END
S: REP 1 0 . 0 61
S: Content-type: application/beep+ocp
S:
S: i-am-here xid ...
S: END
* Sending data message over a BEEP channel (note that we may want to
establish a new channel for data, in addition to control channel for
command messages; here, we are using channel #2, am-id=1234):
C: MSG 2 1234 * 0 1634
C: Content-type: whatever-was-negotiated
C:
C: ... 1634 data octets, with more to come ...
C: END
C: MSG 2 1234 * 1634 65536
C: Content-type: whatever-was-negotiated
C:
C: ... 65536 data octets, with more to come ...
C: END
C: MSG 2 1234 . 67170 100
C: Content-type: whatever-was-negotiated
C:
C: ... last 100 octets of the data ...
C: END
Most numbers/parameters are wrong/random. I am just illustrating
XML/MIME exposure here. You can notice that we must use XML for BEEP
state management and we must use explicit Content-types for anything
other than application/beep+xml.
Note that if we define our own BEEP messages, we can avoid repetitions
of "Content-type:" headers by defining our own defaults. BEEP defaults
to application/beep+xml. We will lose compatibility with existing BEEP
libraries/implementations though, so it may not be such a good idea.
Disclaimer: The first example is actually based on
draft-ietf-syslog-reliable-12 that uses BEEP as transport. I am not a
BEEP expert yet, so the above may have conceptual bugs. Please
correct them if they affect XML/MIME exposure issues.
While I like many of the BEEP concepts and agree that they are very
useful for OCP, I am not sure that I will like the protocol's look
and feel. This may change by seeing a real example, or it will
encourage me to create an alternate proposal ;-)
That's why I am also very interested how OCPTRAN could look like.
I too would be excited to work on a "better BEEP" or "better SOAP". I
just think that existing protocols must be considered first (or in
parallel). If we can convince ourselves that BEEP is good enough, we
will save the working group a lot of work.
Alex.
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Thursday, April 24, 2003 5:41 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: OCP transport nomination
I would like to nominate BEEP as the only OCP transport. My primary
reasons for nominating BEEP are:
- reuse of BEEP negotiation capabilities for
transport encryption and such
- availability of efficient transfer for
opaque ("binary") data
There are several issues that we would need to resolve if BEEP is
selected by the group (e.g., selecting BEEP message exchange model and
defining OCP message encoding), but I would like to hear other
protocol nominations (Hilarie?) or any objections to BEEP before
discussing BEEP-specific details.
I hope I am not making a mistake by giving BEEP a preference over
SOAP. I would really like to use SOAP because that is what web
services world is using, and we are doing something very similar.
Unfortunately, SOAP suffers from a legacy of being started as an RPC
protocol and has no standard way of handling large opaque data
[efficiently]. If BEEP is selected, we would essentially trade
"efficient transfer" for "current deployment". I hope that is the
right choice, especially since SOAP can still be used as another
callout protocol in environments where efficient transfer is not
important. If you think otherwise, please speak up now.
We have talked about all known transport candidates except Hilarie's
OCPTRAN. Let's move this discussion to a closure. OCP work cannot
proceed much further without the transport selection.
Thank you,
Alex.