Subject: AW: [Geopriv] Location Presence Event Package

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

Hello Brian!
 
Sorry, that it took me some time to reply to your mail.
 
We looked at RFC 4660 that defines event notification filters for
presence, but did not see a feasibile way to express the following rule:
"Send a notification, if the presentity enters an area (e.g. specified
by a circle (center point + radius) or a rectangle)."
There was e.g. the proposal in our research group to use presence event
filters in the following way:
<changed from="-67.563 -13.834" by="0.2 0.2">
We think that such a notation is highly ambigous and will lead to
interoperability problems.
 
RFC 4660 builds on the assumtion that the state space of presence is
restricted to a few logical states that can be filtered by a boolean
combination of filter rules. The location presence event package
notifies on geographical positions, that have an (nearly infinite) state
space. Combining geograhical shapes in boolean terms and calculating if
the presentity is now inside/outside of this area is not feasible on
mobile devices with restricted computation resources.

Therfore we propose to use some different kind of filtering approach
(see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.tx
t).

Now there is the question, why not to use geopriv-loc-filters inside the
presence package:
Our main goal is to route SIP SUBSCRIBE messages containing
geopriv-loc-filters documents from the watcher to the presentity. The
location presence event package is targeted at mobile devices and we
argue that filters have to be executed on the mobile device (otherwise
you will no be able to restrict the number of notification messages on
the radio interface). This means that the subscription cannot be
processed by a (conventional) presence server in the network, but has to
be routed to the mobile phone of the user (but only to those mobile
phones, that have an edge presence server running).
Location presence subscriptions and notifications are processed by
different nodes than conventional presence. The scale of location
presence data may be significatly different to conventional presence.
This means that SUBCRIBE and NOTIFY messages have to take different
paths in the network and will be processed by different nodes than
conventional presence.
We thus discussed several methods, to differentiate the routing of
conventional presence to location presence:
	1) Introduce another URI-scheme. This does not seem to be as
elegent as the introduction of the locpres event package.
	2) The edge presence server on the mobile device registers with
an own SIP URI. This requires a lot of a priori knowledge of the
watcher.
	3) define an own event package - we favored this solution

The idea of the locpres event package is, that it uses the same
framework than conventional presence (e.g. for user profiles, policy
decisions etc.), but that it indicates that this type of presence has to
be routed and processed differently than conventional presence. 
Thus SIP routing of initial SUBCRIBE messages can be based on the
content "locpres" of the SIP Event header field. This solution seems to
integrate well in the existing SIP presence framework and general SIP
specifications. Presence user agents can for example use the "Watcher
Information Event Template-Package" [RFC 3857]. This means that the
Presence User Agent can subscribe to "locpres.winfo" notifications in
order to be notified about changes in the subscription state regarding
locpres events. 
Furthermore [RFC 3840] introduces "User Agent Capabilities" in form of
feature tags that can be conveyed in form of parameters in the Contact
header field to other user agents and registrars. In particular a
Contact header with the sip.event media tag containing a value of
"locpres" can be used by a Presence User Agent to indicate that
subscriptions for location presence data shall be routed to this
address. Sip.event feature tag parameters are also used in [RFC 3841]
that defines the notion of "caller preferences" about request handling
in servers. These preferences include the ability to select which
Uniform Resource Identifiers (URI) a request gets routed to, and to
specify certain request handling directives in proxies and redirect
servers. Again a value of "locpres" in a sip.event media feature tag can
be used by a presence server to route a subscription for location
presence data to the responsible edge presence server or state agent.

greetings
Rudolf

________________________________

Von: Brian Rosen [mailto:[email-masked]] 
Gesendet: Montag, 09. April 2007 13:35
An: Pailer Rudolf; [email-masked]; [email-masked]
Betreff: RE: [Geopriv] Location Presence Event Package

I've read this, and I don't really understand why real presence (with
the filter package) doesn't provide the same service.

Can you give an example where presence+filter is significantly different
from this package, with the filter inclusion?   It seems to me that you
get roughly the same number of messages, with roughly the same content.

Brian

________________________________

From: Pailer Rudolf [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 1:57 AM
To: [email-masked]; [email-masked]
Subject: [Geopriv] Location Presence Event Package

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
<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

---

From: "Pailer Rudolf" <[email-masked]>
Date: Sat, 21 Apr 2007 07:22:34 +0200

Hello Paul!

Please see my reply to Brian's posting regarding the routing of subscriptions and notifications for loaction presence.
Location Presence scales differently than conventional presence and different nodes need to process subscriptions for location presence. We were thus looking for a way to differentiate the routing of locpres SIP messages from conventional presence and do propose to use an own event package to do so.

Regading the number of watchers:
In the scientific papers that we published on the topic of location presence, we introduced a node called 'WatcherLister Server'. This server deals with a list of watchers that all subscribe to the same event. We did not include this idea in the location presence draft. The reason for this is, that we think that the specification of a 'Watcher List Server' would be a generic addtion to the SIP presence framework rather than something only valid for location presence. Therefore a 'Watcher List Server' should be specified in an own draft/RFC.

greetings
Rudolf

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Montag, 09. April 2007 15:35
An: Brian Rosen
Cc: Pailer Rudolf; [email-masked]; [email-masked]
Betreff: Re: [Sipping] RE: [Geopriv] Location Presence Event Package

Like Brian I think this seems so close to existing presence that you 
need to work harder to make the case for something different, and to 
show how the two packages would be coordinated.

It appears to me that a major goal you have is to avoid sending out 
messages as a result of movement when there are no watchers that are 
interested in that movement. While I can see how that could be helpful 
in some cases, it needs to be reconciled with the resulting need to 
manage subscriptions from what could be a large number of watchers.

In any case, I think what you suggest could be achieved by introducing 
some special filters for geoloc information into standard presence. At 
least that would work when there is no separate presence aggregator.

	Paul

Brian Rosen wrote:
> ------------------------------------------------------------------------
> 
> *From:* Pailer Rudolf [mailto:[email-masked]]
> *Sent:* Monday, April 09, 2007 1:57 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* [Geopriv] Location Presence Event Package
> 
>  
> 
> Hello!
> 
> Communications and Networking Conference April 2006 (WCNC06), Las Vegas, USA
> 
> Commerce and Wireless Services (WMCS'06) June 26, 2006, San Francisco, USA
> 
> ------------------------------------------------------------------------
> 
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP