services case (i.e., urn:service:sos), so my inclination would be to
avoid going down that path.
--Richard
Winterbottom, James wrote:
> My feelings are that is you want to constrain shapes based on service
> type then you can write an HELD extension that introduces a new
> attribute that can be include din the location request. You can then
> have an IANA registry for the service tags, or, more sensibly, you can
> resuse the IANA service URN registry that LoST has set up and send these
> values to the LIS.
>
> Cheers
> James
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf
>> Of Thomson, Martin
>> Sent: Wednesday, 3 June 2009 11:02 AM
>> To: Rosen, Brian; geopriv@ietf.org
>> Subject: Re: [Geopriv] HELD ResponseTime parameter with
>> valueemergencyRouting
>>
>> 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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
