GEOPRIV WG                                                   J. Peterson
Internet-Draft                                                   NeuStar
Expires: August 7, 2004                                 February 7, 2004

    A Presence Architecture for the Distribution of Geopriv Location

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 7, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   Geopriv defines the concept of a 'using protocol', a protocol that
   carries Geopriv location objects.  Geopriv also defines various
   scenarios for the distribution of location objects that require the
   concept of subscriptions and asynchronous notifications.  This
   document examines some existing IETF work on the concept of presence,
   shows how presence architectures map onto Geopriv architectures, and
   presents one pre-existing using presence protocol that might carry
   location objects.

Peterson                 Expires August 7, 2004                 [Page 1]

Internet-Draft              pres enumservice               February 2004

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Framework Analysis . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Presence Architecture for Geopriv  . . . . . . . . . . . . . . . 4
   4. Geopriv Extensions to PIDF . . . . . . . . . . . . . . . . . . . 6
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
      Informative References . . . . . . . . . . . . . . . . . . . . . 6
      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9

Peterson                 Expires August 7, 2004                 [Page 2]

Internet-Draft              pres enumservice               February 2004

1. Introduction

   Geopriv is a standard for the transmission of location information
   over the Internet.  Location information is a description of a
   particular spatial location, which may be represented as coordinates
   (via longitude, latitude, and so on), or as civil addresses (such as
   postal addresses), or in other ways.  Geopriv focuses on the privacy
   and security issues, both from a technology perspective and a policy
   perspective, of sharing location information over the Internet; it
   essentially defines a secure container class capable of carrying both
   location information and policy data governing the distribution of
   this information.  Geopriv also defines the concept of a 'using
   protocol', a protocol that carries the Geopriv location object.

   Presence is a service defined in RFC2778 [2] that allows users of a
   communications service to monitor one another's availability and
   disposition in order to make decisions about communicating.  Presence
   information is highly dynamic, and generally characterizes whether a
   not a user is online or offline, busy or idle, away from
   communications devices or nearby, and the like.

   This document shows the applicability of presence to Geopriv, and
   argues that a presence protocol might be a suitable using protocol
   for Geopriv.  This document is not intended to demonstrate that
   presence is the only method by which Geopriv location objects might
   be distributed.  However, there are numerous applications of Geopriv
   that depend on the fundamental subscription/notification architecture
   that also underlies presence.

2. Framework Analysis

   The Geopriv framework [1] defines four primary network entities: a
   Location Generator, a Location Server, a Location Recipient, and a
   Rule Holder.  Three interfaces between these entities are defined,
   including a publication interface and a notification interface.

   Geopriv specifies that a 'using protocol' is employed to transport
   location objects from one place to another.  If the publication
   interface and notification interface are network connections, then a
   using protocol would be responsible for the transmission of the
   location object.  Location Recipients may request that a Location
   Server provide them with Geopriv location information concerning a
   particular Target.  The Location Generator publishes Location
   Information to a Location Server, which, in coordination with
   policies set by the Rule Maker, distributes the location information
   to Location Recipients as necessary.

   The Geopriv requirements document shows three scenarios for the use

Peterson                 Expires August 7, 2004                 [Page 3]

Internet-Draft              pres enumservice               February 2004

   of the Geopriv protocol.  In some of these scenarios (such as the
   third), a Location Recipient sends some kind of message to the
   Location Server to request the periodic transmission of location
   information.  The location of a Geopriv Target is likely to vary over
   time (if the Target is a person, or something similarly mobile) and
   consequently the concept of a persistent subscription to the location
   of a Target resulting in periodic notification is valuable to
   Geopriv.  In other scenarios, a Location Recipient may request a one-
   time notification of the geographical location of the Target.

   Geopriv places few requirements on using protocols.  However, it is
   clear from the description above that there must be some mechanism to
   allow Location Recipients to establish a persistent subscription in
   order to receive regular notification of the geographical location of
   a Target as their location changes over time.  There must also be a
   way for Location Generators to publish location information to a
   Location Server that applies further policies for distribution.

   This document adopts a model in which the using protocol is
   responsible for requesting subscriptions, handling publications, and
   sending notifications.  There are other models for Geopriv in which
   such operations might be built into location objects themselves.
   However, there is a significant amount of pre-existing work in the
   IETF related to managing publications, subscriptions and
   notifications for data sets that vary over time.  In fact, these
   concepts all correspond exactly to architectures for presence that
   have been developed in support of real-time communications
   applications such as instant messaging, voice and video sessions.

   Note that there are some Geopriv scenarios in which the Location
   Recipient does not actively request the location of a Target, but
   rather it receives an unsolicited notification of Target's location.
   This document focuses on the use of presence only for those scenarios
   in which the Location Recipient actively solicits location
   information.  It is however possible that many of these base
   operations of the subscription/notification framework of presence
   could be reused in for cases in which the Location Recipient is

3. Presence Architecture for Geopriv

   The Common Profile for Presence [4] (CPP) defines a set of operations
   for delivery of presence information.  These primarily consist of
   subscription operations and notification operations.  A subscription
   creates a persistent connection between a 'watcher' (which
   corresponds to the Location Recipient of Geopriv) and a 'presentity'
   (which corresponds roughly to the Location Server).  When a watcher
   subscribes to a presentity, a persistent connection is created;

Peterson                 Expires August 7, 2004                 [Page 4]

