Subject: Re: [Sipping] New Version Notification for draft-niemi-sipping-event-throttle-06

From: Salvatore Loreto <[email-masked]>
Date: Wed, 05 Mar 2008 12:21:23 +0200

Hi Krisztian,

I have just a doubt about the fact that notifier may lower a suggested 
throttle value,
but in the draft is not clear if the notifier MAY lower in any situation 
or only
in specific case like the one you suggested: "because of lowering the 
subscription expiration".

/sal

[email-masked] wrote:
> A new version of I-D, draft-niemi-sipping-event-throttle-06.txt has been
> successfuly submitted.
>
> Filename: draft-niemi-sipping-event-throttle
> Revision: 06
> Title: Session Initiation Protocol (SIP) Event Notification Extension
> for Notification Throttling
>
> Updates:
> - updated references
> - clarified that notifier may lower or higher watcher suggested throttle
> (the latter one is due to local (static) configuration)
> - clarified that throttle mechanism may be used to pause-resume notifys
> (if throttle=subscription expiry time then notifys are paused until
> subscription expiry/refresh)
> - clarified that throttling is not to be applied when subscription state
> changes from pending to active (The user is not authorized yet, thus it
> gets a notify with pending state. Later on the user is authorized and it
> should get the full notify.)
>
> Abstract:
> This memo specifies a throttle mechanism for limiting the rate of
> Session Initiation Protocol (SIP) event notifications. This mechanism
> can be applied in subscriptions to all SIP event packages, but the
> mechanism is especially designed to be used in combination with a
> subscription to a Resource List Server (RLS).
>
>
> Cheers,
> Krisztian
> _______________________________________________
> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>
>   

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: <[email-masked]>
Date: Fri, 7 Mar 2008 21:05:14 -0600

Hi Sal,

>-----Original Message-----
>From: ext Salvatore Loreto [mailto:[email-masked]] 
>Sent: Wednesday, March 05, 2008 2:21 AM
>To: Kiss Krisztian (Nokia-OCTO/MtView)
>Cc: [email-masked]
>Subject: Re: [Sipping] New Version Notification for 
>draft-niemi-sipping-event-throttle-06
>
>Hi Krisztian,
>
>I have just a doubt about the fact that notifier may lower a 
>suggested throttle value, but in the draft is not clear if the 
>notifier MAY lower in any situation or only in specific case 
>like the one you suggested: "because of lowering the 

Good point. Even in this specific situation, the notifier is
"correcting" the subscriber behavior when that is asking for a longer
throttle value than the actual subscription. If we could live without
this (the throttle may be longer than the subscription duration...any
way the subscription expires first), then perhaps we could drop this
function of the notifier. I don't personally see another use case when
this was needed.

Thanks,
Krisztian

>> A new version of I-D, draft-niemi-sipping-event-throttle-06.txt has 
>> been successfuly submitted.
>>
>> - clarified that notifier may lower or higher watcher suggested 
>> throttle (the latter one is due to local (static) configuration)
>> - clarified that throttle mechanism may be used to pause-resume 
>> notifys (if throttle=subscription expiry time then notifys 
>are paused 
>> until subscription expiry/refresh)
>> - clarified that throttling is not to be applied when subscription 
>> state changes from pending to active (The user is not 
>authorized yet, 
>> thus it gets a notify with pending state. Later on the user is 
>> authorized and it should get the full notify.)
>>
>> Abstract:
>> This list is for NEW development of the application of SIP Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments of core SIP
>>
>>   
>
>