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

From: [email-masked]
Date: Wed, 26 Mar 2003 13:42:45 +0200

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Mar 2003 15:34:16 -0600

No, I'll still remove it.

/a

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2003 14:50
> To: Adam Roach
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [Simple] Event header params in event list subscriptions
> 
> 
> Off the top of my head, no. But, we put an extension point on the
> Event header field. Are you comfortable saying that no one will
> ever find a use for it that isn't an expression of a filter? I'm
> not.
> 
> If you convince me that such parameters can only be filters, and
> we determine that bodies are the right place to express filters
> (which is the direction I think we're taking) then I'll argue to
> remove the ability to carry parameters in that header field.
> 
> I don't think you're disagreeing with the action plan to remove
> the point that started this thread from the document though, right?
> 
> RjS
> 
> On Wed, 2003-03-26 at 14:32, Adam Roach wrote:
> > From: Robert Sparks [mailto:[email-masked]]
> > 
> > > 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.
> > 
> > It's not obvious to me that such parameters could be characterized
> > as anything other than filtering. Can you provide an example?
> > 
> > /a
>