>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
