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
