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

Versions: 00 01

GEOPRIV                                                 M. Garcia-Martin
Internet-Draft                                                  Ericsson
Intended status: Standards Track                           H. Tschofenig
Expires: April 29, 2010                           Nokia Siemens Networks
                                                          H. Schulzrinne
                                                     Columbia University
                                                              M. Thomson
                                                      Andrew Corporation
                                                        October 26, 2009


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

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 April 29, 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 April 29, 2010                 [Page 1]


Internet-Draft      SIP Indirect Presence Publication       October 2009


Abstract

   A method for indirectly publishing presence information is described.
   This allows a presentity user agent to publish a URI that can be used
   by the presence agent to retrieve presence information.  A presence
   agent is then better able to acquire dynamic presence information
   without relying on the presentity user agent.  This also allows a
   presentity user agent to delegate responsibility for managing
   changing presence data to the source of that information.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Geolocation Protocols Relationship . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Indirect Presence Publish  . . . . . . . . . . . . . . . . . .  6
     2.1.  Multiple Presence Sources  . . . . . . . . . . . . . . . .  6
   3.  Location header  . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Indicating and Requiring Support of Indirect Publish . . . . .  8
   5.  De-reference Errors  . . . . . . . . . . . . . . . . . . . . .  8
   6.  The Geolocation Header . . . . . . . . . . . . . . . . . . . .  9
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security considerations  . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informational References . . . . . . . . . . . . . . . . . 14
   Appendix A.  Alternative Solutions Considered  . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16





















Garcia-Martin, et al.    Expires April 29, 2010                 [Page 2]


Internet-Draft      SIP Indirect Presence Publication       October 2009


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] is extended by the
   SIP-events [RFC3265] 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) [RFC3863] documents.

   Two sources of presence information have been established.  The
   presence agent might be able to acquire presence data independently,
   or it might rely on the presentity user agent providing that
   information.  Use of the SIP PUBLISH method for the purpose of
   informing the presence agent of state is described in RFC 3903
   [RFC3903].

   Many existing elements of presence 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], are acquired directly from the
   presentity user agent.  However, there are cases when the presentity
   user agent is not the direct source of the presence information.

   One such example is location information.  A presentity user agent
   might acquire location information from a Location Information Server
   (LIS).  Due to the dynamic nature of location information, a LIS
   might provide location information by reference rather than value.
   One of these cases occurs when a presentity user agent acquires its
   own location information from a LIS using HELD
   [I-D.ietf-geopriv-http-location-delivery].  A reference in the form
   of a location URI allows the holder of the reference to obtain
   location information at any time directly from the LIS.

   This document describes a means for a presentity user agent to
   publish presence information indirectly using a URI.  The presence
   agent is then able to obtain information directly from the source of
   the data.  This removes some of the burden of managing dynamic
   content from the presentity user agent, as they do not need to
   monitor changes to presence data and publish updates as changes
   occur.

   Presence agents might provide a complex presence document that is
   assembled from multiple sources.  A means is provided where the
   presence agent is able to assemble a presence document.

   The mechanism in this document was originally designed with location
   information in mind, but it can be equally applied to any other form
   of dynamic presence data.




Garcia-Martin, et al.    Expires April 29, 2010                 [Page 3]


Internet-Draft      SIP Indirect Presence Publication       October 2009


1.1.  Geolocation Protocols Relationship

   [ED: move these pictures out of here.  We need pictures that aren't
   location-specific so that readers don't mistakenly think that this is
   just about location.  That's already compounded by using "Location",
   so this needs to be very clear.  Maybe this could be made an
   appendix.]

   The PIDF location object (PIDF-LO) [RFC4119] establishes location
   information as a form of presence information.  Therefore, a presence
   agent might provide location information along with other information
   such as status or mood ([RFC4480]).

   A presence service commonly needs to rely on other entities to
   provide it with location information.  A presentity user agent might
   be able to provide location information, or it might interact with a
   Location Information Server (LIS) [I-D.ietf-geopriv-arch] to acquire
   that information.

   Figure 1 depicts the geolocation protocol relationship.  A location
   URI points to a resource on a LIS that is able to provide location of
   a specific Target.  The LIS is able to associate the Location URI to
   the location of the Target inside its administrative domain.  In this
   case, the Target in question is the presentity user agent.

            +-----------+               +------------+
            |           |               | Location   |
            |    LIS    |               | Recipient/ |
            |           |               | Presence   |
            |           |               | Agent      |
            +-----------+               +------------+
                ^  ^                           ^
                |  |                         //
   Location     |  | Location              //
   Configuration|  | Dereference         //
   Protocol     |  | Protocol          //
   (1)          |  | (2)             //
                |  |               //   Location Conveyance
                v  v             //     Protocol (e.g., SIP)
            +------------+     //       (3)
            |            |   //
            | Target /   | //
            | Presentity |<
            |            |
            +------------+

           Figure 1: Presence and Geolocation Protocols (Values)




