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
