Subject: [Simple] Notifies on refreshes [Resend]

From: Avshalom Houri <[email-masked]>
Date: Tue, 7 Feb 2006 13:51:40 +0200

draft-niemi-sip-subnot-etags-00 takes an important step towards saving 
unneeded 
notifies when a subscription is refreshed. 
However, until the suggestion will be accepted and implemented I wonder 
what is 
the meaning of the following paragraph from 3265:

3.1.6.2. Confirmation of Subscription Creation/Refreshing 

   Upon successfully accepting or refreshing a subscription, notifiers 
   MUST send a NOTIFY message immediately to communicate the current 
   resource state to the subscriber.  This NOTIFY message is sent on the 
   same dialog as created by the SUBSCRIBE response.  If the resource 
   has no meaningful state at the time that the SUBSCRIBE message is 
   processed, this NOTIFY message MAY contain an empty or neutral body. 
   See section 3.2.2. for further details on NOTIFY message generation. 

What is the definition of *immediately* here? Can the NOTIFY wait until 
there 
is a next publish? 

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

---

From: Aki Niemi <[email-masked]>
Date: Wed, 08 Feb 2006 13:21:33 +0200

Hi,

> notifies when a subscription is refreshed.

Thanks. ;)

> What is the definition of *immediately* here? Can the NOTIFY wait until 

My reading of it is that the NOTIFY is sent immediately after the 2xx; 
the 1st notify can of course contain dummy state, or no state at all. 
What's important is that the dialog is confirmed and the state of the 
subscription is communicated with the NOTIFY and Subscription-State 
header field.

I'm not sure how delaying the sending of the initial state would help 
here, especially if the subscriber really needs that initial state. 
After all, it wouldn't be subscribing if it didn't.

Cheers,
Aki

> --Avshalom
> 
> 
> ------------------------------------------------------------------------
>

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 8 Feb 2006 13:30:58 +0200

Hi Aki,

The issue is more with refreshes where we need to send a refresh with
a state where the subscriber does not really need it.
It is a big burden on the presence server and on the subscriber.

If the subscriber supports partial notify we could send an empty notify
indicating that nothing was changed (with version) but not all subscribers
will support partial notifies.

--Avshalom

Aki Niemi <[email-masked]> 
08/02/2006 13:21

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
Simple WG <[email-masked]>
Subject
Re: [Simple] Notifies on refreshes [Resend]

Hi,

Thanks. ;)

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Wed, 08 Feb 2006 14:01:24 +0200

> It is a big burden on the presence server and on the subscriber.

I see, then this is what subnot-etags is attempting to solve. The server 
can't tell if it can delay the NOTIFY, unless there is a mechanism like 
the one described in the subnot-etags draft.

> will support partial notifies.

True. But again, the server needs to know whether there is a previous 
(full) state at the client to which it can create a state differential, 
or partial notify.

All in all, to be able to suppress the notify payload, we need 
subnot-etags (or something similar).

Cheers,
Aki

> --Avshalom
> 
> 
> 
> *Aki Niemi <[email-masked]>*
> 
> 08/02/2006 13:21
> 
> 	
> To