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
