Subject: RE: AW: too fast out-of-SENT-order messages

From: "Martin Stecher" <[email-masked]>
Date: Mon, 3 Mar 2003 10:15:29 +0100

> 
> > It seems that I misunderstood the whole concept.
> 
> I am glad you asked these questions, then! Clearly, predraft needs to
> do a better job at defining OPES messages.

No, sorry, it more seems that I didn't read version 01 of the predraft
carefully enough.

[...}

> 
> 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. 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)
    
3. Callout transactions (3.3 of opes-protocol-reqs)

    consists out of one or multiple (t.b.d)
    
4. Application transactions (protocol predraft)

    consists out of multiple (protocol predraft)

5. Application messages (protocol predraft)

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.

> 
> In your experience, what kind of metadata/state would be associated
> with an OPES transaction (separate from the application transaction)?
> Same service IDs? Dispatcher- and callout-server-specific
> info? Anything else?

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.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 3 Mar 2003 13:36:59 -0700 (MST)

On Mon, 3 Mar 2003, Martin Stecher wrote:

> 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.

Yes. And we can even have one callout connection use multiple
transport connections(?).

>     consists out of one or multiple (t.b.d)

consists out of one or multiple OPES messages

4. OPES message (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.

> about the requesting user for instance.

Thank you,

Alex.