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.
On ResponseTime, more work is needed, and I think we need an author proposal
to chew over.
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
