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
- [Geopriv] http-location-delivery-00 - clarificati… Arolick, Eric
- RE: [Geopriv] http-location-delivery-00 - clarifi… Mary Barnes