[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

GEOPRIV Working Group                                   M. Garcia-Martin
Internet-Draft                                                  Ericsson
Intended status:  Standards Track                          H. Tschofenig
Expires:  February 15, 2010                       Nokia Siemens Networks
                                                          H. Schulzrinne
                                                     Columbia University
                                                         August 14, 2009


Indirect Presence Publication with the Session Initiation Protocol(SIP)
              draft-garcia-geopriv-indirect-publish-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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

   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://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 15, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Garcia-Martin, et al.   Expires February 15, 2010               [Page 1]


Internet-Draft      SIP Indirect Presence Publication        August 2009


Abstract

   SIP is extended by the SIP-events framework to provide subscriptions
   and notifications of SIP events.  One example of such event
   notification mechanism is 'presence' and this presence information is
   carried in Presence Information Data Format (PIDF) documents.

   The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document
   is typically used when presentities publish their own presence since
   these presentities are typically the source of the information.
   However, there are cases when the presentity is not the direct source
   of the presence information.  One such example is location
   information where the end host may obtain a reference to location
   information as opposed to as a value.  The endpoint is typically not
   interested in knowing its own location information, but other users
   or entities might be.  So, if the endpoint gets its own location
   information with a reference and wants to publish it embedded in its
   presence information, it first needs to de-reference it for getting a
   value, and then it can embed that value in its presence information.
   While this is certainly a correct sequence, it adds a round-trip to
   the presence publication, in addition to a demand processing power
   and network bandwidth consumption.

   There is a need for a mechanism that the presentity can use to
   publish indirect references, such as indirect location references.
   This document discusses a few variants that may be used to provide
   this functionality.
























Garcia-Martin, et al.   Expires February 15, 2010               [Page 2]


Internet-Draft      SIP Indirect Presence Publication        August 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Geolocation Protocols Relationship . . . . . . . . . . . .  4
     1.2.  Case Study: Location URIs  . . . . . . . . . . . . . . . .  6
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  7
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     5.2.  Informational References . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






































Garcia-Martin, et al.   Expires February 15, 2010               [Page 3]


Internet-Draft      SIP Indirect Presence Publication        August 2009


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] is extended by the
   SIP-events framework [RFC3265] to provide subscriptions and
   notifications of SIP events.  One example of such event notification
   mechanism is 'presence'.  The presence information is typically
   carried in Extensible Markup Language (XML) [W3C.REC-xml-20060816]
   documents that are compliant with a given XML schema
   [W3C.REC-xmlschema-0-20041028].  These presence documents are called
   Presence Information Data Format (PIDF) documents [RFC3863].

   The SIP PUBLISH method specified in RFC 3903 [RFC3903] carrying a
   PIDF document is typically used when presentities publish their own
   presence information.  Usually the presentity can compose a quite
   detailed PIDF document, which is typically extended with a number of
   rich information, such as the Presence Data Model [RFC4479], Rich
   Presence Extensions to PIDF (RPID) [RFC4480], or the Contact
   Information to the Presence Information Data Format (CIPID)
   [RFC4481].

   In the mentioned extensions, the presentity is typically the source
   of the extended rich presence information.  However, there are
   occasions, when the presentity is not the direct source of the
   presence information.  One of these cases occurs when a presentity
   acquires its own location information from a HELD server
   [I-D.ietf-geopriv-http-location-delivery].  The HELD client on the
   end host can request Location URI (location by reference) as opposed
   to as a value (location by value).

1.1.  Geolocation Protocols Relationship

   Figure 1 depicts the geolocation protocol relationship.  A Location
   URI points to a Location Configuration Protocol (LCP) server that is
   able to provide location of a specific target.  The LCP server is
   able to associate the Location URI to the location of the target
   inside its administrative domain.  A target of location information
   implements a Location Configuration Protocol (LCP) client.  The LCP
   client first uses the location configuration protocol to acquire its
   location information (see step 1 in Figure 1).  We assume this
   location information is delivered in the format of a reference.

   Then the LCP client needs to de-reference the acquired reference.
   This done in step 2 in Figure 1 and uses a location de-reference
   protocol to get a value of its location information.  Last, the end
   host can embed its location information in the location conveyance
   protocol (step 3 in in Figure 1) and send it to a location recipient,
   such as a presence server.




Garcia-Martin, et al.   Expires February 15, 2010               [Page 4]


Internet-Draft      SIP Indirect Presence Publication        August 2009


          +-----------+               +------------+
          |           |               | Location   |
          |    LCP    |               | recipient/ |
          |   server  |               | Presence   |
          |           |               | cerver     |
          +-----------+               +------------+
              ^  ^                        ^
   Geopriv    |  | Geopriv              //
   Location   |  | Location           //
   Dereference|  | Configuration    //
   Protocol   |  | Protocol       //
   (2)        |  | (1)          //
              |  |            //   Geopriv Location
              v  v          //     Conveyance Protocol
          +-----------+   //       (e.g., SIP)
          | Target /  | //         (3)
          | End host  |v
          | LCP client|
          +-----------+

           Figure 1: Current Geolocation Protocols Relationship

   This document, though, discusses proposals for the scenario
   envisioned in Figure 2, where the target or end hosts acquires a
   reference via the location configuration protocol (step 1 in
   Figure 2), sends such reference in a location conveyance protocol or
   presence publication (step 2), and lets the location recipient or
   presence server to acquire the actual value according to the
   reference (step 3).

   The kind of reference that is first acquired and then send to the
   location recipient determines the value that the location recipient
   gets in step 3.  Section 1.2 discusses location URIs.


















Garcia-Martin, et al.   Expires February 15, 2010               [Page 5]


Internet-Draft      SIP Indirect Presence Publication        August 2009


   +-----------+  Geopriv      +------------+
   |           |  Location     | Location   |
   |    LCP    |<------------->| Recipient/ |
   |   server  |  Dereference  | Presence   |
   |           |  Protocol (3) | Server     |
   +-----------+               +------------+
         ^                         ^
         | Geopriv               //
         | Location            //
         | Configuration     //
         | Protocol        //
         | (1)           //
         |             //   Geopriv Location
         v           //     Conveyance Protocol
   +-----------+   //       (e.g., SIP)
   | Target /  | //         (2)
   | End Host  |v
   | LCP Client|
   +-----------+

           Figure 2: Proposed Geolocation Protocols Relationship

1.2.  Case Study: Location URIs

   A Location URI points to a Location Configuration Protocol (LCP)
   server that is able to provide location of a specific target.  The
   LCP server is able to associate the Location URI to the location of
   the target inside its administrative domain.  However, the resolution
   step from a Location URI to a Location Object may be influenced by
   different parameters and by the location URI itself.

   Depending on the value returned as an invocation to the reference
   URI, we can classify location URI in two cases:

   Static location URIs:

      Whenever a static location URI is de-referenced, the same static
      location is returned.  These URIs are typically constrained by a
      start and a stop time.  For example, the location of Alice on a
      her 21st birthday at 10:00 AM is a static location URI, because
      she was in a place at that time and date, so, the location does
      not change.  The path that Alice took on the same day from 12 PM
      to 2 PM is also a static location URI, because as a result of its
      de-reference the location recipient will get the same collection
      of locations.






Garcia-Martin, et al.   Expires February 15, 2010               [Page 6]


Internet-Draft      SIP Indirect Presence Publication        August 2009


   Dynamic location URIs:

      Every time a dynamic location URI is de-referenced a new
      (potentially different) location is provided.  Typically these
      URIs do not have a constraint with the time.  Assume Alice
      acquires a URI that points to her current location, every time
      that a location recipient invokes the URI, he will get a different
      location (assuming that Alice's location changes).  Another
      example can be when Alice acquires a URI that provides her
      location between today noon and now, so, when the location
      recipient invokes the URI, he will be accumulating further
      locations, providing that Alice is changing her location.

   Dynamic location URIs have stronger privacy considerations, because
   the target does not really know what is the location supplied at any
   time.  However, the target has mechanisms to constraint the
   availability of a dynamic location URI, for example, by imposing a
   time when the reference expires.

   With either dynamic or location URIs there is a need for a mechanism
   that allows the presentity to publish indirect references.  In
   absence of this mechanism, the presentity would need to retrieve its
   location information by value, compose a PIDF document that contains
   it, and publish it to the presence server.

1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

   This version of the document does not contain normative text at this
   point in time given the different options that are available to solve
   the described problem.


2.  Overview of Operation

   A presentity first send a location request
   [I-D.ietf-geopriv-http-location-delivery] over the binding protocol,
   indicating the desire to receive its location by reference.  This is
   done by including a <locationType> element with the value set to
   "locationURI".  The server responds with one or more <locationURI>
   elements, typically with different URI schemas.  The presentity then
   selects a SIP or SIPS URI scheme, and:

   [[Editor's Note:  We have several options here.  We need to pick



Garcia-Martin, et al.   Expires February 15, 2010               [Page 7]


Internet-Draft      SIP Indirect Presence Publication        August 2009


   one.]]

   1.  Inserts the value of the locationURI in a Geolocation header
       field, as specified in the SIP Location Conveyance document
       [I-D.ietf-sipcore-location-conveyance].  Then, it sends it in a
       PUBLISH request, which may also contain a regular PIDF document.

          The drawback of this approach is that it is specific to
          geolocation and difficult to generalize.  Furthermore, it is
          not possible to determine whether the server actually
          understands the provided references.

   2.  Inserts the locationURI value in a new extension to the PIDF to
       carry an indirect reference.  The extension consists of a new
       element called "indirect-reference", which is inserted.  Then,
       the PIDF is attached to a PUBLISH request and sent to the
       presence server.

          The drawback of this approach is that it is still not possible
          to determine whether the server supports it.  Also, if the
          referred document is a PIDF, then the semantics would be "here
          is the reference to an additional PIDF document" as opposed to
          "include this position some elements that are indirectly
          referred".  The advantage of this approach is that this
          extension is general enough to include any indirect reference,
          for example, to a calendar that can publish RFC 4481
          extensions to PIDF.

   3.  Creates an additional XML document (independent of a PIDF
       document) and if the presentity also attaches a regular PIDF
       document, then both documents are put into a MIME multipart/
       related wrapper, which becomes the payload of the PUBLISH
       request.  Otherwise, the sole new XML document is attached to the
       PUBLISH request and sent to the presence server.

          The drawback of this approach is the shy support for multipart
          MIME bodies.  The advantage is a clean solution with no
          interferences with PIDF.  It also allows to include an
          indirect-reference of any kind.


   When the presence server receives a PUBLISH request that contains an
   indirect reference, it tries to de-reference, e.g., invoke the URI
   included there.  If the result of such operation is that the presence
   server gets a presentity's PIDF document, then it should consider the
   document as directly published from the presentity, and should
   composed a merged PIDF document, potentially including other sources
   of presence information.



Garcia-Martin, et al.   Expires February 15, 2010               [Page 8]


Internet-Draft      SIP Indirect Presence Publication        August 2009


3.  IANA Considerations

   This document has no actions for IANA.


4.  Security considerations

   The security considerations described in SIP Location Conveyance
   [I-D.ietf-sipcore-location-conveyance]are applicable to this
   document.


5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

5.2.  Informational References

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-15 (work in
              progress), June 2009.

   [I-D.ietf-sipcore-location-conveyance]
              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sipcore-location-conveyance-01 (work in
              progress), July 2009.

   [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
              W., and J. Peterson, "Presence Information Data Format
              (PIDF)", RFC 3863, August 2004.

   [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
              for Event State Publication", RFC 3903, October 2004.




Garcia-Martin, et al.   Expires February 15, 2010               [Page 9]


Internet-Draft      SIP Indirect Presence Publication        August 2009


   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
              July 2006.

   [RFC4480]  Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
              Rosenberg, "RPID: Rich Presence Extensions to the Presence
              Information Data Format (PIDF)", RFC 4480, July 2006.

   [RFC4481]  Schulzrinne, H., "Timed Presence Extensions to the
              Presence Information Data Format (PIDF) to Indicate Status
              Information for Past and Future Time Intervals", RFC 4481,
              July 2006.

   [W3C.REC-xml-20060816]
              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E.,
              and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth
              Edition)", World Wide Web Consortium FirstEdition REC-xml-
              20060816, August 2006,
              <http://www.w3.org/TR/2006/REC-xml-20060816>.

   [W3C.REC-xmlschema-0-20041028]
              Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer
              Second Edition", World Wide Web Consortium
              Recommendation REC-xmlschema-0-20041028, October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.


Authors' Addresses

   Miguel A. Garcia-Martin
   Ericsson
   Calle Via de los Poblados 13
   Madrid, ES  28033
   Spain

   Email:  miguel.a.garcia@ericsson.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone:  +358 (50) 4871445
   Email:  Hannes.Tschofenig@gmx.net
   URI:    http://www.tschofenig.priv.at/





Garcia-Martin, et al.   Expires February 15, 2010              [Page 10]


Internet-Draft      SIP Indirect Presence Publication        August 2009


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   USA

   Phone:  +1 212 939 7042
   Email:  schulzrinne@cs.columbia.edu
   URI:    http://www.cs.columbia.edu/~hgs









































Garcia-Martin, et al.   Expires February 15, 2010              [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/