Subject: [Geopriv] HELD Emergency Text

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 1 Oct 2007 20:19:23 -0500

Hi All,

Here is my suggested text for a HELD emergency section.

Cheers
James

One use of HELD allows a Target to acquire location information suitable
for use with emergency services. This includes both the requesting and
supplying of location information suitable for routing an emergency call
to the local PSAP, and location information to which emergency crews can
be dispatched. The following paragraphs describe how HELD is used to
request location information for use with emergency applications.

A request for location information to be used with emergency
applications MUST NOT contain an exact attribute with a value of true.
It is RECOMMENDED that a request for emergency location information not
qualify the location type in the request. The LIS MUST ignore the value
of the exact attribute if the responseTime is set to emergencyRouting or
emergencyDispatch.

The responseTime SHOULD be set to emergencyRouting where the location is
requested at emergency call time and being used for routing. The
responseTime SHOULD be set to emergencyDispatch if the location
information is to be used for providing direction to emergency crews. A
responseTime of emergencyDispatch MAY be used at system startup time and
periodically there after, but SHOULD NOT be used to request location
information at call time.

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: <[email-masked]>
Date: Mon, 1 Oct 2007 21:43:43 -0400

James,

This is good. Is the responseTime parameter mandatory for ES then?

Also, if you consider having a specific section for ES, you may want to move this text from section 6.1:
"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 time values defined for those    purposes, emergencyRouting and emergencyDispatch, will likely be governed by jurisdictional policies, and SHOULD be configurable on the LIS."

Furthermore, related to HTTPS vs HTTP, should there be some text stating that for ES applications, if HTTPS fails, try HTTP (à la SIP)?

Thanks,

Guy Caron
-----Message d'origine-----
De : Winterbottom, James [mailto:[email-masked]] 
Envoyé : 1 octobre 2007 21:19
À : [email-masked]
Objet : [Geopriv] HELD Emergency Text

Hi All,

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 1 Oct 2007 20:51:04 -0500

Hi Guy,

Inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, 2 October 2007 11:44 AM
> To: Winterbottom, James; [email-masked]
> Subject: RE: [Geopriv] HELD Emergency Text
> 
> James,
> 

[AJW] Yes I think it should be.

> "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 time values defined
> for those    purposes, emergencyRouting and emergencyDispatch, will likely
> be governed by jurisdictional policies, and SHOULD be configurable on the
> LIS."
>
[AJW] Agreed

> Furthermore, related to HTTPS vs HTTP, should there be some text stating
> that for ES applications, if HTTPS fails, try HTTP (à la SIP)?
>
[AJW] Hmmm.... I am not sure that same applies necessarily. For location the intent is that you try an acquire it ahead of time, so if you can't get it at call time you still have something. So may be it is reasonable to say something to the effect that if you can't get location at boot time due to TLS issues, the Target may attempt a location request without using a secure connection. I don't think that at call time I would bother to try a second time to get location, if I couldn't connect I would go with what I had.

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 2 Oct 2007 08:26:06 -0400

Is this text intended for the HELD draft? Does some of it belong more in
phonebcp than HELD? Specifically, the last paragraph seems more bcp-like
than protocol specification.

For the last paragraph, I believe that any device capable of making
emergency calls that is making a HELD query to get its location at
system startup MUST do so with responseTime set to emergencyDispatch.

As for not using emergencyDispatch when making an emergency call, I
don't think this is quite right. I think we would want both an
emergencyDispatch and emergencyRouting query at call time. The
emergencyRouting value would be used for routing, and the
emergencyDispatch would update the currently saved Dispatch location.

If this is what we want it brings up a few other questions for me. But I
think those questions apply to phonebcp, and not HELD (which would mean
ecrit and not geopriv). So, I await other opinions as to whether
phonebcp will pick up the recommendations of the last paragraph.
Barbara

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 9:19 PM
To: [email-masked]
Subject: [Geopriv] HELD Emergency Text

Hi All,

Cheers
James

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 2 Oct 2007 14:36:53 +0200

Agree.

Putting this in HELD in this form is inconsistent with the agreements we
already made on sip-location-conveyance in regard to emergency call
material.

Essentially the HELD document should make sure that all the emergency
call requirements can be met, i.e. that emergency call usage of HELD is
conformant with HELD itself, but the specifics of using HELD for an
emergency call should be in an ECRIT document. 

Regards

Keith

