We WILL use the rate control mechanism. However, this interacts with
ResponseTime.
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. The normal use really is
seconds, and I would not wish to see this restricted to just the defined
special values for emergencies.
The rate control mechanism has what we basically need: min/max/average
notification rate.
However, there is a problem, specific to location, which derives from the
problem that the FIRST response often takes longer that subsequent
responses. 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.
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.
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.
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
