Assuming that responseTime only pertains to response time, it might be reasonable for a client to make certain assumptions about the two emergency tags and use them accordingly.
I know that already emergencyRouting is used to mean "just long enough to get basic location". Nothing prevents a similar assumption about emergencyDispatch (i.e. "just long enough to get really good location").
Nothing in the contract states that doing this risks degraded service. An explicit service tag would provide an explicit indication to the client that the LIS might have done something special to the result for that service. The semantics could state that the location is (potentially) only useful for that service.
--Martin
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Wednesday, 3 June 2009 11:26 AM
> To: Thomson, Martin
> Cc: Rosen, Brian; geopriv@ietf.org
> Subject: Re: [Geopriv] HELD ResponseTime parameter with value
> emergencyRouting
>
> On the other hand, a HELD request places no constraints on what shape
> 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
> >
------------------------------------------------------------------------------------------------
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