Garcia-Martin, et al.    Expires April 29, 2010                 [Page 4]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   The following three steps are followed in Figure 1:
   (1).  The presentity user agent (or Target) acquires a location URI
         from the Location Information Server (LIS) using a Location
         Configuration Protocol (LCP).
   (2).  Before publishing location information to the presence agent,
         the target must first de-reference the location URI to acquire
         a location value.  Alternatively, location information might be
         acquired from the LIS by value.
   (3).  Finally, the presentity user agent assembles an updated
         presence document and publishes this to the presence agent.

   A location URI [I-D.ietf-geopriv-lbyr-requirements] provides
   additional flexibility that this process does not take advantage of.
   A location URI provides a way for a location recipient to have
   control over when and how location information is acquired.  A
   location URI can be used by the presence agent to acquire location
   information according to the needs of the watchers that require the
   information.

   This document enables the scenario shown in Figure 2, where the
   presentity user agent is able to acquire a location URI (step 1) and
   publish the URI (step 2).  The presence agent is then able to acquire
   location information directly from the LIS (step 3).

    +-----------+               +------------+
    |           |  Location     | Location   |
    |    LIS    |<------------->| Recipient/ |
    |           |  Dereference  | Presence   |
    |           |  Protocol (3) | Agent      |
    +-----------+               +------------+
          ^                            ^
          |                          //
          | Location               //
          | Configuration        //
          | Protocol           //
          | (1)              //
          |                //   Location Conveyance
          v              //     Protocol (e.g., SIP)
   +-------------+     //       (2)
   |             |   //
   | Target /    | //
   | Presentity  |<
   |             |
   +-------------+

         Figure 2: Presence and Geolocation Protocols (References)





Garcia-Martin, et al.    Expires April 29, 2010                 [Page 5]


Internet-Draft      SIP Indirect Presence Publication       October 2009


1.2.  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 document uses SIP events terminology from [RFC3265], presence
   terminology from [RFC3903], and Geopriv terminology from
   [I-D.ietf-geopriv-arch].


2.  Indirect Presence Publish

   A presentity user agent first acquires a reference to presence
   information in the form of a URI.

      For location information, a location URI can be obtained using a
      location configuration protocol, such as HELD
      [I-D.ietf-geopriv-http-location-delivery].  For HELD, this is done
      by including a "locationType" element with the value set to
      "locationURI".

   The presentity user agent then publishes the URI (or URIs) to a
   presence agent, using the "Location" header (see Section 3).

      This header is not specific to physical location information.  Do
      not confuse the "Location:" header with the "Geolocation:" header.
      The former inherits its meaning from the HTTP [RFC2616] header of
      the same name, the name being a logical location or address.  The
      latter is specifically restricted to physical location
      information.

   The presence agent de-references URIs to acquire the referenced
   information.  A "sip:", "sips:" or "pres:" URI is dereferenced by
   subscribing for the presence event package at the given URI; a
   "http:" or "https:" URI is dereferenced following the rules in
   [I-D.winterbottom-geopriv-deref-protocol].  Other URIs MUST not be
   used unless a method is defined for that URI that produces a presence
   document.

2.1.  Multiple Presence Sources

   Indirect publish establishes multiple presence sources for a presence
   agent.  In addition to the presentity user agent, multiple indirect
   sources of presence data can be identified using the "Location"
   header.




