Subject: AW: [Sipping] Location Presence Event Package

From: "Pailer Rudolf" <[email-masked]>
Date: Tue, 1 May 2007 18:39:22 +0200

Hello Hisham!

The goal of a location presence filter is, to specify a geographical boundary. The presentity notifies about enter/exit events relative to this boundary.
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.txt proposes to use GML to specify this boundary. GML is a rather complete set of XML elements to express any geographical boundary that you can possibly think of (in 2D and 3D).

Using RFC 4660 with an expression like
<changed from="-67.563 -13.834" by="0.2 0.2">
raises in my opinion the following questions:
What is the coordinate system?
What is the geometry?
What is the intended semantic of 'changed'?

You are right, that RFC 4660 can be extended in a way to also transport XML documents proposed in draft-ietf-geopriv-loc-filters-01.txt.
When implementing this on a mobile phone in a J2ME environment, we realized that this RFC 4660 filter wrapper did not add any functionality to our use case, but rather made the message longer and more complicated to parse. We therefore decided to drop the RFC 4660 wrapper.

I would appreciate your thoughts about wrapping  location filters proposed in draft-ietf-geopriv-loc-filters-01.txt inside an RFC 4660 filter document.

greetings
Rudolf

-----Ursprüngliche Nachricht-----
Von: Hisham Khartabil [mailto:[email-masked]] 
Gesendet: Dienstag, 01. Mai 2007 05:00
An: Pailer Rudolf
Cc: Brian Rosen; [email-masked]; [email-masked]
Betreff: Re: [Sipping] AW: [Geopriv] Location Presence Event Package

On 21/04/07, Pailer Rudolf <[email-masked]> wrote:
> 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.

What kind of interoperability problem?

Please also note that you can extend RFC4660.

Hisham

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

_______________________________________________
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