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