On Sun, 26 Oct 2003, Martin Stecher wrote:
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.
For SMTP maybe not immediatly. See below.
Yes, I assumed single adapted AM above.
For HTTP this special code is not needed for direct functionality
but for better statisticy and debugging possibilities: If the OPES
processor wants to count for cases #3 a special result code will
even count then for the case in which both AMEs are sent
simultaniously. If in a debugging session someone checks the data
sent by the OPES processor (not seeing the data sent by the callout
server), he may wonder that an application message is not sent
completly. A result code other than 200 with the AME message, will
help to understand why.
Agreed.
For other application protocols, such as SMTP, the special code sent
by the callout service can even make functional sense. A service may
want to send several error messages, all not longer depending on the
rest of the application data, to multiple recipient and therefore it
will send several application messages. By indicating with the first
AME that the OPES processor can stop sending more application data
it helps to increase performance.
It looks like you want one adapted AME status code affect behavior of
other adapted application messages (whether they are going to receive
more original data). I think a better interface would be to have a
special "Wont-Use" message with a transaction scope, to indicate that
more original data is not needed. Hmm... It looks like we really do
not have a good enough interface to control original data flow in the
case of multiple adapted messages. It is currently not clear whether a
single adapted flow statement like Wont-Use parameter applies to
original data flow (and hence affects other adapted messages) or just
to the adapted flow making a statement. If we ever end up supporting
multiple adapted application messages, we would have to make all of
that clear and consistent.
For now, it looks like we assume that there is always a single
original flow, regardless of the number of adapted flows. Perhaps it
is the right decision (because it is simple), but it is hard to say
without digging into SMTP specifics. On the other hand, we stick
parameters like Wont-Use into am-id-dependent messages as if we imply
that two adapted flows may have different Wont-Use statements.
Do you think we should move all parameters that apply to the original
flow from am-id-specific messages to xid-specific messages? For
consistency reasons? Or do you think we will eventually require
processor to merge all such parameters together before deciding what
to do with the original flow? In other words, who is responsible for
merging adapted flows' interests into one statement affecting original
flow, the server or the processor?
This case will be different from an error message which is sent in
the first application message but another application message which
builds on the complete original message will follow; in that case,
the callout server will send a result 200 with the first AME.
Agreed.
If you agree in all this, I would prefer to have some general status codes
for the three cases in OCP core.
I think I can and should document 206 code in Core.
However, I am not sure how to document the "short circuit" code in the
Core. The Core cannot assume that an application protocol has
requests/responses and, hence, cannot document something like a
"Respond with this response instead of forwarding original request"
code.
If I try to be generic and document the code as something like
"adapted message is not intended for the original message recipient",
we might raise red flags for those who think that IAB "OPES must not
resolve URIs" concern applies in this case.
Suggestions?
Also, should we use 207 as the value for this short-circuit code? Or
does some HTTP extension use that code? We do not have to avoid all
conflicts with HTTP, but it would be nice to avoid same codes naming
very different things.
The length of an application message SHOULD only be determined by
the length of the DUM message's payload (and the DUY message's size
param) and terminated by the AME message. AM-EL values are important
for better HTTP adaption but they SHOULD NOT be used for message
length counting for OCP purposes, IMO.
I agree in principle, and we already have a MUST that instructs agents
to send AMEs immediately.
Alex.