[Sipping] SUB/NOT issues

[Rohan Mahy <rohan at ekabal.com>]

Hi Aki,

I read you draft about SUB/NOTIFY issues and potential optimizations. I 
definitely agree that requirement 1 and 2 would be a good optimization. 
 A few random thoughts on the first two requirements:

- This would require something like If-Match in the SUB and something 
like the Subscription-State header in the response to the Subscribe.
- You would need to SUBSCRIBE to a GRUU.  It may be prudent to define a 
new 2xx response that means you REALLY got the right notifier.

I'm not sure about requirement 3.  isn't 1 and 2 sufficient?  obviously 
you don't want to hammer the network with NOTIFYs (not good for 
congestion collapse) if there is no UA there.  I don't understand how 
you would strike a nice balance here.

thanks,
-rohan

Requirements from the draft:
>    REQ1:  It must be possible to suppress the NOTIFY request (and the
>           event body therein) triggered by a subscription refresh, if
>           the subscriber already has possession of the latest event
>           state of the resource
>
>    REQ2:  It must be possible to suppress the NOTIFY request (and the
>           event body therein) triggered by a fetch, if the subscriber
>           already has possession of the latest event state
>
>    REQ3:  It must be possible for the notifier to fail soft in case
>           temporary interferences in the subscriber's connectivity.  In
>           other words, the notifier must tolerate notification time 
> outs
>           without severing the subscription, especially in long-lasting
>           subscriptions.


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP