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

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 3 Jun 2002 13:55:16 -0400

+1 

abbie

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 1:30 PM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: RE:
> http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r
> eqs-00.txt
> 
> 
> 
> We're struggling with the very issue in the CATS work group.  
> In the CATS
> case, we were hoping OPES would either come up with a 
> solution or make it
> acceptable to punt for now.
> 
> My vote is to punt.
> 
> -----Original Message-----
> On Behalf Of Markus Hofmann:
> 
> [snip]
> Nevertheless, one might wonder whether the benefits that could be
> expected from chaining callout servers outweight the increased
> complexity, in particular with respect to trust relationships,
> privacy, security, etc. Therefore, I'd be little bit hesitant to put
> more specific requirements for callout server chaining on the calloout
> protocol.
> 
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 10 Jun 2002 14:43:56 -0700

Hello Martin,

>From: Martin Stecher [mailto:[email-masked]]
>Sent: Thursday, June 06, 2002 9:26 AM
>To: Andre Beck
>Cc: OPES Group
>Subject: RE:
>http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re
>qs-00.txt
>
>
>
>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.

or we won't be wasting time evaluating protocols that do not comply..

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

I'm not sure I agree with this...It seems you are asking for SHOULD in order
to make ICAP a more viable solution. I have nothing against ICAP, but the
idea of the requirements draft (which I stated on the last IETF
presentation), was to have a clean slate and not to think on any existing
protocols while we write the draft.

For continuity sake let me say that I read your argument regarding the
keepalive as a capability message. As Andre put it I do not consider it very
efficient and it complicates the semantics of the capability message, which
now can be used for keep alives. We have several protocols that use some
type of special 'hello' message and also have capability negotiation and
they are different things. 

Also, I would like to decoupled for the sake of this discussion the
importance of kepalives and how it will be done. 

So, if you think having keepalives as a SHOULD is the right thing to do from
a deployment/technical perspective than I would like to hear your arguments
why, otherwise having it as a SHOULD because of protocol X or Y, then I'm
not sure I agree. 

regards,

Reinaldo

>Martin
>> From: Andre Beck [mailto:[email-masked]]
>> Sent: Thursday, June 06, 2002 5:15 PM
>> To: Martin Stecher
>> Cc: OPES Group
>> Subject: Re:
>> 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
>> 
>> 
>> 
>> 
>> 
>