Subject: [Geopriv] Another Update to draft-ietf-geopriv-loc-filters-05.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 11:24:56 +0300

Hi all, 

Here is another update to draft-ietf-geopriv-loc-filters-05.txt based on the
feedback from Martin. The changes are:

* added the <locationType> element (including the 'exact' and 'responseTime'
attribute). I re-used the text from the HELD specification and modified as
appropriately. 
* fixed the civic prefix in the example (again)
* modified the schema to pick up the suggestion regarding the <moved> and
the <enterOrExit> element.

The new document is here: 
http://www.tschofenig.priv.at/svn/Filters/draft-ietf-geopriv-loc-filters-05.
txt

Ciao
Hannes

PS: When including the text about <locationType> element two issues that
might need to get discussed, namely the ability to carry multiple PIDF-Los
(or to include multiple representations of the location in the same PIDF-LO)
in a NOTIFY and the need to define some error messages (e.g., to tell the
Notifier that the requested locationType is actually not available).

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 18:39:13 -0500

Thanks Hannes,

responseTime is a bit of a concern.

At a minimum, responseTime is a separate item from locationType.  That will simplify your description a little.

More seriously: I'm not entirely sure how to interpret responseTime in the context of a SIP PA.  This might work as you have described, but I would suggest that it complicates things considerably.  There's discussion on this point in my draft here:

<http://tools.ietf.org/html/draft-thomson-simple-cont-presence-val-req-02#section-4.6.1.1>

I don't know how to solve this problem yet.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 15 July 2009 6:25 PM
> To: [email-masked]
> Subject: [Geopriv] Another Update to draft-ietf-geopriv-loc-filters-
> 05.txt
> 
> Hi all,
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 17 Jul 2009 13:07:39 +0300

Hi Martin, 

>At a minimum, responseTime is a separate item from 
>locationType.  That will simplify your description a little.

Since there is no top level XML element I could only define it as a separate
XML element. That's fine but I believe it does not change a lot.  

>More seriously: I'm not entirely sure how to interpret 
>responseTime in the context of a SIP PA.  This might work as 
>you have described, but I would suggest that it complicates 
>things considerably.  There's discussion on this point in my 
>draft here:
>

I am not sure I see the problems.

Imagine a SIP proxy receives a SIP message with an LbyR and wants to
retrieve location information for routing. Depending on the URI scheme (HTTP
vs. SIP) he would either use 
http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-03.txt
Or 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-04.txt

For
http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-03.txt he
could use the 'responseTime' attribute set to "emergencyRouting". 

When a 'responseTime' attribute is used with
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-04.txt
then hopefully the semantic would be the same. Instead of returning location
information that is good for dispatch location information usable for
routing would be returned. 

Ciao
Hannes

>> Here is another update to 
>draft-ietf-geopriv-loc-filters-05.txt based 
>> on the feedback from Martin. The changes are:
>> 
>> attribute). I re-used the text from the HELD specification and 
>> modified as appropriately.
>> * modified the schema to pick up the suggestion regarding 
>the <moved> 
>> and the <enterOrExit> element.
>> 
>> PS: When including the text about <locationType> element two issues 
>> that might need to get discussed, namely the ability to 
>carry multiple 
>> PIDF- Los (or to include multiple representations of the location in 
>> the same
>> PIDF-LO)
>> in a NOTIFY and the need to define some error messages 
>(e.g., to tell 
>> the Notifier that the requested locationType is actually not 
>> available).
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 19 Jul 2009 19:18:10 -0500

> routing would be returned.

This doesn't necessarily work out this way.  Imagine that emergencyRouting translates to 30 seconds, worst case.  Imagine that your SIP stack considers the "immediately" from RFC 3265 to be in the order of 5 seconds.

The SUBSCRIBE is sent and a 200 response is returned.  The stack waits its 5 seconds and then gives up on the subscription.  When the NOTIFY arrives 25 seconds later, it doesn't know what to do with it.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 20 Jul 2009 09:59:37 +0300

