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

From: "Moran Tim (NET/Dallas)" <[email-masked]>
Date: Mon, 10 Dec 2001 12:40:19 -0600

Each event package has its own attributes but I think a set of
rules/constructs could be defined that are generically applicable to
multiple packages. We've looked at a couple of methods using XML. Valid
vs well formed is certainly one discussion.

I can be reached at 214-679-1466 during the breaks.

Tim Moran

> -----Original Message-----
> From: ext Eric Burger [mailto:[email-masked]]
> Sent: Saturday, December 08, 2001 8:45 PM
> To: Moran Tim (NET/Dallas)
> Cc: [email-masked]
> Subject: RE: [Sipping] draft-moran-sipping-filters Where does 
> this fit?
> 
> 
> 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,
> 
> 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
> 

_______________________________________________
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: [email-masked]
Date: Tue, 11 Dec 2001 21:24:09 +0200

Hi,

What we could do is gather up right after the SIPPING meeting, and try 
to set up a suitable time slot for everyone who's interested to discuss 
this issue.

Br,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 16:01:57 -0500

I did not attend this. Did a meeting happen? Any notes available?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Thu, 20 Dec 2001 14:00:33 +0200

Hi,

We ended up discussing this problem space a bit with Tim and Eric, but that
was the extent of the meeting. 

I would say that the conclusion was that the draft needs to be looked at by
more people on this list and get some discussion going. We agreed that it
may be a bit too early to start looking at filtering/throttling mechanisms
for event notifications, since the work is still ongoing with events,
presence, etc. themselves.

But the authors of the draft feel this work is important and we are happy to
continue work on it.

Cheers,
Aki

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 19. December 2001 23:02
> To: Niemi Aki (NET/Espoo)
> Cc: Moran Tim (NET/Dallas); [email-masked]; [email-masked]
> Subject: Re: [Sipping] draft-moran-sipping-filters Where does 
> this fit?
> 
>