Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed

From: Adam Roach <[email-masked]>
Date: Tue, 28 Jul 2009 09:45:17 +0200

Dean Willis wrote:
> Byron Campen wrote:
>
>   
>>     Indeed, this could be done with etag, and using etag is a far more
>> efficient mechanism, because you are not gratuitously sending
>> (potentially very large) documents. My main beef is that this shifts the
>> job of maintaining soft-state to the server. As a general principle,
>> this has been the client's job, and this is specifically how SIP events
>> is supposed to work. Allowing the client to say, "Nah, you're going to
>> handle recovery now." is a rather fundamental change to the protocol,
>> that we should only make if there is a compelling reason. I see no such
>> reason.
>>
>>     
>
> I find this argument compelling. It might even be worth expounding on
> this general concept in rfrc265bis.
>   

I don't understand what you are proposing. Could you give an example of 
what such text would look like?

/a

---

From: Byron Campen <[email-masked]>
Date: Tue, 28 Jul 2009 08:52:54 -0500

> I don't understand what you are proposing. Could you give an example  
> of what such text would look like?
>
> /a

	Basically, that the client should handle keepalives for soft state.

Best regards,
Byron Campen

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Jul 2009 16:35:20 +0200

[as individual participant]

>     Basically, that the client should handle keepalives for soft state.

I get that, but I don't see where that indicates any changes to the 
document.

I'll be more blunt: if you have an idea for something you'd like to see 
added to RFC3265bis, send the literal text you'd like to see included in 
the document, and an extremely precise pointer to where you'd like to 
see it inserted. I'll take xml2rfc format or plain text.

/a

---

From: Byron Campen <[email-masked]>
Date: Tue, 28 Jul 2009 10:52:20 -0500

>>> I don't understand what you are proposing. Could you give an  
>>> example of what such text would look like?
>>>
>>> /a
>>
> I'll be more blunt: if you have an idea for something you'd like to  
> see added to RFC3265bis, send the literal text you'd like to see  
> included in the document, and an extremely precise pointer to where  
> you'd like to see it inserted. I'll take xml2rfc format or plain text.
>
> /a

	Personally, it seems like a design principle that is more general, so  
I dunno if it would go somewhere like 3265bis. Dean?

Best regards,
Byron Campen