> From: Stark, Barbara [mailto:[email-masked]] 
> Sent: Tuesday, October 02, 2007 1:26 PM
> Is this text intended for the HELD draft? Does some of it 
> belong more in phonebcp than HELD? Specifically, the last 
> paragraph seems more bcp-like than protocol specification.
> 
> For the last paragraph, I believe that any device capable of 
> making emergency calls that is making a HELD query to get its 
> location at system startup MUST do so with responseTime set 
> to emergencyDispatch.
> 
> As for not using emergencyDispatch when making an emergency 
> call, I don't think this is quite right. I think we would 
> want both an emergencyDispatch and emergencyRouting query at 
> call time. The emergencyRouting value would be used for 
> routing, and the emergencyDispatch would update the currently 
> saved Dispatch location.
> 
> If this is what we want it brings up a few other questions 
> for me. But I think those questions apply to phonebcp, and 
> not HELD (which would mean ecrit and not geopriv). So, I 
> await other opinions as to whether phonebcp will pick up the 
> recommendations of the last paragraph.
> Barbara
> 
> One use of HELD allows a Target to acquire location 
> information suitable for use with emergency services. This 
> includes both the requesting and supplying of location 
> information suitable for routing an emergency call to the 
> local PSAP, and location information to which emergency crews 
> can be dispatched. The following paragraphs describe how HELD 
> is used to request location information for use with 
> emergency applications.
> 
> It is RECOMMENDED that a request for emergency location 
> information not qualify the location type in the request. The 
> LIS MUST ignore the value of the exact attribute if the 
> responseTime is set to emergencyRouting or emergencyDispatch.
> 
> The responseTime SHOULD be set to emergencyRouting where the 
> location is requested at emergency call time and being used 
> for routing. The responseTime SHOULD be set to 
> emergencyDispatch if the location information is to be used 
> for providing direction to emergency crews. A responseTime of 
> emergencyDispatch MAY be used at system startup time and 
> periodically there after, but SHOULD NOT be used to request 
> location information at call time.
> 
>  
> The information transmitted is intended only for the person 
> or entity to which it is addressed and may contain 
> confidential, proprietary, and/or privileged material. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. GA625
> 
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Oct 2007 14:46:02 +0200

I agree with Keith.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 2 Oct 2007 08:57:15 -0400

I also agree and will put this text in -phonebcp.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2007 8:46 AM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Geopriv] HELD Emergency Text
> 
> I agree with Keith.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 2 Oct 2007 09:02:52 -0400

> than protocol specification.
As in the other part of this thread, I agree it goes in -phonebcp

> system startup MUST do so with responseTime set to emergencyDispatch.
Yes, I would think so too

> emergencyDispatch would update the currently saved Dispatch location.
Well, I think that's complicated.

First of all, the minimum sequence is emergencyRouting and send the call.
UPDATE location later if you need to.

Question to James et. al. on a reference: Do you ever think something like
the notion of emergencyRouting/Dispatch would get encoded in the reference?
I hope not.

Then you could ask for both, but you need to do that in separate requests so
that the response to the Routing request comes in as soon as it's ready.

And of course if you get both, and you have them before you send the call
(meaning they come in quickly), then you want to use and send Dispatch and
discard Routing unless there is an error.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 2 Oct 2007 09:05:25 -0400

> [AJW] Hmmm.... I am not sure that same applies necessarily. For location
> the intent is that you try an acquire it ahead of time, so if you can't
> get it at call time you still have something. So may be it is reasonable
> to say something to the effect that if you can't get location at boot time
> due to TLS issues, the Target may attempt a location request without using
> a secure connection. I don't think that at call time I would bother to try
> a second time to get location, if I couldn't connect I would go with what
> I had.
I think this is wrong.  You don't know if the device is mobile.  The device
doesn't know it's mobile.  There is nothing that tells it its mobile.  

Therefore the importance of updated, current location is much more important
than you are implying, and I think you must retry with http.

Brian

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 2 Oct 2007 10:36:02 -0400

