RE: [Geopriv] http-location-delivery-00 - clarification for "location information"

"Mary Barnes" <mary.barnes@nortel.com> Sun, 01 July 2007 14:49 UTC

Return-path: <geopriv-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I50jj-0003bo-GW; Sun, 01 Jul 2007 10:49:15 -0400
Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1I50ji-0003bi-70 for geopriv-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 10:49:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I50jh-0003ba-TX for geopriv@ietf.org; Sun, 01 Jul 2007 10:49:13 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I50jd-0002uk-Cq for geopriv@ietf.org; Sun, 01 Jul 2007 10:49:13 -0400
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l61En6a08269; Sun, 1 Jul 2007 14:49:07 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Geopriv] http-location-delivery-00 - clarification for "location information"
Date: Sun, 01 Jul 2007 09:48:51 -0500
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB16E79984@zrc2hxm1.corp.nortel.com>
In-Reply-To: <A09345776B6C7A4985573569C0F300430B03C8F4@rrc-dte-exs01.dte.telcordia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] http-location-delivery-00 - clarification for "location information"
thread-index: Ace6cBxV32uY08FXQo6/o9q5Unxp/gBfj8Dw
From: Mary Barnes <mary.barnes@nortel.com>
To: "Arolick, Eric" <earolick@telcordia.com>, geopriv@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8
Cc:
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2098683191=="
Errors-To: geopriv-bounces@ietf.org

Hi Eric,
 
Thanks for your feedback. In general, I agree that the clarifications
you suggest would be useful and I'll make those changes in the
-01 version I'm currently editting.  As far as your last point about
adding the "all" or "both", I'm not fully convinced that would be useful
given that it can be accomplished through the appropriate enumerations
and it's not clear to me how common such a request would be.  However,
if others in the WG think it's useful, it's a fairly straightforward
addition.
 
Thanks,
Mary 

	
	-----Original Message-----
	From: Arolick, Eric [mailto:earolick@telcordia.com] 
	Sent: Friday, June 29, 2007 12:09 PM
	To: geopriv@ietf.org
	Subject: [Geopriv] http-location-delivery-00 - clarification for
"location information"
	
	

	It would be helpful to provide more clarification and
consistency in the HELD specification regarding whether the term
"location information" refers to only actual location information e.g.
civic and/or geodetic data, or whether it also includes location
references, i.e., a location URI. The following comments are based on
location information referring only to actual location data - in other
words, location-by-value; what can be returned in a PIDF-LO. Based on
this, a location reference is not location information - it is used to
obtain location information.

	 

	The definition given for "location information" in Section 3
states that LI is the data that describes location. This text appears to
indicate that a location URI is not included in what is meant by
location information.  An additional definition, "location reference"
with text describing that this is a pointer or key in the form of a
location URI used to retrieve location information via a de-referencing
process would more explicitly highlight that a location URI is not
location information.

	 

	Rewording in Section 4 and Section 5 where location information
is discussed is needed for consistency and to resolve ambiguity
regarding the meaning of the term, but in most places the distinction is
not critical to the overall meaning of the text.

	 

	Whatever the intended meaning of location information,
clarification would be helpful in Sec 7.2 for the locationType
parameter, where locationURI is included as a type of location
information. It is not clear whether the "any" value includes only
location data in civic and/or geodetic form or also a locationURI. An
additional sentence would allow the flexibility to return actual
location information and/or a locationURI, but not strongly suggest that
the LCS create and maintain a location reference for location requests
where a reference was not explicitly requested.

	 

	Existing sentence - The LCS SHOULD return location information
in a form that is suited for routing and responding to an emergency call
in its jurisdiction. (This could be interpreted to not include a
locationURI as it cannot be routed on or used for dispatch as is.)

	 

	Suggested additional sentence -   The LCS MAY alternatively or
additionally return a locationURI. 

	 

	An additional possible value for the locationType element of
"all" or "both" could be used to explicitly indicate a request for both
location values and a location reference.

	 

	Thanks

	 

	Eric Arolick

	 

	 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv