On Mon, 3 Mar 2003, Martin Stecher wrote:
I was thinking that OPES transactions might correspond to OPES
connections. That is why I did not introduce them into the draft yet,
waiting to hear more opinions on the connection management issues. It
is probably about time for me to make a specific proposal though.
Callout transactions and connections are not the same due to the
requirements draft.
True. I was not accurate enough. I meant to say that we could prohibit
multiplexing OPES transactions over one OPES connection. We must
support multiple OPES transactions over one OPES connection, but those
transactions may be sequential unless I misread the requirements.
This is the message hierachy as I see it today.
Please correct if I am wrong:
1. Transport layer connection between OPES processor and callout server
can have one or multiplex multiple (3.4 of opes-protocol-reqs)
2. Callout connections (3.4 of opes-protocol-reqs)
consists out of multiple (3.4 of opes-protocol-reqs)
Yes. And we can even have one callout connection use multiple
transport connections(?).
3. Callout transactions (3.3 of opes-protocol-reqs)
consists out of one or multiple (t.b.d)
consists out of one or multiple OPES messages
4. OPES message (protocol predraft)
4. Application transactions (protocol predraft)
consists out of multiple (protocol predraft)
5. Application messages (protocol predraft)
Application transactions and application messages are
application-protocol specific. They are not defined in the predraft,
but one callout transaction must correspond to one application message
(3.3 of opes-protocol-reqs and see below).
The mapping between 3 and 4 is not yet determined. I suggest to go
for a relationship where one callout transaction consists out of
multiple application transactions. And then move the "services"
parameter of the "xaction-start" message to the callout transaction
init message. This way we can minimize the overhead of callout
transaction specific meta data in application transactions.
But draft-ietf-opes-protocol-reqs-03.txt says in 3.3 Callout
Transactions:
A callout transaction is defined as a message exchange between an
OPES processor and a callout server consisting of a callout request
and a callout response. [...] A callout request
MUST always contain a partial or complete application message. A
callout response MUST always indicate the result of the callout
transaction. A callout response MAY contain a modified application
message.
The above seems to imply that there could be only one application
message (or two, if you count original and modified separately) per
callout transaction. That implication seems natural to me. That is why
I was thinking that callout _connections_ should carry properties
common to many callout transactions.
A transport connection does not have to be terminated when a callout
connection ends, I guess, so we are not going to loose efficiency
here.
If you look into ICAP's OPTIONS message we could move some or all of
these parameters into the callout transaction init phase. Other meta
data for a callout transaction would be "requested services",
"processor identification", "callout service database version (see
ISTAG header of ICAP)".
Meta data of an application transaction would then be information
about the requesting user for instance.
Thank you,
Alex.