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
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