Internet-Draft              pres enumservice               February 2004

   notifications of presence information will henceforth be sent to the
   watcher as the presence information changes.  CPP also supports
   unsubscriptions (terminating the persistent subscription) and fetches
   (one-time requests for presence information that result in no
   persistent subscription).

   CPP provides a number of attributes of these operations that flesh
   out the presence system.  There is a system for automatically
   expiring subscriptions if they are not refreshed at user-defined
   intervals (in order to eliminate stale subscriptions).  There are
   transaction and subscription identifiers used to correlate messages,
   and a URI scheme ("pres:") is defined to identify watchers and

   The IETF IMPP WG has also defined an XML data format for presence
   information called the Presence Information Data Format [6] (PIDF).
   PIDF is a body carried by presence protocols that contains presence
   information, including the current state of a presentity.  PIDF is
   discussed in more detail in Section 4.

   At a high-level, then, the presence architecture seems to have
   considerable applicability to the problem of delivering Geopriv
   information.  However, the CPP framework is an abstract framework -
   it doesn't actually specify a protocol, it specifies a framework and
   a set of requirements to which presence protocols must conform.
   Also, CPP does not define any concept similar to a Location Server,
   nor any way for presence information to be published to a Location

   SIMPLE, the application of the Session Initiation Protocol [7] (SIP)
   to instant messaging and presence, is one protocol that instantiates
   the CPP format and extends it in a number of important ways.  SIP has
   native support for subscriptions and notifications (in its events
   framework [8]) and has added an event package [9] for presence in
   order to satisfy the requirements of CPP.  Above and beyond CPP,
   SIMPLE has done work on a publication method [11] that will allow
   presence information to be published by presentities to a server that
   will apply various policies before sharing presence information with
   watchers (in the SIMPLE publication architecture, this server is
   known as a compositor).  SIMPLE has also defined an interface [10]
   through which authorization policies can be provisioning in a
   presence server.

   In summary, like Geopriv, presence requires an architecture for
   publication, subscription, and notification for a mutable set of data
   associated with a principal.  Presence has already tackled many of
   the harder issues associated with subscription management, including
   subscription expiration, development of identifiers for principals,

Peterson                 Expires August 7, 2004                 [Page 5]

Internet-Draft              pres enumservice               February 2004

   and defining document formats for presence information.  Rather than
   reinventing work that has been done elsewhere in the IETF, Geopriv
   should if at all possible reuse this existing work by specifying
   presence protocols (such as SIMPLE) as Geopriv using protocols.

4. Geopriv Extensions to PIDF

   As was mentioned above, the presence architecture developed in the
   IETF IMPP WG has defined a format for presence information called
   PIDF.  PIDF is an XML format that provides presence information about
   a presentity - primarily, this consists of status information, but
   also optionally includes contact addresses (a way of reaching the
   presentity), timestamps, and textual notes with arbitrary content.

   PIDF is an extensible format.  It defines an XML element for
   representing the status of a presentity (the status element), and
   gives some guidance on how this element might be extended.  While the
   authors of PIDF viewed geographical location as a potential category
   of presence information, PIDF currently defines no way to do so.

   PIDF meets the security requirements given in RFC2779 [3] (see
   especially 5.1, 5.2 and 5.3), which parallel the security
   requirements of the Geopriv location object given in the Geopriv
   requirements [1].  CPP and PIDF specify mechanisms for mutual
   authentication of participants in a presence exchange as well as
   confidentiality and integrity properties for presence information.

   So in short, many of the requirements of Geopriv objects map well
   onto the capabilities of PIDF.

5. Security Considerations

   Geopriv information, like presence information, has very sensitive
   security requirements.  The requirements of RFC2779 [3], which are
   followed by CPP, PIDF and SIMPLE, map well onto the security
   requirements of the Geopriv protocol, as defined in the Geopriv
   requirements document and the Geopriv threat analysis [12] document.
   Specifically, the presence security requirements call for
   authentication of watchers, integrity and confidentiality properties,
   and similar measures to prevent abuse of presence information.

6. IANA Considerations

   This document introduces no considerations for the IANA.

Informative References

   [1]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.

Peterson                 Expires August 7, 2004                 [Page 6]

Internet-Draft              pres enumservice               February 2004

         Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-04 (work
         in progress), October 2003.

   [2]   Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
         Instant Messaging", RFC 2778, February 2000.

   [3]   Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
         Presence Protocol Requirements", RFC 2779, February 2000.

   [4]   Peterson, J., "A Model for Presence and Instant Messaging",
         draft-ietf-impp-pres-04 (work in progress), August 2003.

   [5]   Peterson, J., "Address Resolution for Instant Messaging and
         Presence", draft-ietf-impp-srv-04 (work in progress), September

   [6]   Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
         J. Peterson, "CPIM Presence Information Data Format", draft-
         ietf-impp-cpim-pidf-08 (work in progress), May 2003.

   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, May 2002.

   [8]   Roach, A., "Session Initiation Protocol(SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [9]   Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
         in progress), Jan 2003.

   [10]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-
         01 (work in progress), October 2003.

   [11]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", Internet-Draft  draft-ietf-simple-
         publish-02, January 2004.

   [12]  Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat
         Analysis of the geopriv Protocol", draft-ietf-geopriv-threats-
         01 (work in progress), September 2003.

   [13]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August

Peterson                 Expires August 7, 2004                 [Page 7]

Internet-Draft              pres enumservice               February 2004

Author's Address

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520

   Phone: +1 925/363-8720

Peterson                 Expires August 7, 2004                 [Page 8]

Internet-Draft              pres enumservice               February 2004

Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Peterson                 Expires August 7, 2004                 [Page 9]