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
>-----Original Message-----
>From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
>Sent: 29 July, 2009 08:27
>To: James M. Polk; Hannes Tschofenig; geopriv@ietf.org
>Subject: RE: [Geopriv] Another Update to
>draft-ietf-geopriv-loc-filters-05.txt
>
>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
>---------------------------------------------------------------
>---------------------------------
>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