I believe that the following statement (from James' recommended text)
does belong in HELD:

The LIS MUST ignore the value of the exact attribute if the responseTime
is set to emergencyRouting or emergencyDispatch. 

Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 8:57 AM
To: 'Hannes Tschofenig'; 'DRAGE, Keith (Keith)'
Cc: [email-masked]
Subject: RE: [Geopriv] HELD Emergency Text

Brian

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 2 Oct 2007 11:35:19 -0500

And, I also agree with you all.  I think the only text than needs to be
in HELD is in the detailed attribute sections describing normative
behavior. I think the sentences in the middle paragraph could possibly
be put into the appropriate sections of the HELD spec, but I think it
really all belongs in phone-bcp.

Thanks,
Mary. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 7:57 AM
To: 'Hannes Tschofenig'; 'DRAGE, Keith (Keith)'
Cc: [email-masked]
Subject: RE: [Geopriv] HELD Emergency Text

Brian

> > Putting this in HELD in this form is inconsistent with the 
> > agreements we already made on sip-location-conveyance in regard to 
> > emergency call material.
> >
> > Essentially the HELD document should make sure that all the 
> > emergency call requirements can be met, i.e. that emergency call 
> > usage of HELD is conformant with HELD itself, but the specifics of 
> > using HELD for an emergency call should be in an ECRIT document.
> >
> > Regards
> >
> > Keith
> >
> >
> >> Is this text intended for the HELD draft? Does some of it belong 
> >> more in phonebcp than HELD? Specifically, the last paragraph seems 
> >> more bcp-like than protocol specification.
> >>

> >> If this is what we want it brings up a few other questions for me. 
> >> But I think those questions apply to phonebcp, and not HELD (which 
> >> would mean ecrit and not geopriv). So, I await other opinions as to

> >> whether phonebcp will pick up the recommendations of the last 
> >> paragraph.
> >> Barbara
> >>
> >> One use of HELD allows a Target to acquire location information 
> >> suitable for use with emergency services. This includes both the 
> >> requesting and supplying of location information suitable for 
> >> routing an emergency call to the local PSAP, and location 
> >> information to which emergency crews can be dispatched. The 
> >> following paragraphs describe how HELD is used to request location 
> >> information for use with emergency applications.
> >>
> >> It is RECOMMENDED that a request for emergency location information

> >> not qualify the location type in the request. The LIS MUST ignore 
> >> the value of the exact attribute if the responseTime is set to 
> >> emergencyRouting or emergencyDispatch.
> >>
> >> location is requested at emergency call time and being used for 
> >> routing. The responseTime SHOULD be set to emergencyDispatch if the

> >> location information is to be used for providing direction to 
> >> emergency crews. A responseTime of emergencyDispatch MAY be used at

> >> system startup time and periodically there after, but SHOULD NOT be

> >> used to request location information at call time.
> >>
> >>
> >> This message is for the designated recipient only and may contain 
> >> privileged, proprietary, or otherwise private information.
> >> immediately and delete the original.  Any unauthorized use of this 
> >> email is prohibited.
> >> The information transmitted is intended only for the person or 
> >> entity to which it is addressed and may contain confidential, 
> >> proprietary, and/or privileged material. Any review, 
> >> retransmission, dissemination or other use of, or taking of any 
> >> action in reliance upon this information by persons or entities 
> >> other than the intended recipient is prohibited. If you received 
> >> this in error, please contact the sender and delete the material 
> >> from all computers. GA625
> >>
> >>
> >>
> >>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Oct 2007 15:34:35 -0500

Inline
Clipped to the relevant section.

> the notion of emergencyRouting/Dispatch would get encoded in the

[AJW] Assuming I understand what you mean, I don't think they are
encoded into the reference. If I am using HELD as the dereference
protocol for an HTTP URI then I can certainly specify a responseTime of
emergencyROuting or emergencyDispatch and I think that this needs to be
allowed.

> 
> Then you could ask for both, but you need to do that in separate
requests
> so

[AJW] I am not sure eat this point if you are suggesting that this is a
good thing or not. I think what you are trying to do is to tell the LIS
that an emergencyDispatch request will be coming soon, so start getting
ready now. We don't have a way to do this yet.
 
> discard Routing unless there is an error.

[AJW] I agree with this last bit.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Oct 2007 15:36:07 -0500

I am okay with this.
Is it okay to have a reference from HELD to phone-BCP then saying see
that document over there for emergency semantics?

The only reason that I proposed this section for the HELD document
itself was that there seemed to be confusion based on comments from the
list.

Cheers
James

> Sent: Tuesday, 2 October 2007 10:57 PM
agreements
> we
emergency
> > > call requirements can be met, i.e. that emergency call usage of
HELD
> is

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 3 Oct 2007 11:35:05 -0400

Okay, I agree.  The dereference operation itself specifies its own
ResponseTime, you only have one ResponseTime, so getting emergencyRouting
and emergencyDispatch can't be done with one request.  You request one, wait
for the response, then make the other request.

Brian

> Sent: Tuesday, October 02, 2007 4:35 PM
> To: Brian Rosen; Stark, Barbara; [email-masked]

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 3 Oct 2007 11:56:23 -0400

Why do you have to wait for the response to the first request, before
making the 2nd request? Why can't they be sent at the same time? Is it
not possible to determine which request a response is for?
Barbara 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 11:35 AM
To: 'Winterbottom, James'; Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] HELD Emergency Text

Okay, I agree.  The dereference operation itself specifies its own
ResponseTime, you only have one ResponseTime, so getting
emergencyRouting
and emergencyDispatch can't be done with one request.  You request one,
wait
for the response, then make the other request.

Brian

> > Question to James et. al. on a reference: Do you ever think
something
> like
> > (meaning they come in quickly), then you want to use and send
Dispatch
> and
--
> ----------------------
--
> ----------------------

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Richard Barnes <[email-masked]>
Date: Wed, 03 Oct 2007 12:06:04 -0400

> You request one, wait

Not to nitpick, but can't the two be done in parallel?
--RB

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 3 Oct 2007 12:06:52 -0400

Oh, you probably can.  More thread hacking.
You can't literally do it on the same thread, because you block on the read
for the first response.  You can spin off two threads, one for each request,
and get what you want.

It's probably not much more work than dealing with the 30 second response to
begin with.

Brian

> Sent: Wednesday, October 03, 2007 11:56 AM
> To: Brian Rosen; Winterbottom, James; [email-masked]
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA621

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 3 Oct 2007 16:13:07 -0500

Yes they can be done in parallel, or even sequentially down the same
pipe.
But you on have one responseTime in each request.

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Thursday, 4 October 2007 2:06 AM
> To: Brian Rosen
> Cc: Winterbottom, James; [email-masked]