Subject: AW: [Geopriv] Location Presence Event Package

From: "Pailer Rudolf" <[email-masked]>
Date: Sat, 21 Apr 2007 06:09:35 +0200

Hello Hannes!

The following comments regarding the documents that you mentionned:

*) The content of location presence notifications is based on PIDF-LO. For containment status data (inside/outside of an area) an extension proposed in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.txt is used.

*)  The story about the document draft-ietf-geopriv-loc-filters-01.txt by Rohan Mahy is, that the draft was expired and I decided to copy some parts of it in the location presence draft. There are some minor adjustments to draft-ietf-geopriv-loc-filters-01.txt, that we propose, and that I have also posted on this mailing list.
Now this draft has reappeard and I plan to just refer to Rohan's draft in the next version.

*) RFC 4745 describes in general how policy documents should look like. draft-ietf-geopriv-policy-11.txt describes the polica about access to presence data depending on the current location. There may be some kind of connection to location presence, but we see potential problems if policy areas and location presence areas overlap (in particular, if the service should be implemented on a mobile phone with restricted computing resources). We will further investigate the relation of our draft to policy rules.
draft-ietf-simple-presence-rules-09.txt describes policy for RPIDF documents. We did not find RPIDF useful for transporting locatrion presence data.

*) 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).

*) draft-ietf-geopriv-revised-civic-lo-05.txt  works with civic addresses that are out of the scope of the location presence avent package. Again there is the problem, how to implement mapping of geographical data to civic addresses on a mobile phone. We rather think that such a mapping service should be implemented by some GIS in the network.

*) draft-singh-geopriv-pidf-lo-dynamic-01.txt is definitely interesting regading dynamic features like speed, accelleration or bearing. In real applications, there are however scalability considerations to be done, in particular regarding the rate of notifications. 

Greetings
Rudolf

-----Ursprüngliche Nachricht-----
Von: Hannes Tschofenig [mailto:[email-masked]] 
Gesendet: Montag, 09. April 2007 13:31
An: Pailer Rudolf
Cc: [email-masked]
Betreff: Re: [Geopriv] Location Presence Event Package

Hi Rudolf,

I would be interested to read the documents you mentioned. I also would 
like to better understand the relationship of your document to the 
following GEOPRIV documents:

