Subject: [Geopriv] Location Profile Comments

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Apr 2007 20:36:31 +0200

Hi Rudolf,

please find my comments regarding the location profile document.

Rudolf wrote:

*) draft-ietf-geopriv-pdif-lo-profile-06.txt is mentionned in the 
location presence document as a potential reference. The
geographical shapes in this draft are much more complex than the 
rectangle shape in our draft. The location presence event package should 
be implemented in mobile devices. Finding out, whether a mobile phone is 
inside/outside of a specified geographical shape may result in complex 
and resource intensive calculations (with exception of the shape of a 
circle (center point with radius) that is missing in the features.xsd of 
GML).

There are two specific issues mentioned here:

a) Conveying location information within SIP as part of PIDF-LO

b) Location information used within authorization policies

Ad a) The location shapes indicated in 
draft-ietf-geopriv-pdif-lo-profile-06.txt are based on today's location 
determination techniques. We would like to restrict the functionality 
but unfortunately we failed todo so given that there are environments 
where many of these shapes are used.

For example, in a WLAN / enterprise environment one might most likely 
find civic information. But, if geodedic information is used then it 
would most likely be represented by a point. In cellular environments 
our Nokia Siemens Networks location experts told me that a point with 
uncertainty circle (i.e., Circle in GML 3.1.1 PIDF-LO Shape Application 
Schema) and arc bands are in fact used. 3GPP and OMA specifications 
define other shapes that got implemented but rarely used.

I haven't, however, seen a survey that would allow me to restrict the 
number of shapes in the document (a sort of classification into 
mandatory and optional to implement).

The problem with restricting the shapes is also that different 
applications might use different shapes. This document aims to be 
generic and hence it is difficult to restrict the functionality too 
much. For the emergency services use case we discussed this aspect 
during the SDO Emergency Services Workshop and we came to a rough 
conclusion that all shapes should be supported by the LIS and the PSAP 
should be able to receive and process them. For display reasons only a 
point representation might, however, be used. What will be used for 
dispatch might change in the future -- nobody knows.

Still, if you have feedback please let us know.

Ad b) Section 4 of draft-ietf-geopriv-policy-11.txt currently defines 
very simple shapes with an extensibility mechanism to define more 
complex ways to express authorization policies that match then an entity 
is within a particular geographical area.  We decided to use a polygon 
(2d & 3d). Depending on the input data (based on what information is 
actually available to the Presence/Location Server a  point-in-polygon, 
polygon-in-polygon or a similar computation is necessary to determine 
the final rule matching result. This might not be the simplest 
computation but it is certainly not the most complicated one either.
Let me focus on the point-in-polygon operation, for simplicity reasons, 
since you can obviously reduce the quality of the input data to a point. 
As stated several times already on the mailing list, the computational 
complexity is not that large. 
http://www.cgafaq.info/wiki/Point_in_polygon and 
http://www1.acm.org/pubs/tog/editors/erich/ptinpoly/ gives you an idea 
about the algorithms. "Testing whether a point is inside a polygon is a 
basic operation in computer graphics.": If you like computer games then 
this statement might indicate that this is not a tremendously unusual 
thing on today's end devices.

I haven't seen that draft-pailer-locpres-00.txt defines location 
information conditions. However, even if it would then the difference to 
the content in Section 4 of draft-ietf-geopriv-policy-11.txt would be 
pretty small given that both use the polygon -- just the maximum number 
of points that need to be understood are different. One can obviously 
argue about the 3d polygon.

We would obviously appreciate feedback for 
draft-ietf-geopriv-policy-11.txt since that document will become RFC 
pretty soon (at least I hope so).

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Pailer Rudolf" <[email-masked]>
Date: Wed, 25 Apr 2007 06:04:19 +0200

Hello Hannes!

The focus of draft-pailer-locpres-00.txt lies in using the SIP event framework to subscribe to notifications about location presence of a user.  Location presence data may either be requested as the current geographical position of a user, or as a containment state (inside/outside) relative to a specified area.
We think that in particular the containment state has a lot of potential because it first allows to specify different area sizes for different watchers and second that the area itself may just be referenced by a URL.
The idea is, that a presentity can define a set of containment areas itself (e.g. in my case 'Austria', 'Vienna', 'Office' etc.) and make this areas accessible via URLs. The presentity decides whether a watcher may subscribe to notifications to 'Vienna' (medium scale) or to 'Office' (detailed scale). We further think that usability and readability of named location area URLs can increase the acceptance of Location Based Services in general.
Please note that by defining areas on different scales the presentity has a simple way to restrict the resolution of it's own position.

We therfore do not have any particular preference for any data format and can easily accept circles, arc bands, polygons etc. as long as the following requirements are met:
*) the number of possible shapes is not too large so that the footprint of code does not grow beyond the limits of typical mobile devices.
*) the containment algorithm (inside/outside) can be computed on a typical mobile device (e.g. using J2ME).
*) the shape is encoded in XML and can be addressed via a URL

draft-pailer-locpres-00.txt is quite strict in definition of location data format in order to ensure interoperability. However I do not see any reason, why draft-pailer-locpres-00.txt should not reference draft-ietf-geopriv-pdif-lo-profile-06.txt as the source for specification of location data shapes.

I further think that applying draft-ietf-geopriv-policy-11.txt to subscriptions of the current geographical position in draft-pailer-locpres-00.txt is possible and even desireable. Above I have described the mechanism of  draft-pailer-locpres-00.txt to ensure privacy of the presentity by restricting the resolution of the containment area.  Thus transformations like specified in section 6.5.2 of draft-ietf-geopriv-policy-11.txt are not aplicable to containment areas.

best regards
Rudolf

-----Ursprüngliche Nachricht-----
Von: Hannes Tschofenig [mailto:[email-masked]] 
Gesendet: Samstag, 21. April 2007 20:37
An: Pailer Rudolf
Cc: GEOPRIV
Betreff: Location Profile Comments

Hi Rudolf,

Rudolf wrote:

Ciao
Hannes