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

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 30 March 2004 22:46 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19799 for <sipping-emergency-archive@odin.ietf.org>; Tue, 30 Mar 2004 17:46:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006YH-7K for sipping-emergency-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EK0n9Q020010 for sipping-emergency-archive@odin.ietf.org; Sun, 14 Mar 2004 15:00:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bmy-0005Bi-L0 for sipping-emergency-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 15:00:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03648 for <sipping-emergency-web-archive@ietf.org>; Sun, 14 Mar 2004 15:00:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2bmv-0003bZ-00 for sipping-emergency-web-archive@ietf.org; Sun, 14 Mar 2004 15:00:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2blQ-0003Fi-00 for sipping-emergency-web-archive@ietf.org; Sun, 14 Mar 2004 14:59:13 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2bkP-000315-00 for sipping-emergency-web-archive@ietf.org; Sun, 14 Mar 2004 14:58:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bkS-0003ej-2R for sipping-emergency-web-archive@ietf.org; Sun, 14 Mar 2004 14:58:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Xfm-0004Lc-Jb for sipping-emergency@optimus.ietf.org; Sun, 14 Mar 2004 10:37:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23170 for <sipping-emergency@ietf.org>; Sun, 14 Mar 2004 10:37:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Xfk-00047W-00 for sipping-emergency@ietf.org; Sun, 14 Mar 2004 10:37:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Xem-0003zF-00 for sipping-emergency@ietf.org; Sun, 14 Mar 2004 10:36:05 -0500
Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1B2Xdr-0003sG-00 for sipping-emergency@ietf.org; Sun, 14 Mar 2004 10:35:07 -0500
Received: from bear.cs.columbia.edu (IDENT:mzfDsAt0CZ+MJ6QRqh8gEBFvXpNxJ9fW@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i2EFZ4NC005641 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 14 Mar 2004 10:35:04 -0500 (EST)
Received: from cs.columbia.edu (pool-138-89-69-144.mad.east.verizon.net [138.89.69.144]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i2EFZ3fG004423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 14 Mar 2004 10:35:03 -0500
Message-ID: <40547BA2.9080302@cs.columbia.edu>
Date: Sun, 14 Mar 2004 10:34:58 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219
X-Accept-Language: en-us, en, de
MIME-Version: 1.0
To: "James M. Polk" <jmpolk@cisco.com>
CC: sipping-emergency@ietf.org
Subject: Re: [Sipping-emergency] PIDF-LO Emergency Additions for consideration
References: <4.3.2.7.2.20040314005715.02794f00@localhost> <4.3.2.7.2.20040314005715.02794f00@localhost> <4.3.2.7.2.20040314092252.02771948@localhost>
In-Reply-To: <4.3.2.7.2.20040314092252.02771948@localhost>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Id: <sipping-emergency.ietf.org>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,CELL_PHONE_BOOST autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

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.

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.
> 
> 
> At 09:52 AM 3/14/2004 -0500, Henning Schulzrinne wrote:
> 
>>> 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.
>>
>>
>> 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
>>>     form of a URI)
>>
>>
>> <provided-by>sip:foo@bar.com</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
> 
> 
> 
> cheers,
> James
> 
>                                *******************
>                 Truth is not to be argued... it is to be presented

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency