On Sat, 25 Oct 2003, Martin Stecher wrote:
I agree that a Want-Out message is very needed and it's a good idea
to have a special status code as result for transaction termination.
Question here: Should it be the result of TE or better AME? I think
AME fits better.
I agree and will fix the current wording to imply "AME". The following
TE will have a "normal" 200 code.
However, please note that "I want out of the loop" has a transaction
scope, not application message scope. It is not possible to continue
the transaction once the server is out of the loop.
Proof by contradiction: If it were an application message-scoped
mechanism it would be possible to get one application message out of
the loop while still processing remaining application messages within
the same transaction as usual. The latter is only possible for
profiles that support multiple adapted AMs per single original AM
(e.g., SMTP). To support such a mode, the processor would have to
maintain at least two original data flows: one short-circuited due to
Want-Out and one to feed remaining adapted flows. That is probably too
much complexity and goes way beyond the current "one transaction, one
original data flow" approach.
Should the callout server confirm by sending also a special (the
same 206) result code?
Yes, I believe so. Both agents send AMEs/206 and TE/200. If the
callout server sends AME/200, it means the adapted application message
should stop at that point instead of being continued from the original
data flow (i.e, once processor gets AME/200, the loop is over).
In other words, "I want out of the loop" does not mean "I am not going
to adapt starting now". Imagine a situation where an overloaded
non-essential service wants to get out of the loop, but does not mind
keeping adaptation algorithms alive (or cannot disable them) and those
algorithms decide to terminate the message "early" for reasons
unrelated to the overload condition.
If you agree with the rationale, I should document the above caveat.
There are three normal cases for transaction termination. We may
want to discuss this together in one section of OCP core and define
result codes for all three. What do you think?
1. Complete application message is sent to callout server and
terminated with AME 200, callout server returns a complete message
and also ends with AME 200.
2. At some time callout server decides to only echo the rest of the
message. It sends a Want-Out message, echos all data until it
receives an AME 206 and then responds also with an AME 206.
3. The callout server sends a response (e.g. an error message for
the client). Sending is done before complete application message has
been received. The callout server will send its AME message and by
design does not longer care about DUM/DUY messages being transferred
for this transaction. OPES processor can stop sending the
application data when it sees the AME message. It will terminate the
transaction.
In #3, the server will terminate the transaction first: it will send
TE right after AME.
We should also have a special 2xx result for this case, I think.
Could you explain why a special 2xx result would be needed for #3?
To ease statistics collection? Requests, responses,
and short-circuiting is application specific. Do you propose to add
a special status code to HTTP Adaptations draft?
Note, that in cases 1 and 2 the OPES processor sends the AME message first
and in case 3 it's the callout server sending AME first.
Of course beside these three cases there are other scenarios, but I
think they all deal with transaction terminations due to error
conditions.
If I have time, I will enumerate the above scenarios in a informative
(non-normative) way.
I have a related question: Do you think a callout server may send AME
if it thinks that the message is completed (e.g., the original body
has been received and processed, and no trailers are expected)? Or
should the server wait for AME from the processor before sending its
own AME, under normal conditions? In other words, do we want to
support concurrent close optimization OR do we want to allow for
larger-than-expected messages to be adapted successfully? In yet other
words, what does constitute application message end (AME from the
other agent only OR that and some other information like AM-EL)?
Thanks,
Alex.