Subject: [Simple] MSRP Comments - Keepalive

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 19:02:34 +0300

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

---

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

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

---

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

Regards,
Aki

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 20 Oct 2003 11:15:08 +0100

<<comment in-line>>

>From: [email-masked] [mailto:[email-masked]]
>Sent: 20 October 2003 11:03
>To: [email-masked]
>Cc: [email-masked]
>Subject: RE: [Simple] MSRP Comments - Keepalive
>
>
>
>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?

[Chris Boulton] The only real reason I can think of is to maintain the
'lets keep it simple and light weight' philosophy that MSRP champions.
I don't have a problem with creating a new method for this functionality
BUT I think we need to be careful when crating new methods for
functionality where appropriate semantics already exist.  As long as the
refresh operation is explicitly defined, I just don't see the need.

Chris.

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 20 Oct 2003 11:15:08 +0100

<<comment in-line>>

nature
require
reason to

Chris.

---

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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: Monday, October 20, 2003 1:03 PM
> 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,
>  > >

---

From: [email-masked]
Date: Mon, 20 Oct 2003 20:50:25 +0300

Why don't we have just the one method and define semantics using mime type bodies. This is exactly the same arguments we have in SIP. Why wouldn't they apply here?

/Hisham

> ext Chris Boulton
> Sent: Monday, October 20, 2003 1:15 PM
> To: Niemi Aki (NMP/Helsinki); [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 20 Oct 2003 20:50:25 +0300

/Hisham