1) The functions provided by event-rate-control are useful in the context of location. However, that doesn't say anything about whether loc-filters needs to include a reference, directly or otherwise.
My current opinion is that loc-filters should avoid dealing with these issues. That means responseTime remains out of scope.
~~
2) responseTime is intrinsically linked to event rate control. As Brian pointed out, this is about that first _complete_ NOTIFY (what you refer to as the second NOTIFY). Min-interval throttles this, perhaps unnecessarily.
We discussed this on and off with Adam Roach. Adam suggested that we could use max-interval to force this NOTIFY. On face value, that works quite well, but it smells off to me.
a) The min-interval throttling interacts with this and max-interval must be greater than min-interval. Therefore, a low value of min-interval must also be specified for the first NOTIFY.
b) After first notification the "special" behaviour must be reverted; here, Adam suggested using the 200 response to the NOTIFY to convey updated values*.
c) The notifier/PA might not be willing to support appropriately low values of max-interval. I think that this is the showstopper. (Note that it can't assume that the watcher is going to update intervals after the first NOTIFY.)
d) The quality semantic provided by responseTime is lost. I don't care so much about this as much because a subscription provides the means to avoid the need to this parameter, but it's still nice to have. One advantage of having an explicit tag is that it carries a strong semantic: "responseTime" means "only take this long to generate (location) information", which still has some value in a subscription.
* There's an issue here where the watcher doesn't get informed of the final values until the next NOTIFY, but we agreed that's minor enough to worry about.
~~
3) I get the impression that we're looking at different use cases when you make this suggestion. I almost made an entirely opposite suggestion. Values in seconds are still very useful...outside of emergency use cases, of course.
~~
I'm thinking that a concrete proposal is needed. I might write one up.
--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Saturday, 8 August 2009 3:02 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] Making progress with the responseTime in loc-filters
>
> Hi all,
>
> I would like to conclude the responseTime discussion and close an open
> issue with the current document. For this purpose, I need your
> feedback.
>
> Here are the issues I can see:
>
> 1) REFERENCE TO SIPCORE-EVENT-RATE-CONTROL
>
> Based on the suggestion by Martin some time back I removed any
> reference
> to sipcore-event-rate-control.
>
> sipcore-event-rate-control is only be needed if we want functionality
> like
>
> -- "Send me location updates with a minimum time
> period between two notifications".
>
> -- "Send me location updates with a maximum time period
> between two notifications."
>
> Currently, we make the notifications dependent on the degree of
> location
> change.
>
> Do we really need the functionality defined in
> http://tools.ietf.org/html/draft-ietf-sipcore-event-rate-control-00 for
> this document?
>
>
> 2) RESPONSETIME ATTRIBUTE
>
> This has triggered some discussion and my current understanding (and I
> was not at the IETF meeting and hence did not participate in the
> hall-way conversations etc. etc.) is the following:
>
> Martin does not like 'responseTime' to be an XML attribute of the
> <locationType> element. Fine. Not a big issue.
>
> How are notifications sent when someone sets
> responseTime="emergencyRouting" or responseTime="emergencyDispatch" but
> the LIS is unable to provide the requested location immediately (which
> is quite likely in many environments)?
>
> Here is a figure:
>
> Location
> Recipient LIS
> |-----SUBSCRIBE---->| Request state subscription
> |<-------200--------| Acknowledge subscription
> |<------NOTIFY-(1)- | Return current state information
> |--------200------->|
> |<------NOTIFY-(2)- | Return current state information
> |--------200------->|
>
>
> My reading of RFC 3265 is that a SIP NOTIFY (1) is sent immediately in
> response to the initial SUBSCRIBE and may contain an empty body.
>
> Then, when location is available (as desired) another NOTIFY (2) is
> sent. This then contains the desired answer.
>
> Why aren't we happy with this behavior?
>
> We could obviously make this behavior more explict in the document.
>
> 3) NUMERICAL VALUES IN RESPONSETIME
>
> The labels "emergencyRouting" and "emergencyDispatch" make a lot of
> sense for our purpose. When it comes to the numerical values I am less
> clear whether we need them in the loc-filters document. Here is the
> text
> from the HELD document (Section 6.1 of
> http://www.ietf.org/id/draft-ietf-geopriv-http-location-delivery-
> 15.txt)
> :
>
> The "responseTime" attribute includes a time value
> indicating to the LIS how long the Device is prepared to wait for a
> response or a purpose for which the Device needs the location.
>
> So, do we need this functionality?
>
> Ciao
> Hannes
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
