Subject: [Sipping] Fwd: I-D Action:draft-johnston-sipping-batch-notify-00.txt

From: Alan Johnston <[email-masked]>
Date: Mon, 02 Mar 2009 12:42:28 -0600

All,

Here is a new I-D on the requirements and mechanisms for batch 
notifications in SIP.  This relates to 
draft-niemi-sipping-event-throttle, so the timing is good.

Thanks,
Alan

-------- Original Message --------
Subject: 	I-D Action:draft-johnston-sipping-batch-notify-00.txt
Date: 	Mon, 2 Mar 2009 10:30:01 -0800 (PST)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : A Batch Notification Extension for the Session Initiation Protocol (SIP)
	Author(s)       : A. Johnston, B. Mertka
	Filename        : draft-johnston-sipping-batch-notify-00.txt
	Pages           : 10
	Date            : 2009-03-02

This memo specifies the requirements and mechanism for a SIP events
extension where bulk SIP event information can be shared between two
peers both with the ability and authority to act as notifiers for
this information.  An example application use case is the transition
of event state information during a backup/recovery sequence between
event state servers.  This document is targeted at addressing server
overflow conditions that include the possibilities of the size of
individual notification messages getting excessive and the processing
of state information by both the subscriber and notifier also
becoming excessive.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-johnston-sipping-batch-notify-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 22 Mar 2009 01:42:41 +0200

Hi Alan,

I have read the draft and it looks interesting  especially for Presence

   Aggregated presence servers within a domain could use an
   approach such as this to share presence information between them and
   to synchronize and transfer event state compositor information.

however it looks as the mechanism you are proposing is suitable for a 
one time fetch and not for monitoring
presence over time. isn't it?
What would be interesting is to reuse a subscription between two servers 
to send the Notifies for X number
of presentities in that sip_dialog.

Moreover REQ-1 is about the max number of bodies in a notification and 
REQ-4 is to indicate that the full event state has been transferred
That may be useful for applications where you have to know the full 
state of a notification before acting
on the content: you divide a picture into several notifications and then 
concatenate the content
to get the full picture.
However in an RLS scenario, an RLS can send notifies independently if 
combining more presentities in one single
notify makes the body to be too big. The only issue would be if a single 
data in a notification is too large, but then
the draft does not have a Requirement about it.

/Sal

Alan Johnston wrote:
> _______________________________________________
> 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: Alan Johnston <[email-masked]>
Date: Wed, 25 Mar 2009 11:09:40 -0500

Salvatore,

Thanks for your comments on the draft.  See my responses below.

Thanks,
Alan

> presence over time. isn't it?

No, if you leave out REQ-4, then it can be ongoing.  We should state 
this more clearly and include a call flow showing this.  There are, 
however, applications where a different mechanism (such as publication) 
will be used for ongoing state updates instead of this bulk notification 
for initial sync.

> What would be interesting is to reuse a subscription between two 
> servers to send the Notifies for X number

I'm not sure I follow - are you saying - could you explain more.

> on the content: you divide a picture into several notifications and 
> then concatenate the content
> to get the full picture.

Right.

> notify makes the body to be too big. The only issue would be if a 
> single data in a notification is too large, but then

Right - this draft doesn't cover that case, but I believe yours, 
draft-niemi-sipping-event-throttle, would, right?  I would imagine that 
both mechanisms would commonly be used together.

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Mar 2009 11:16:36 -0500

Salvatore,

Thanks,
Alan

Right.