Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt

From: "Martin Stecher" <[email-masked]>
Date: Thu, 6 Jun 2002 09:15:20 +0200

Hi Andre,

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

> 
> Yes, this would be feasible (but not necessarily very efficient).
> 

Absolutely. And that's why an OPES protocol SHOULD offer a keep-alive
mechanism.

Regards
Martin

---

From: Andre Beck <[email-masked]>
Date: Thu, 06 Jun 2002 10:15:12 -0500

Hi Martin,

> callout server without loosing data if the next request is just about to

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.

> Absolutely. And that's why an OPES protocol SHOULD offer a keep-alive

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