Subject: RE: [Simple] MSRP Comments - Keepalive

From: [email-masked]
Date: Mon, 20 Oct 2003 20:48:13 +0300

I'm in favour of not overloading method semantics and therefore agree with Aki.

KEEPALIVE sounds ok.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: Monday, October 20, 2003 1:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Simple] MSRP Comments - Keepalive
> 
> 
> 
> 
>  > -----Original Message-----
>  > From: ext Ben Campbell [mailto:[email-masked]]
>  > Sent: 17 October, 2003 20:49
>  > To: Niemi Aki (NMP/Helsinki)
>  > Cc: [email-masked]
>  > Subject: Re: [Simple] MSRP Comments - Keepalive
>  > 
>  > 
>  > The reasoning was, from a relay's perspective, it watchers for IM 
>  > traffic to determine liveness. Clients that don't have any _other_ 
>  > traffic to send should just generate some frome time to 
>  > time. There is 
>  > nothing particularly special about the traffic generated. 
> Sending an 
>  > empty message seemed to have exactly these semantics.
> 
> I don't think there is anything wrong with this reasoning.
> 
>  >  From an endpoints perspective, I could see adding a new 
>  > method if we 
>  > wanted some special semantic handling that is different than 
>  > for SEND. 
>  > But I don't see how the receiver semantics for a 
> "KEEPALIVE" method 
>  > would be any different than for an empty SEND method.
> 
> That is certainly true. I don't think there is a difference 
> in semantics.
> 
> Where I think something like KEEPALIVE would help is in 
> specification clarity. I think it's better to keep things 
> explicit. If in total, this would save a few posts on 
> sip-implementors that doubt the "special" nature of a SEND 
> without a body, then I think it's worth doing.
> 
> On the other hand, as a drawback to the KEEPALIVE method, it 
> would require defining a new method with it's associated 
> specification work, which I don't believe is a considerable 
> burden though. Is there any other reason to prefer an empty 
> SEND over a KEEPALIVE?
> 
> Regards,
> Aki
>  
>  > 
>  > Aki Niemi wrote:
>  > 
>  > > Hi,
>  > > 
>  > > I know this is the sort of thing people usually use as 
>  > flamebait, but I 
>  > > just have to ask ;-)
>  > > 
>  > > Why overload the SEND for keepalive? Is there a specific 
> reason to 
>  > > minimize the number of methods in this protocol? I don't see the 
>  > > complexity added by having a function that clearly does 
> something 
>  > > specific have its own method name, too.
>  > > 
>  > > Regards,
>  > > Aki
>  > > 
>  > > 
>  > > 
>  > > _______________________________________________
>  > > Simple mailing list
>  > > [email-masked]
>  > > https://www1.ietf.org/mailman/listinfo/simple
>  > 
>  > 
>  > 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2003 12:52:46 -0500

I will re-iterate that I do not see this as overloading method 
semantics. The relays do not even know that keepalives exist--nor should 
they. All they are doing is watching how much time has passed since the 
last SEND request.

I believe the empty SEND request was the consensus of the room in the 
interim meeting. Are there others that share the opinion that we need to 
change this to a new method?

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2003 12:52:46 -0500