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

From: "Martin Stecher" <[email-masked]>
Date: Tue, 11 Jun 2002 09:41:10 +0200

Hi Reinaldo,

> 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. 
 
I just read again the definitions of MUST and SHOULD in RFC 2119.
 
How can I argue for a SHOULD without showing particular circumstances
that may have their valid reasons to do without keep-alive? I follow
Andre and you that a protocol without keep-alive has some disadvantages
and so technical arguments to ignore keep-alive are weak.
 
But I do not understand why it is an absolute requirement to have a
keep-alive message in order to create a working callout protocol. And I
am missing your arguments for this position.
Andre and you tell me about "less efficient" and "it complicates
without...". These are not arguments for a MUST, are they?
 
The Abstract section of this OPES draft says: "The requirements are
intended to help evaluating possible protocol candidates and to guide
the development of such protocols."
 
I think that keep-alives as an absolute requirement without exceptions
in particular circumstances is wrong to support this task.
 
There is nothing more I can say about this. I will not continue with
this argumentation. If you cannot follow my arguments, keep the MUST
alive ;-)
 
Regards
Martin

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 11 Jun 2002 11:22:18 -0400

Martin,

 > keep-alive message in order to create a working callout protocol.
 > And I am missing your arguments for this position. Andre and you
 > tell me about "less efficient" and "it complicates without...".
 > These are not arguments for a MUST, are they?

If the goal would only be to have some "working" mechanism for remote 
service execution, you could probably do this with already existing 
mechanisms - a callout protocol is somehow motivatate by 
efficiency/complexity considerations, so I'd assume it's fine to have 
some requirements with respect to those issues.

-Markus