Subject: [Sipping-emergency] PIDF-LO Emergency Additions for consideration

From: "James M. Polk" <[email-masked]>
Date: Sun, 14 Mar 2004 01:16:29 -0600

All

A group of us in Seoul reacted to the discussion in SIPPING and Geopriv 
regarding where certain requirements should be met regarding added 
information within a SIP INVITE message. I initiated most of the confusion 
by listing several requirements that were brought to my attention (due to 
me writing (with Brian Rosen) the Location Conveyance in SIP ID) as being 
necessary within the message (I might not have explained very well that the 
message needed these elements - SIP itself did not necessarily). You can 
review my preso from the softarmor site for what was presented.

The group of us (Brian, Henning, myself, Keith Drage, Hannes Tschofenig and 
Nadine Abbott) distilled to two the list of 5 or 6 that should be addressed 
within the PIDF-LO ID for now. Jon (that doc's author) is already aware of 
1 of these, and has heard about the other - but didn't know to my knowledge 
which set of additional elements we'd chosen. We agreed this reflector 
would be the first to see the list before it's offered to the Geopriv list 
during that ID's WGLC.

We want to request that the two additional information elements be:

1. 	by what mechanism did the UAC receive its LI from (.11, GPS,
	manual entry, Triangulation, DHCP) by name, not number

	i.e: *not*
	1=GPS
	2=DHCP
	etc

	I think this list is going to have to be IANA registered for this
	effort for consistency.

2.	what organization was that LI field value provided by (in the
	form of a URI)

comments?

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Mar 2004 09:52:51 -0500

>     I think this list is going to have to be IANA registered for this

Indeed. This would be something simple like

<method>gps</method>

(I think <method> more clearly distinguishes this from the next item below.)

Text could be something like:

The <method> element describes the way that the location information in 
the location object was derived. Its value is drawn from a set of 
IANA-registered tokens that include

GPS: Global Positioning System

A-GPS: GPS with assistance

manual: entered manually by an operator or user, e.g., based on 
subscriber billing or service location information

DHCP: provided by DHCP [geo,civil]

triangulation: triangulated from time-of-arrival, signal strength or 
similar measurements

cell: location of the cellular radio antenna or 802.11 access point

> 2.    what organization was that LI field value provided by (in the

<provided-by>sip:[email-masked]</provided-by>

One question is whether (2) is meant for human consumption or for some 
robot. If human consumption, we don't have to say much more than 'URI 
identifying the entity that calculated the geospatial or civil location 
information. This allows the recipient to determine, for example, if the 
location information was provided by the target itself or some third 
party and may allow the recipient to contact the entity identified by 
the URI to report errors.'.

If suitable for a robot, we would have to define what kind of 
information such a robot would find useful, such as

- some standard-format contact information (like a vCard)
- some description of the likely accuracy of the measurement method

I think at this point we need to provide precise text. If we're unable 
to do that, it probably indicates that the concepts are too fuzzy and 
insufficiently baked for inclusion.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 14 Mar 2004 09:49:48 -0600

At 10:34 AM 3/14/2004 -0500, Henning Schulzrinne wrote:
>More detail is better, so I agree with your suggestion of splitting 
>things. I would suggest that once we have reached closure in this 
>subgroup, that we send text to the geopriv mailing list, so that it is 
>part of the official last-call record.

I agree

>James M. Polk wrote:
>
>>Below is good with one exception:
>>I think the 802.11 method type should be unique, as it has some unique 
>>properties associated with distance (within) from the Access Point 
>>antenna that might prove useful from an accuracy/resolution point of view 
>>during the dispatch of police/fire/ambulance personnel.

cheers,
James

                                *******************

---

From: Allison Mankin <[email-masked]>
Date: Sun, 14 Mar 2004 18:30:00 -0800

> <provided-by>sip:[email-masked]</provided-by>

Henning and James,

Could you give more explanation of what you mean by the organzation
that provided the LI field value? 

What would the field be set to for GPS?

Could we (here) get a better feel for what use you expect the emergency
center to make of this info?

Allison

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 14 Mar 2004 10:34:58 -0500

James M. Polk wrote:

> antenna that might prove useful from an accuracy/resolution point of 
> view during the dispatch of police/fire/ambulance personnel.
> 
> 
> At 09:52 AM 3/14/2004 -0500, Henning Schulzrinne wrote:
> 
>> The <method> element describes the way that the location information 
>> in the location object was derived. Its value is drawn from a set of 
>> identifying the entity that calculated the geospatial or civil 
>> location information. This allows the recipient to determine, for 
>> example, if the location information was provided by the target itself 
>> or some third party and may allow the recipient to contact the entity 
>> identified by the URI to report errors.'.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 14 Mar 2004 09:29:44 -0600

I think the 802.11 method type should be unique, as it has some unique 
properties associated with distance (within) from the Access Point antenna 
that might prove useful from an accuracy/resolution point of view during 
the dispatch of police/fire/ambulance personnel.

At 09:52 AM 3/14/2004 -0500, Henning Schulzrinne wrote:
>manual: entered manually by an operator or user, e.g., based on subscriber 
>billing or service location information
>
>location information was provided by the target itself or some third party 
>and may allow the recipient to contact the entity identified by the URI to 
>report errors.'.
>
>If suitable for a robot, we would have to define what kind of information 
>such a robot would find useful, such as
>
>I think at this point we need to provide precise text. If we're unable to 
>do that, it probably indicates that the concepts are too fuzzy and 

cheers,
James

                                *******************