Garcia-Martin, et al.    Expires April 29, 2010                 [Page 6]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   The presence agent acquires presence information from each source.
   This results in multiple presence documents.  These documents are
   combined to produce a single document.

   The single presence document contains the union of the set of tuples
   (or the [RFC4479] equivalents of "device" or "person") from every
   presence document thus obtained.  Tuple identifiers are modified as
   necessary to prevent collisions in the identifier namespace; this
   might be done be prefixing each tuple with the source identifier.

   The presentity identifier in the final document is the presentity
   identifier in any presence document provided by the presentity user
   agent itself.  Presentity identifiers from other sources are ignored.

   The presence agent then monitors the state of the referenced presence
   document according to the needs of watchers.  The presence agent
   updates its own copy of the presence data from each source.  As
   presence state provided by each source changes, this is combined with
   data from other sources and watchers are notified accordingly.

   A partial presence document [RFC5264] MAY be used if the presence
   agent supports this format.  In this case, partial differences
   ("pidf-diff" documents) provided from a given source are applied the
   information retrieved previously from the same source.


3.  Location header

   The "Location" header includes a URI for information that might
   otherwise be included in the body of a request.  It is defined by the
   following ABNF [RFC5234], using the conventions and definitions in
   [RFC3261]:

   location-header        = "Location" HCOLON location-header-value
   location-value         = (location-item *(COMMA location-item))
   location-item          = LAQUOT location-URI RAQUOT
                          / *(SEMI location-param)
   location-URI           = absoluteURI
   location-param         = location-src-param / generic-param
   location-src-param     = "src" EQUAL token

   This document defines the "Location" header field as valid in SIP
   PUBLISH [RFC3903] requests only.

   Each URI in the "Location" header MAY be tagged with a "src"
   parameter, identifying the source of the data that is found at the
   URI.  This identifier is an opaque tag that is used to identify
   different URIs as having the same source.  An included URI with no



Garcia-Martin, et al.    Expires April 29, 2010                 [Page 7]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   "src" parameter is considered to have a different "src" parameter to
   any other included URI.  URIs with identical "src" parameters
   indicate that they are alternative URIs (possibly with different
   schemes) for the same information.

   A presence agent MUST only attempt to use a single URI from each set
   with a unique "src" parameter.  Presence information from any given
   URI can only be updated or replaced with presence information from a
   URI with the same "src" parameter.

   Each PUBLISH message contains a complete set of URIs.  The presence
   agent MUST NOT use a URI if the most recent "Location" header
   received does not include that URI.  The "Location" header can be
   omitted in a request, which does not alter the set of URIs used by
   the presence agent.  Providing an empty "Location" header stops the
   presence agent from using any URIs.


4.  Indicating and Requiring Support of Indirect Publish

   A SIP option tag of "indirectpub" is created for use in the "Require"
   header.  This is used by a presentity user agent to provide surety
   that any request to indirectly publish presence data has been
   understood by the presence agent.

   Attempts to publish indirectly MUST use this option tag in the
   "Require" header.  If an attempt to publish information indirectly
   fails, the presence agent includes the tag in the "Unsupported"
   header of a 420 (Bad Extension) response.  Upon receiving this
   response, the presentity user agent SHOULD attempt to de-reference
   the URI and re-attempt the request with the presence information
   included directly unless it is unable or local policy dictates
   otherwise.


5.  De-reference Errors

   Indirect publish adds an additional de-reference step to the publish
   process.  This adds additional failure scenarios.  The presence agent
   might be unable to de-reference a URI for a number of reasons:
   o  the indicated host might be unreachable
   o  the URI might be badly formed or it might refer to a non-existent
      destination
   o  the URI schemes - and the de-reference mechanisms they indicate -
      provided might not be supported by the presence agent
   o  the URI might produce information that is not presence data





Garcia-Martin, et al.    Expires April 29, 2010                 [Page 8]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   o  the presence agent might not be authorized to retrieve the
      indicated data and the de-reference request might be rejected by
      the server

   Some of these errors might be detected during the processing of the
   request.  Others might be encountered later by the presence agent.  A
   mechanism is provided to indicate to the presentity user agent when
   the presence agent detects an error while processing the request.

   [TBD: need to work out how to do this.  Either way, it's almost
   essential to indicate to the presentity user agent that something has
   failed.  There are many reasons that a URI might not be accessible,
   in many cases, it might be useful if the presentity user agent could
   fall back on providing information by value if the URI can't be used.
   It might be that the presentity user agent is more able to
   dereference the URI, or might be able to look for alternative sources
   for the information.]

   [The lessons of the Geolocation header might be of some use here.]


