Subject: [Sipping] draft-moran-sipping-filters Where does this fit?

From: "Moran Tim (NET/Dallas)" <[email-masked]>
Date: Thu, 6 Dec 2001 17:25:08 -0600

Greetings,

The status for draft-moran-sipping-filters is listed as "Where does this
fit?".  To that end we would like to propose that those interested in
discussing this meet on Tuesday @ 7:30 in front of the registration
desk. From there we will go to a room and hold a bar bof on the issue.
Let me offer the following to help us derive an answer.
This work would appear to fit in the sip wg since it is an enhancement
to the SUBSCRIBE/NOTFIY methods. However, since it doesn't really add
new methods it might be more appropriate for the sipping wg.  The idea
for this draft was a result in observing some open issues in the sip
events, sip presence and wathcer info drafts as well as application
issues for wireless.  These are the two major aspects  which lead to the
draft. To explain:
Issues with current drafts using subscribe/notify:
It is suggested in the sip events draft that a throttling mechanism may
be needed in the packages which instantiate the subscribe/notify
methods. Current drafts such as watcher info and presence come close but
do not explicitly state when a notification is sent. Wathcer info comes
closest but when you read the detailed sections, it becomes a little
unclear. Even if the packages & subpackages define the rules, the issue
remains that over time, esp as more attributes are added to the
packages, that the rules may simply not fit what all implementations of
the basic service need - or specifically what a given user of the
service may need. Wireless and wire line telephony provide options for
features such as whether a calling line id is presented or whether it is
not, who pays (calling or callee) and which long distance carrier to
use. Why then should a user (client) be forced to receive Notifys only
when a pre-determined (defined in the package draft) set of rules in the
server are met? Yes, there is polling which is quite powerful but
polling is expensive. As the number of attributes increases for new
services (as in the case when an operator wants to differentiate their
service or for environments such as wireless) the default rules will be
hard pressed to provide adequate service - if in deed the defaults can
be specified. If not (and even if not), the client (subscriber) should
have some say as to the rules for when to deliver notification - and in
a common way.
Wireless applications:
The attributes for presence for wireless are already being extended well
beyond the basic open/close status. wireless links require cost saving
measures. Optimizing the frequency and content of Notifications to meet
the needs of the service, service provider, and the user ($) is needed. 
So, this draft identifies the need to permit clients (subscribers) a
common mechanism to specify the rule(s) for how often notifies are to be
sent with a little more intelligence than the value of one attribute .
It also identifies a need for specifying how much information is sent as
opposed to everything.  
We suggest that a common mechanism be defined rather than the wheel
being re-invited for each instantiation of SIP events.
Best Regards,
Tim Moran 

_______________________________________________
Sipping mailing list  http://www1.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: "Eric Burger" <[email-masked]>
Date: Sat, 8 Dec 2001 21:45:24 -0500

I would be *very* interested if one could come up with a generic mechanism.
I'm disconnected right now, but I plan on reading the draft before Tuesday.

As anyone at the Dallas Interim WG Meeting knows, I believe this is an
intractable problem.  That is, it is not possible to define a generic
mechanism, as every even package has different metrics (as you outline below
:-).

Could you move the meeting time to 8:30pm?  However, I just looked and saw
that this collides with the security ad hoc.  Other alternatives?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Moran Tim (NET/Dallas)
Sent: Thursday, December 06, 2001 6:25 PM
To: [email-masked]
Subject: [Sipping] draft-moran-sipping-filters Where does this fit?

Greetings,