ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft

2003-02-19 10:33:45
At 16:43 19/02/03, Oskar Batuner wrote:
1. Terminology: I'd suggest using names "OPES processor" and "callout server",
as in the architecture document. OPES server is a bit confusing - too similar
to OPES processor (which in fact is also a server).

I'd also suggest using transaction-id (tid) instead of buffer-id.

Might we not think in term of dispatcher and services?

Does location of these functions change the logic of the relations between the dispatcher (applying the filtering rules) and the service(s)?

2. Transaction boundaries: in your example OPES server does not send
xaction-end. This may result in protocol stack on the callout server keeping
some tid-related data for indefinite time - in order to correctly match
possible incoming messages to the protocol state.

I'd suggest keeping clear transaction structure: each side MUST open and close
transaction with predefined start-end messages. This will result in more
stable and reliable protocol state machine.

I am not sure about this: can matters subject to rules of the filter be changed by the server? Canit result in loops?

3. Client-server protocol versus independent message flow. I think that
client-server architecture (as in ICAP and HTTP) has certain advantages. It
fits well OPES dataflow model: OPES server always initiates transaction as
result of some message received from customer.

not if it acts as a sub-server. Question can we hide that sub-servicing?

Exemple: the OPES server must add a documentation inclduing
a graphic. That graphic mustbe obtained from another paying OPES
server. There is a need for the sub-transaction to be recorded
(payement, legal responsbility etc).

Callout server provides
services that are initiated by request made by OPES processor. This structure
is simpler, and if we need transactions initiated by callout server
independent from OPES data flow (for example request for policy information,
address book, preferences, etc.) we may use a different unidirectional
channel.

bi-directionnal if we want to have negociations?

jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03
<Prev in Thread] Current Thread [Next in Thread>