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:
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: Internet-Drafts@xxxxxxxx
Reply-To: internet-drafts@xxxxxxxx
To: i-d-announce@xxxxxxxx
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.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
