Subject: RE: [Simple] Event header params in event list subscriptions

From: Adam Roach <[email-masked]>
Date: Wed, 26 Mar 2003 11:55:17 -0600

This is part of the open issue we just closed. You might
have noticed a recent thread entitled, "Urgent: Event Lists
Open Issue;" it covers exactly this topic.

The short answer: this is being removed, and will be
resolved by the filtering work.

/a

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2003 5:43
> To: [email-masked]
> Subject: [Simple] Event header params in event list subscriptions
> 
> 
> Hi,
> 
> Chapter 3.2 of the event list draft talks about Event header 
> params, and suggests that all parameters are propagated 
> towards the leaf subscriptions. Is this a good idea?
> 
> As an example, if an event throttle would in fact be an Event 
> header parameter, should it be propagated, or should it 
> instead be applied only to the root subscription? Would a 
> propagated throttle in fact be applied at multiple levels, 
> virtually quenching the list?
> 
> Also, it could be a problem if the RLS does support a 
> specific parameter, but none of the other nodes/leafs do.
> 
> Cheers,
> Aki
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Robert Sparks <[email-masked]>
Date: 26 Mar 2003 12:51:00 -0600

Aki actually participated in the thread you call out.

Step away from the example he gave and look at the question
again. Suppose an event carries parameters on the Event header
that somehow affect processing the subscription. Suppose further
that there might be an effect that can't be characterized as
"filtering". What then? The answer certainly isn't going to
come out of the filtering work.

The same type of question can be applied to other parts of the
message, Require or Accept for example. 

Those are all useful questions to ask, but I believe the answers
to each of them are going to be implementation specific (Remember
that an RLS might well be responsible for all the "leaves" and 
never have to go off-board for more information, or may go off-board
using not-SIP). This draft doesn't need to specify the details
of how this back-end part of an RLS behaves.

In summary - I agree that the point should be removed. These
questions will be addressed as needed in other contexts.

RjS