* PIDF-LO & Presence
The PIDF-LO (http://www.ietf.org/rfc/rfc4119.txt) is meant to be used in 
the presence architecture. RFC 4079 http://www.ietf.org/rfc/rfc4079.txt 
describes the motivation why it is useful to map the presence work to 
the GEOPRIV concepts.

* Notification Filters
To limit the amount of notifications Rohan wrote a document that is 
about to get finished (see 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.txt).

* The Common Policy / GEOPRIV / Presence authorization policy documents 
describe how privacy can be enabled for presence based systems that, 
among other things, use location information in presence systems.
Here are the documents:
http://www.ietf.org/rfc/rfc4745.txt
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-09.txt

We recently worked on a short paper for a W3C privacy workshop. I have 
to search for it...
A longer version of the paper will be published soon in form of an IETF 
draft.

* Profiling of Location Formats
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt
This document provides more information on the usage of GML. The idea 
was that we do the profiling once and then we don't need todo it for 
every document.
A revised version of the civic location format can be found here; 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised-civic-lo-05.txt

* Temporal Features
http://tools.ietf.org/wg/geopriv/draft-singh-geopriv-pidf-lo-dynamic-01.txt
This document extends the <location> element specified in RFC 4119 to 
carry temporal feature elements useful for tracking moving objects.

Ciao
Hannes

Pailer Rudolf wrote:
> Hello!
>
> I would like to notify you about the the Internet Draft "A Location
> Presence Event Package for the Session Initiation Protocol (SIP)".
> http://www.ietf.org/internet-drafts/draft-pailer-locpres-00.txt
>
> The draft describes the usage of the Session Initiation Protocol (SIP)
> for subscriptions and notifications of location presence. Location
> presence is information about the geographical position of a user.
> Subscriptions and notifications of location presence are supported by
> defining an event package within the general SIP event notification
> framework.
>
> The concept of a SIP based location enabler that is the core of the
> proposed draft was published on several occasions:
> *) A Terminal-Based Location Service Enabler for the IP Multimedia
> Subsystem, R. Pailer, S. Bessler, F. Wegscheider, IEEE Wireless
> Communications and Networking Conference April 2006 (WCNC06), Las Vegas,
> USA
> *) Terminal-Centric Location Services for the IP Multimedia Subsystem,
> J. Fabini, M. Happenhofer, R. Pailer, IEEE 63rd Vehicular Technology
> Conference, May 2006, Melbourne, Australia
> *) Implementing a Native IMS Location Service Enabler over a
> Prototypical IMS Core Network Testbed, P. Reichl, S. Bessler, J. Fabini,
> R. Pailer, J. Zeiss,The Third IEEE International Workshop on Mobile
> Commerce and Wireless Services (WMCS'06) June 26, 2006, San Francisco,
> USA
> *) Practical Experiences with an IMS-Aware Location Service Enabler on
> Top of an Experimental Open Source IMS Core Implementation, P. Reichl,
> S. Bessler, J. Fabini, R. Pailer, A. Poropatich, N. Jordan, R. Huber, H.
> Weisgrab, C. Brandner, I. Gojmerac, M. Ries, F. Wegscheider, Journal of
> Mobile Multimedia, Rinton Press, Fall 2006
> *) Lecture Notes in Geoinformation and Cartography, Location Based
> Services an TeleCartography, G. Gartner, W. Cartwright, M. P. Peterson
> (Eds.), Springer, 2007
>
> I can provide above documents in PDF format, if needed.
>
> Feedback from the IETF Working Groups GEOPRIV and SIPPING would be
> appreciated very much indeed.
>
> greetings
> Rudolf
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>   

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 21 Apr 2007 15:49:37 +0200

Hi Rudolf, 

> *) The content of location presence notifications is based on PIDF-LO. For
> containment status data (inside/outside of an area) an extension proposed
> in
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.txt is used.

Ok

> 
> *)  The story about the document draft-ietf-geopriv-loc-filters-01.txt by
> Rohan Mahy is, that the draft was expired and I decided to copy some parts
> of it in the location presence draft. There are some minor adjustments to
> draft-ietf-geopriv-loc-filters-01.txt, that we propose, and that I have also
> posted on this mailing list.

Got it. 

> *) RFC 4745 describes in general how policy documents should look like.
> draft-ietf-geopriv-policy-11.txt describes the polica about access to
> presence data depending on the current location. There may be some kind of
> connection to location presence, but we see potential problems if policy areas and
> location presence areas overlap (in particular, if the service should be
> implemented on a mobile phone with restricted computing resources). We will
> further investigate the relation of our draft to policy rules.
> draft-ietf-simple-presence-rules-09.txt describes policy for RPIDF
> documents. We did not find RPIDF useful for transporting locatrion presence data.

That's certainly something we should discuss further. I would like to better understand your thoughts about potential problems for the relationship between presence and location policy. 

> 
> *) 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).

I will have to double-check this with your draft. There are a couple of shapes in draft-ietf-geopriv-pdif-lo-profile-06.txt that relate to location determination techniques used in cellular networks. 

I will respond to this aspect in a separate mail 

> 
> *) draft-ietf-geopriv-revised-civic-lo-05.txt  works with civic addresses
> that are out of the scope of the location presence avent package. Again
> there is the problem, how to implement mapping of geographical data to civic
> addresses on a mobile phone.

Civic address information is more valueable in an non-cellular environment. There are, however, a couple of mobility environments where this is pretty useful. 

> We rather think that such a mapping service
> should be implemented by some GIS in the network.
> 
> *) draft-singh-geopriv-pidf-lo-dynamic-01.txt is definitely interesting
> regading dynamic features like speed, accelleration or bearing. In real
> applications, there are however scalability considerations to be done, in
> particular regarding the rate of notifications. 

I am sure that there are implications regarding the amount of notifications being returned. This aspect motivated Rohan's filter draft. 

Ciao
Hannes