>Okay, you want it on list. No problem.
Maybe someone else has some good thoughts.
>
>We WILL use the rate control mechanism. However, this
>interacts with ResponseTime.
Well. In your previous mail you said that sipcore-event-rate-control is
an informative reference. With this statement it does not seem to be
that way.
I don't even think that sipcore-event-rate-control makes sense for our
application usage.
Here are the use cases we wanted to cover (and those do not require the
functionality from sipcore-event-rate-control):
1. the Target moves more than a specified distance since the last
notification
2. the Target exceeds a specified speed
3. the Target enters or exits a region (described by a circle or a
polygon)
4. one or more of the values of the specified address labels have
changed for the location of the Target. For example, the value
of the <A1> civic address element has changed from 'California'
to 'Nevada'.
5. the type of location information being requested.
We limit the number of notifications by utilizing location semantic not
via min/max/avg indication.
>ResponseTime, in HELD is a quality request: it's a hint to the
>server of what kind of mechanisms the server may use, and how
>it should use them, in order to achieve the desired response
>time.
I agree.
The "symbolic label" (namely responseTime="emergencyRouting" or
responseTime="emergencyDispatch") probably cover most of the cases we
care about.
>The normal use really is seconds, and I would not wish
>to see this restricted to just the defined special values for
>emergencies.
Might be interesting to know what application developers like to use
more.
>
>The rate control mechanism has what we basically need:
>min/max/average notification rate.
Not at all. From the previous discussion this does not really follow.
>
>However, there is a problem, specific to location, which
>derives from the problem that the FIRST response often takes
>longer that subsequent responses.
The first response to the SUBSCRIBE comes immediately (and it might be
empty).
>That means the "minimum"
>thing is "ResponseTime" for the first, but not subsequent
>notifications. To put it another way, we need a way to
>specify the (minimum) time to get the first response, and then
>the minimum time before the next notification must be sent.
>That can't be done with rate control as is.
I agree with you when someone wants to use sipcore-event-rate-control in
combination with the loc-filters document. This only makes sense when
the functionality in loc-filters is largely not used (expect for the
responseTime parameter). Why would someone use, for example, the the
Target enters or exits a region functionality in combination with a
min/max/avg rate limiting mechanism?
My current thinking is that we are adding functionality that makes the
entire implementation more complex without a lot of added value.
>
>So, either we need to enhance the rate control mechanism to
>let us specify first and subsequent "force" (minimum) values,
>or we use responseTime to specify the first notify time and
>rate control for subsequent ones. The latter, to me is
>"yuck". The former requires the authors (and work group) for
>rate control to agree.
I prefer the first (requiring changes only to
sipcore-event-rate-control) and particuarly not demand that anyone uses
sipcore-event-rate-control with loc-filters other than an optional
feature.
>
>But "responseTime" is really a proxy for a request for a
>particular quality.
>It's "give me the best quality location I can get in this much
>time". We really would like a filter on quality, with the
>caveat that we have to deal with an overspecified set of
>filters that the server can't meet.
For me, there is also the question about how the responseTime parameter
(in HELD and also in this loc-filters document) align with
http://tools.ietf.org/id/draft-thomson-geopriv-location-quality-04.txt
(which is yet another optional extension).
Ciao
Hannes
>
>Brian
>
>
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Friday, August 07, 2009 2:53 PM
>> To: 'Brian Rosen'; Tschofenig, Hannes (NSN - FI/Espoo);
>> geopriv@ietf.org
>> Subject: RE: [Geopriv] Making progress with the responseTime in loc-
>> filters
>>
>> >On the rate control reference, while I would like to see the
>> >reference to call attention, it could be informative, and isn't
>> >required; one can use the rate control to achieve the purpose you
>> >describe, and no further mechanism is required.
>>
>> Informative references sound nice but then you have options that
>> someone could implement and someone has to check whether
>there is some
>> undesired interaction with other functionality, such as with
>> responseTime.
>>
>> >
>> >On ResponseTime, more work is needed, and I think we need an author
>> >proposal to chew over.
>>
>> I don't see what additional work is need other than
>describing what I
>> listed below and to move the attribute into an element.
>>
>> >
>> >Working on it.
>> >
>> >Brian
>> >
>> >> -----Original Message-----
>> >> From: geopriv-bounces@ietf.org
>[mailto:geopriv-bounces@ietf.org] On
>> >> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>> >> Sent: Friday, August 07, 2009 1:02 PM
>> >> 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
>> >
>> >_______________________________________________
>> >Geopriv mailing list
>> >Geopriv@ietf.org
>> >https://www.ietf.org/mailman/listinfo/geopriv
>> >
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