Hi Martin, 

>From: Thomson, Martin [mailto:[email-masked]] 
>Sent: 20 July, 2009 03:18
>To: Hannes Tschofenig; [email-masked]
>Subject: RE: [Geopriv] Another Update to 
>draft-ietf-geopriv-loc-filters-05.txt
>
>> retrieve location information for routing. Depending on the 
>URI scheme 
>> (HTTP vs. SIP) he would either use
>> then hopefully the semantic would be the same. Instead of returning 
>> location information that is good for dispatch location information 
>> usable for routing would be returned.
>
>This doesn't necessarily work out this way.  Imagine that 
>emergencyRouting translates to 30 seconds, worst case.  
>Imagine that your SIP stack considers the "immediately" from 
>RFC 3265 to be in the order of 5 seconds.

An initial NOTIFY to the SUBSCRIBE is generated immediately. That's fine. It
might even come with an empty body. 

>
>The SUBSCRIBE is sent and a 200 response is returned.  The 
>stack waits its 5 seconds and then gives up on the 
>subscription.  When the NOTIFY arrives 25 seconds later, it 
>doesn't know what to do with it.

I don't understand why the stack would decide on it's own when to give up
the subscription.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 16:44:16 -0500

>Notifier that the requested locationType is actually not available).

this last "e.g." part -- shouldn't that be decided at subscription 
time by the UAS not accepting the subscription, or for the periodic 
interval update of location be a simple RFC 3261 defined 480 
(Temporarily Unavailable) ?

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 16:53:27 -0500

At 05:07 AM 7/17/2009, Hannes Tschofenig wrote:
> ><http://tools.ietf.org/html/draft-thomson-simple-cont-presence->val 
> -req-02#section-4.6.1.1>
> >

I'm confused.

For SIP, why would the filters doc be used when Conveyance already 
has how a server dereferences a location URI for routing?

This isn't a soliciting action requiring filters.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 27 Jul 2009 19:46:47 +0300

Hi James, 

>>that might need to get discussed, namely the ability to carry 
>multiple 
>>PIDF-Los (or to include multiple representations of the 
>location in the 
>>same PIDF-LO) in a NOTIFY and the need to define some error messages 
>>(e.g., to tell the Notifier that the requested locationType 
>is actually not available).
>
>this last "e.g." part -- shouldn't that be decided at 
>subscription time by the UAS not accepting the subscription, 
>or for the periodic interval update of location be a simple 
>RFC 3261 defined 480 (Temporarily Unavailable) ?

That's a good question. I could imagine that providing the error during
subscription time would probably be most useful. However, I could imagine
that certain errors could happen during the lifetime of the subscription. 

A protoype implementation would help to understand the error codes better. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 27 Jul 2009 19:54:23 +0300

Hi James, 
 
>> >More seriously: I'm not entirely sure how to interpret responseTime 
>> >in the context of a SIP PA.  This might work as you have described, 
>> >but I would suggest that it complicates things 
>considerably.  There's 
>> >discussion on this point in my draft here:
>> >
>>http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-prot
>ocol-03.t
>>xt
>>Or
>>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-fil
>ters-04.t
>>xt
>
>I'm confused.
>
>For SIP, why would the filters doc be used when Conveyance 
>already has how a server dereferences a location URI for routing?
>

How does SIP Location Conveyance dereference location URIs?
My reading of draft-ietf-sip-location-conveyance was that it conveys
location by value and/or by reference. 

What "indication" is used in a SIP SUBSCRIBE to indicate "Please give me
location information suitable for routing."? 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 04:46:56 -0500

>that certain errors could happen during the lifetime of the subscription.

perhaps I misunderstood you comment about "defining some error 
messages" as *creating* some new ones that don't exist already. If 
that's the case, I apologize.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 05:01:43 -0500

>location by value and/or by reference.

