the LIS returns, so in principle, a LIS could use the responseTime
parameter as an input. This could happen even in non-emergency cases,
e.g., if it would return a sector for a fast lookup and an error ellipse
with A-GPS.
The risk that goes along with this is that the endpoint might use the
location for non-emergency services, and thus obtain a lower quality of
service is the location is less precise/accurate.
--Richard
Thomson, Martin wrote:
> The problem here is that Brian seems able to interpret this text to attach additional meaning to the emergencyRouting and emergencyDispatch tags. I had thought that the text was clear enough, but it seems that Brian has been harbouring an alternative interpretation for a while now.
>
> We discussed the option of a separate service indicator. In fact, I was in favour of such, but this approach was chosen - I thought - because we only wanted to address the _response time_ problem in relation to emergency services.
>
> The dogmatic position is that response time is response time and it doesn't say anything about anything else.
>
> Conflation of semantics is bad engineering.
>
> --Martin
>
> p.s. Wow, two misspellings of my name in less than 2 minutes. I agree with Marc, but not you. You get the response. Marc does seem to be talking to someone else entirely though...
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Rosen, Brian
>> Sent: Wednesday, 3 June 2009 10:42 AM
>> To: geopriv@ietf.org
>> Subject: [Geopriv] HELD ResponseTime parameter with value
>> emergencyRouting
>>
>> In NENA, there is a discussion on the best form (shape) to send to the
>> LoST server when the shape is a cell sector. The discussion itself is
>> pretty specific to NENA, although it involves the fact that it might be
>> necessary for the LIS to choose the shape of the response for emergency
>> routing that might be different than it would return for other
>> purposes.
>>
>>
>> Martin Thompson is worried about something that I seek advice on.
>>
>> The wording choice for ResponseTime in HELD is:
>> 6.1. "responseTime" Parameter
>>
>> The "responseTime" attribute MAY be included in a location request
>> message. 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.
>>
>> In the case of emergency services, the purpose of obtaining the LI
>> could be either for routing a call to the appropriate PSAP or
>> indicating the location to which responders should be dispatched.
>> The values defined for the purpose, "emergencyRouting" and
>> "emergencyDispatch", will likely be governed by jurisdictional
>> policies, and should be configurable on the LIS.
>>
>> Please note the construction of the last sentence of the first
>> paragraph
>> about "purpose".
>>
>> I claim that it is perfectly reasonable to expect the LIS to construct
>> a
>> PIDF suitable for the purpose of emergency routing when it encounters
>> the emergencyRouting value in responseTime, and the fact that it is in
>> the "responseTime" parameter doesn't limit the LIS from sending an
>> appropriate PIDF content as well as within an appropriate time limit.
>> The LIS knows the purpose, and can reasonably be expected to respond
>> appropriately in both time and content. Otherwise, we would need
>> another parameter to ask for the right content, which is silly.
>>
>> I have been okay with the current wording because I believed that the
>> LIS could use the emergencyRouting (or emergencyDispatch for that
>> matter) as an all purpose "purpose" (as it were) and wasn't hung up on
>> the fact that it's in the responseTime parameter.
>>
>> Am I wrong?
>>
>> Brian
>> _______________________________________________
>> 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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
