My point is:
I see this protocol having (at least) two purposes:
1. Preparation to create a good OPES callout protocol
2. Being an evaluation basis for any other wannabe callout protocol
For number 1 we will obviously want to design a protocol that meets all
MUST and SHOULD requirements, i.e. the OPES protocol will include these
keep-alive messages.
But having more MUST requirements than necessary means that evaluation
of other protocols will be less detailed.
ICAP as an example:
That protocol uses persistent connections but misses the keep-alive
messages. Timing out the connections works but puts more responsibility
to the client side. An ICAP client has at least to keep the last chunk
of application data in order to recover from a connection that is just
about to be closed by the ICAP server and to make a retry or to connect
to an alternate server.
This is a less good solution and it shows that ICAP/1.0 cannot be the
final OPES protocol but I still think that ICAP somehow addresses the
idea of persistent channels and should receive a better evaluation than
a very simple protocol that does not offer this at all.
And that's why I think a SHOULD for this section is a good choice.
Martin
-----Original Message-----
From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
Sent: Thursday, June 06, 2002 5:15 PM
To: Martin Stecher
Cc: OPES Group
Subject: Re:
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r
eqs-00.txt
Hi Martin,
True, but the difference is that HTTP servers typically can
use some
sort of time-out mechanism to close idling persistent
connections and
free resources. Callout servers can't do that because such
a behavior
could result in the loss of application message data and the OPES
processor may not necessarily be able to repeat a callout
request (since
it cannot always keep a copy of application messages).
Think of a very simple callout protocol that starts each
request with a
little handshake before application data is transfered
(like in SMTP).
For such a protocol it will be possible to timeout a
connection by the
callout server without loosing data if the next request is
just about to
be sent in this moment.
I agree, but this approach would kind of defeat the purpose of why we
want to use persistent connections in the first place, i.e. to avoid
handshakes and the like before each and every callout transaction.
Yes, this would be feasible (but not necessarily very efficient).
Absolutely. And that's why an OPES protocol SHOULD offer a
keep-alive
mechanism.
How about we leave the requirement for a keep-alive mechanism in the
document, but add a sentence that says that the callout protocol MAY
choose to use an implicit mechanism in order to check the
health status
of a callout connection endpoint, e.g. the parameter
negotiation process.
-Andre