I have a section on this. Specifically it is section 4.5

         "Using sip/sips/pres as a Dereference Scheme"

I even have a pretty diagram.

>location information suitable for routing."?

err, a proxy routes based on the location information it is given (if 
it initiates a dereference transaction in the first place, there is 
no "suitable-ness" to it.

The location-based routing process asks for, and receives (or not) 
the PIDF-LO of the Target, then processes the message (i.e., making 
routing decisions) as if it were sent the PIDF-LO in the original SIP 
request. There's no magic to a location URI to get a routable 
location vs. an unroutable location -- especially since there is no 
difference in our that same proxy receives location by value.

If you believe there needs to be a suitable-ness to location 
information, then we need a new error code for cases in which the 
supplied location isn't suitable, with exactly what an inserter is 
supposed to do with that error code (i.e., in that error code, there 
needs to be an indication what was missing - other than the whole 
location - that needs to be in the subsequent SIP request to make is 
worthy of being routed.

Which do you want -

#1 - route based on the available location supplied (by-value or by-reference)?
or
#2 - a new error code and inserter behavior to know what to do when 
insufficient location was provided in the initial SIP request?

#1 is easy, cuz that's the way Conveyance is written now.

#2 is much more complicated - both to the routing proxy, and the 
burden on the location inserter to understand what isn't enough 
location, and to correct for just that amount - to satisfy the 
proxy's determination of what it thinks it needs to route the message 
propoerly.

James

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 28 Jul 2009 13:20:14 +0300

I was more focused on the following scenario: 

The SIP proxy gets a location URI via SIP. Now, it wants todo location based
routing for the emergency call. It will dereference the location URI as you
mention in Section 4.5 of your document. The LIS does not know that this is
request is only for location sufficient for routing and it tries to
determine location at a best possible extend. This takes time. Then, when
location is available the NOTIFY is sent. The SIP proxy can route the call
but had to wait longer (potentially longer than Brian states in Phone BCP
regarding the maximum call setup time). 

If I understood the HELD mechanism correctly then there is a way to indicate
what type of reference the URI should point to (this relates a bit to the
HELD context document). And the same stuff is available in HELD deref as
well. 

Now, I was wondering whether this would be useful in
draft-ietf-geopriv-loc-filters-05.txt as well. Namely, to let the SIP proxy
tell the LIS when it sends a SUBSCRIBE that it wants location for routing
(and that typically means faster> 

If it does not make sense to anyone then I remove it from
draft-ietf-geopriv-loc-filters-05.txt. 

Ciao
Hannes

>From: James M. Polk [mailto:[email-masked]] 
>Sent: 28 July, 2009 13:02
>To: Hannes Tschofenig; 'Thomson, Martin'; [email-masked]
>> >> >responseTime in the context of a SIP PA.  This might work as you 
>> >> >have described, but I would suggest that it complicates things
>> >considerably.  There's
>>What "indication" is used in a SIP SUBSCRIBE to indicate "Please give 
>>me location information suitable for routing."?
>
>err, a proxy routes based on the location information it is 
>given (if it initiates a dereference transaction in the first 
>place, there is no "suitable-ness" to it.
>
>The location-based routing process asks for, and receives (or 
>not) the PIDF-LO of the Target, then processes the message 
>(i.e., making routing decisions) as if it were sent the 
>PIDF-LO in the original SIP request. There's no magic to a 
>location URI to get a routable location vs. an unroutable 
>location -- especially since there is no difference in our 
>that same proxy receives location by value.
>
>information, then we need a new error code for cases in which 
>the supplied location isn't suitable, with exactly what an 
>inserter is supposed to do with that error code (i.e., in that 
>error code, there needs to be an indication what was missing - 
>other than the whole location - that needs to be in the 
>subsequent SIP request to make is worthy of being routed.
>
>Which do you want -
>
>#2 - a new error code and inserter behavior to know what to do 
>when insufficient location was provided in the initial SIP request?
>
>#2 is much more complicated - both to the routing proxy, and 
>the burden on the location inserter to understand what isn't 
>enough location, and to correct for just that amount - to 
>satisfy the proxy's determination of what it thinks it needs 
>to route the message propoerly.
>
>James
>
>
>>Ciao
>>Hannes
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 05:56:47 -0500

That's a good use case.  It's certainly useful.  There are some issues to resolve, but those are minor.  I think that this can be resolved with the responseTime attribute and the event rate control mechanism.

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, 28 July 2009 12:20 PM
> To: 'James M. Polk'; Thomson, Martin; [email-masked]
> Subject: RE: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> filters-05.txt
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 07:01:01 -0500

Current SIP rules for SUBSCRIBE are that when the subscription is 
accepted, a NOTIFY is sent immediately (containing the current state 
of what the subscribed-to entity knows about the subscription event). 
If the subscription is to last "over time", then additional NOTIFYs 
are sent when new changes to the "event" occur.

This, I don't believe, is something Conveyance has to account for, 
but PhoneBCP certainly does. If can be as simple as having text 
saying that subscriptions for dereferences need to last for 15 or 
more seconds (i.e., enough to get that second location update from 
"the system"), but it cannot be completely open ended.  This should 
cover the concept.

Do you agree?

James

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 07:03:01 -0500

At 05:56 AM 7/28/2009, Thomson, Martin wrote:
>That's a good use case.  It's certainly useful.  There are some 
>issues to resolve, but those are minor.  I think that this can be 
>resolved with the responseTime attribute and the event rate control mechanism.

or... the subscription can be left open for the subsequent location 
update in a subsequent NOTIFY, which is easier, and covers non HELD 
cases - which any mechanism needs to.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 07:03:08 -0500

With responseTime, the subscription should be open for long enough for a real notification to get through.  That's probably whatever value emergencyDispatch has in the jurisdiction, which might be 15 seconds, or something else.

> Behalf Of James M. Polk
> Sent: Tuesday, 28 July 2009 2:01 PM
> Subject: Re: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> filters-05.txt
> 
> you
> already

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 07:12:47 -0500

The notifier still needs to know how long it has got.  Otherwise, it might not provide a dispatch-worthy location when it's needed.  responseTime gives it that.  Sure, event-rate-control can do this with max-interval, but it would also require that the subscription be updated to prevent an excessive rate.  

In particular, the required responseTime might be lower than the notifier is willing to accept in max-interval.  If you want a response in less than 2s, using max-interval is likely to fail.  This gives the notifier the control it needs without running afoul of event-rate constraints.

Further, keep in mind that responseTime has a hidden use - that of notifying the LG of how long it has.  This helps the LG select the appropriate method so the information is available on time.  This can also be applied to later notifications where the notifier needs to go to an LG.

--Martin

> Sent: Tuesday, 28 July 2009 2:03 PM
> To: Thomson, Martin; Hannes Tschofenig; [email-masked]
> > > The SIP proxy gets a location URI via SIP. Now, it wants todo
> location
> > > based
> > > routing for the emergency call. It will dereference the location
> URI as
> > > you
> > > determine location at a best possible extend. This takes time.
> Then,
> > > when
> > > location is available the NOTIFY is sent. The SIP proxy can route
> the
> > > call
> > > but had to wait longer (potentially longer than Brian states in
> Phone
> > > BCP
> > > what type of reference the URI should point to (this relates a bit
> to
> > > the
> > > HELD context document). And the same stuff is available in HELD
> deref
> > > as
> > > well.
> > >
> > > draft-ietf-geopriv-loc-filters-05.txt as well. Namely, to let the
> SIP
> > > proxy
> > > >><http://tools.ietf.org/html/draft-thomson-simple-cont-presence-
> >va
> > > >> >> >l
> > > >> >> -req-02#section-4.6.1.1>
> > > >> >> >

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 16:50:53 -0500

At 07:03 AM 7/28/2009, Thomson, Martin wrote:
>With responseTime, the subscription should be open for long enough 
>for a real notification to get through.  That's probably whatever 
>value emergencyDispatch has in the jurisdiction, which might be 15 
>seconds, or something else.

I fully agree with this (i.e., that it needs to be confirugurable 
-  because it will depend on the local <everything> - and can't 
really, accurately be be defined in one of our docs, at least not yet).

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 16:58:48 -0500

At 07:12 AM 7/28/2009, Thomson, Martin wrote:
>The notifier still needs to know how long it has got.  Otherwise, it 
>might not provide a dispatch-worthy location when it's 
>needed.  responseTime gives it that.  Sure, event-rate-control can 
>do this with max-interval, but it would also require that the 
>subscription be updated to prevent an excessive rate.

this is why I think guidance can be said here, but no realistic 
minimums or maximums.

I also believe fully that phoneBCP must account for the subscribed-to 
entity that does not support filters; meaning only having a non-zero 
Expire header be what's counted on.

After the PSAP receives location in a request, it'll probably 
initiate its own subscription anyway to get updates. This is more 
where the filters doc comes into play IMO.

>In particular, the required responseTime might be lower than the 
>notifier is willing to accept in max-interval.  If you want a 
>response in less than 2s, using max-interval is likely to 
>fail.  This gives the notifier the control it needs without running 
>afoul of event-rate constraints.
>
>Further, keep in mind that responseTime has a hidden use - that of 
>notifying the LG of how long it has.  This helps the LG select the 
>appropriate method so the information is available on time.  This 
>can also be applied to later notifications where the notifier needs 
>to go to an LG.

isn't the notifier and the LG the same entity in this case (i.e., in 
both cases - this entity is the same LIS)?

The subscriber may (and probably does) change, but always to the same LIS.

> > > > >><http://tools.ietf.org/html/draft-thomson-simple-cont-presence-> >va
> > > > >> >> >l
> > > > >> >> -req-02#section-4.6.1.1>
> > > > >> >> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Jul 2009 00:27:24 -0500

Brian and I discussed this problem of responseTime at some length yesterday and here's what we came up with.  We both think that it's simple, elegant and the appropriate place to do this.

Problem:

When the subscription is made, the notifier doesn't necessary have location available.  Thus, the first notification might be empty, or certain values might be absent.  Because location generation can take arbitrary amounts of time, something like responseTime is useful - it provides the location generator/presence source with some constraints - otherwise it might take an inappropriate length of time to get what it needs.

Solution:

If we specify responseTime in the filter, not only does it suffer from a bad smell, it interacts badly with event-rate-control.  So what we do is specify another parameter in the event rate control header, that identifies how long the client is willing to wait for the _first_ full notification.

Things to note:

An alternative would be to use min-interval.  However, if a response is desired in 3 seconds, this results in forcing a notification every 3 seconds indefinitely.  That's inconvenient if the long term value for this parameter is something different - and I can imagine this being the case.  The subscription would need to be updated after the first notification.  Furthermore, low times might be rejected by policy in the notifier - 3 seconds is likely to be much lower than the notifier is willing to tolerate anyhow.

This new parameter is more important than max-interval (the throttling parameter).  If the clients wants to throttle notifications down to one every 20 seconds, they are still able to specify a value for this new parameter that is lower than this.

What's left:

We need to discuss with the authors of event-rate-control and work out whether it makes sense for that document to include the new parameter, or whether it would be better to create a new document.  I spoken with one of the authors, who in principle understands the concept, but we'll have to work with these guys more closely.

--Martin

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Jul 2009 09:23:14 +0300

Hi Martin, 

>That's a good use case.  It's certainly useful.  There are 
>some issues to resolve, but those are minor.  I think that 
>this can be resolved with the responseTime attribute and the 
>event rate control mechanism.

How do you see the event rate mechanism being useful here given that in a
previous mail you argued it is not needed? 

Ciao
Hannes

>> The SIP proxy gets a location URI via SIP. Now, it wants 
>todo location 
>> based routing for the emergency call. It will dereference 
>the location 
>> URI as you mention in Section 4.5 of your document. The LIS does not 
>> know that this is request is only for location sufficient 
>for routing 
>> and it tries to determine location at a best possible extend. This 
>> takes time. Then, when location is available the NOTIFY is sent. The 
>> SIP proxy can route the call but had to wait longer (potentially 
>> longer than Brian states in Phone BCP regarding the maximum 
>call setup 
>> time).
>> 
>> If I understood the HELD mechanism correctly then there is a way to 
>> indicate what type of reference the URI should point to 
>(this relates 
>> a bit to the HELD context document). And the same stuff is available 
>> in HELD deref as well.
>> 
>> draft-ietf-geopriv-loc-filters-05.txt as well. Namely, to 
>let the SIP 
>> proxy tell the LIS when it sends a SUBSCRIBE that it wants location 
>> for routing (and that typically means faster>
>> 
>> >> >> >things
>> >>What "indication" is used in a SIP SUBSCRIBE to indicate "Please 
>> >>give me location information suitable for routing."?
>> >
>given (if 
>> >not) the PIDF-LO of the Target, then processes the message (i.e., 
>> >making routing decisions) as if it were sent the PIDF-LO in the 
>> >original SIP request. There's no magic to a location URI to get a 
>> >routable location vs. an unroutable location -- especially since 
>> >there is no difference in our that same proxy receives location by 
>> >value.
>> >

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Jul 2009 09:35:59 +0300

Hi Martin, Hi Brian, 

Thanks for discussing this issue face-to-face. 

I don't have a problem to shuffle the parameter into another document,
namely the event-rate-control document in this case. 

Let me know when you discuss this with the authors of event-rate-control. I
would then remove it from this document. 

Ciao
Hannes

>Sent: 29 July, 2009 08:27
>To: James M. Polk; Hannes Tschofenig; [email-masked]
>Brian and I discussed this problem of responseTime at some 
>length yesterday and here's what we came up with.  We both 
>think that it's simple, elegant and the appropriate place to do this.
>
>Problem:
>
>When the subscription is made, the notifier doesn't necessary 
>have location available.  Thus, the first notification might 
>be empty, or certain values might be absent.  Because location 
>generation can take arbitrary amounts of time, something like 
>responseTime is useful - it provides the location 
>generator/presence source with some constraints - otherwise it 
>might take an inappropriate length of time to get what it needs.
>
>Solution:
>
>If we specify responseTime in the filter, not only does it 
>suffer from a bad smell, it interacts badly with 
>event-rate-control.  So what we do is specify another 
>parameter in the event rate control header, that identifies 
>how long the client is willing to wait for the _first_ full 
>notification.
>
>Things to note:
>
>An alternative would be to use min-interval.  However, if a 
>response is desired in 3 seconds, this results in forcing a 
>notification every 3 seconds indefinitely.  That's 
>inconvenient if the long term value for this parameter is 
>something different - and I can imagine this being the case.  
>The subscription would need to be updated after the first 
>notification.  Furthermore, low times might be rejected by 
>policy in the notifier - 3 seconds is likely to be much lower 
>than the notifier is willing to tolerate anyhow.
>
>This new parameter is more important than max-interval (the 
>throttling parameter).  If the clients wants to throttle 
>notifications down to one every 20 seconds, they are still 
>able to specify a value for this new parameter that is lower than this.
>
>What's left:
>
>We need to discuss with the authors of event-rate-control and 
>work out whether it makes sense for that document to include 
>the new parameter, or whether it would be better to create a 
>new document.  I spoken with one of the authors, who in 
>principle understands the concept, but we'll have to work with 
>these guys more closely.
>
>--Martin