6.  The Geolocation Header

   [ED: Useful?  Unnecessary complication?  Initial inclination is
   toward the latter.]

   A presence agent MAY choose to treat a Geolocation header
   [I-D.ietf-sipcore-location-conveyance] in a PUBLISH request as though
   it were a "Location" header.  The "Require" header of the request
   MUST include "indirectpub" in this case; if it does not, the presence
   agent cannot assume that the information was intended to be
   published.

   The contents of the "Geolocation" header MUST be ignored if a
   "Location" header is present.


7.  Example

   In the Figure 3, the presentity user agent (PUA) acquires and
   publishes a reference to presence data that is served by a presence
   source (PS).  The presence agent (PA) provides this information to a
   watcher along with information included by the presentity user agent.
   Only request messages are shown for clarity.







Garcia-Martin, et al.    Expires April 29, 2010                 [Page 9]


Internet-Draft      SIP Indirect Presence Publication       October 2009


        PUA              PS                   PA             WATCHER
         |               |                    |                 |
         |<-- Acquire -->|                    |<-- Establish -->|
         |   Reference   |                    |   Subscription  |
         |               |                    |                 |
         |------- M1: Publish Reference ----->|                 |
         |               |                    |                 |
         |               |<-- M2: Subscribe --|                 |
         |               |                    |                 |
         |               |--- M3: Notify ---->|                 |
         |               |                    |                 |
         |               |                    |-- M4: Notify -->|
         |               |                    |                 |
         |               |       ...          |                 |
         |               |                    |                 |
         |               |----- Notify ------>|                 |
         |               |                    |                 |
         |               |                    |---- Notify ---->|
         |               |                    |                 |
         .               .                    .                 .

                                 Figure 3

   A presentity user agent acquires a URI that refers to presence
   information.  In this example, it is also assumed that the watcher
   has also established a subscription.

   The presentity user agent publishes this information to a presence
   agent.  The SIP PUBLISH might also include information that the
   presentity user agent directly provides, such as the status.





















Garcia-Martin, et al.    Expires April 29, 2010                [Page 10]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   M1:
     PUBLISH sip:presentity@example SIP/2.0
     To: <sip:presentity@example>
     From: <sip:presentity@example>;tag=1234wxyz
     Call-ID: 81818181@pua.example
     CSeq: 1 PUBLISH
     Max-Forwards: 70
     Event: presence
     Location: <pres:3cy89sckl@source.example>;src=abc123,
       <https://source.example/presence/3cy89sckl>;src=abc123
     Contact: presentity@pua.example
     Content-Type: application/pidf+xml
     Content-Length: ...

     <presence entity="pres:presentity@example">
       <tuple id="status>
         <!-- status tuple contents-->
       </tuple>
     </presence>

   The presence agent selects one location from each source and de-
   references this URI.  For a SIP URI ("sip:", "sips:", or "pres:")
   this requires a presence event package subscription.

   M2:
     SUBSCRIBE pres:3cy89sckl@source.example SIP/2.0
     To: <pres:3cy89sckl@source.example>
     From: <pres:pa.example>;tag=4567qwer
     Call-ID: 111222@example
     CSeq: 1 SUBSCRIBE
     Max-Forwards: 70
     Event: presence
     Expires: 3600
     Contact: sip:pa.example
     Content-Length: 0
















Garcia-Martin, et al.    Expires April 29, 2010                [Page 11]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   The presence source provides a notification containing presence
   information selects one location from each source and de-references
   this URI.  For a SIP URI ("sip:", "sips:", or "pres:") this requires
   a presence event package subscription.

   M3:
     NOTIFY pa.example SIP/2.0
     To: <pres:pa.example>
     From: <pres:3cy89sckl@source.example>;tag=7678fghj
     Call-ID: 111222@example
     CSeq: 1 NOTIFY
     Max-Forwards: 70
     Event: presence
     Subscription-State: active; expires=3599
     Contact: sip:source.example
     Content-Type: application/pidf+xml
     Content-Length: ...

     <presence entity="pres:3cy89sckl@source.example">
       <tuple id="geolocation">
         <!-- geolocation tuple contents -->
       </tuple>
     </presence>

   The presence agent then provides a notification to the watcher with
   this new presence data.

   M4:
     NOTIFY watcher@example SIP/2.0
     To: <pres:watcher@example>
     From: <pres:presentity@example>;tag=asd234
     Call-ID: 789678@example
     CSeq: 1 NOTIFY
     Max-Forwards: 70
     Event: presence
     Subscription-State: active; expires=3207
     Contact: sip:pa.example
     Content-Type: application/pidf+xml
     Content-Length: ...

     <presence entity="pres:presentity@example">
       <tuple id="status>
         <!-- status tuple contents-->
       </tuple>
       <tuple id="abc123-geolocation">
         <!-- geolocation tuple contents -->
       </tuple>
     </presence>



Garcia-Martin, et al.    Expires April 29, 2010                [Page 12]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   From this point, changes in presence state at the source trigger
   notifications to the presence agent.  This in turn triggers
   notifications to any watchers.


8.  IANA Considerations

   TBD: register SIP header, "indirectpub" option tag and establish
   parameter registry (pah).


9.  Security considerations

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

   Privacy protections are extremely important for presence information.
   Indirect publish potentially provides watchers and presence agents
   greater access to a user's private data.  A presence source


10.  References

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [I-D.winterbottom-geopriv-deref-protocol]
              Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
              Thomson, M., and M. Dawson, "A Location Dereferencing
              Protocol Using HELD",
              draft-winterbottom-geopriv-deref-protocol-04 (work in
              progress), July 2009.

   [I-D.ietf-sipcore-location-conveyance]
              Polk, J. and B. Rosen, "Location Conveyance for the



Garcia-Martin, et al.    Expires April 29, 2010                [Page 13]


Internet-Draft      SIP Indirect Presence Publication       October 2009


              Session Initiation Protocol",
              draft-ietf-sipcore-location-conveyance-01 (work in
              progress), July 2009.

10.2.  Informational References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

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

   [RFC5264]  Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
              Partial Presence Information", RFC 5264, September 2008.

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




Garcia-Martin, et al.    Expires April 29, 2010                [Page 14]


Internet-Draft      SIP Indirect Presence Publication       October 2009


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

   [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-16 (work in
              progress), August 2009.

   [I-D.ietf-geopriv-lbyr-requirements]
              Marshall, R., "Requirements for a Location-by-Reference
              Mechanism", draft-ietf-geopriv-lbyr-requirements-08 (work
              in progress), September 2009.

   [I-D.ietf-geopriv-arch]
              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
              Tschofenig, H., and H. Schulzrinne, "An Architecture for
              Location and Location Privacy in Internet Applications",
              draft-ietf-geopriv-arch-00 (work in progress), July 2009.


Appendix A.  Alternative Solutions Considered

   [ED: this section is a mess; it should be cleaned up and moved to an
   appendix.]

   The following alternative solutions were considered in the design of
   this solution:
   1.  Rather than using a header, additional SIP bodies could be
       defined.  This could be a PIDF extension, or a specialized
       format.  This has a number of advantages, particularly in terms
       of good protocol hygiene.  This potentially runs afoul of the shy
       support for multipart MIME in SIP agents.  As a PIDF extension,
       it's possible that multipart support is not required, but it
       would potentially be difficult to ensure that it is the presence
       agent that is performing the de-reference.
   2.  Integration with partial presence publish [RFC5264] was
       considered.  Including a URI in a "pidf-diff" document would
       provide an elegant way to integrate indirectly published data.
       However, RFC 5264 defines a format that cannot be extended.  The
       scheme chosen also provides less flexibility and is consequently
       significantly simpler.
   3.  It's possible that a mechanism is not necessary at all.  Presence
       sources could be given the information necessary to PUBLISH the
       information.  Mechanisms would need to be provided for this



Garcia-Martin, et al.    Expires April 29, 2010                [Page 15]


Internet-Draft      SIP Indirect Presence Publication       October 2009


       purpose.  Aside from the complexity of managing this
       relationship, it does not benefit from the ability to use an
       event-based subscription.  It is also more difficult to ensure
       that the presence source publishes when the presence agent (and
       watchers) need the information.
   4.  The SIP Location Conveyance [I-D.ietf-sip-location-conveyance]
       defines a Geolocation header field that could be used for
       indirect publish.  Limiting this solution to location information
       would be a constraint that would prevent this from use for other
       types of information.


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
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


   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 April 29, 2010                [Page 16]


Internet-Draft      SIP Indirect Presence Publication       October 2009


   Martin Thomson
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500
   AU

   Phone: +61 242 212915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/










































Garcia-Martin, et al.    Expires April 29, 2010                [Page 17]


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