SIMPLE Working Group M. Garcia-Martin
Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks
Expires: August 21, 2008 H. Schulzrinne
Columbia University
February 18, 2008
Indirect Presence Publication with the Session Initiation Protocol(SIP)
draft-garcia-simple-indirect-presence-publish-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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
Garcia-Martin, et al. Expires August 21, 2008 [Page 1]
Internet-Draft SIP Indirect Presence Publication February 2008
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 August 21, 2008 [Page 2]
Internet-Draft SIP Indirect Presence Publication February 2008
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
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Garcia-Martin, et al. Expires August 21, 2008 [Page 3]
Internet-Draft SIP Indirect Presence Publication February 2008
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 August 21, 2008 [Page 4]
Internet-Draft SIP Indirect Presence Publication February 2008
+-----------+ +------------+
| | | 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 August 21, 2008 [Page 5]
Internet-Draft SIP Indirect Presence Publication February 2008
+-----------+ 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 August 21, 2008 [Page 6]
Internet-Draft SIP Indirect Presence Publication February 2008
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 August 21, 2008 [Page 7]
Internet-Draft SIP Indirect Presence Publication February 2008
one.]]
1. Inserts the value of the locationURI in a Geolocation header
field, as specified in the SIP Location Conveyance document
[I-D.ietf-sip-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 August 21, 2008 [Page 8]
Internet-Draft SIP Indirect Presence Publication February 2008
3. IANA Considerations
This document has no actions for IANA.
4. Security considerations
The security considerations described in SIP Location Conveyance
[I-D.ietf-sip-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
[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.
[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]
Garcia-Martin, et al. Expires August 21, 2008 [Page 9]
Internet-Draft SIP Indirect Presence Publication February 2008
Maler, E., Paoli, J., Bray, T., Sperberg-McQueen, C., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-xmlschema-0-20041028]
Fallside, D. and P. Walmsley, "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>.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-09 (work in progress),
November 2007.
[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-04 (work in
progress), January 2008.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia Siemens Networks
P.O.Box 6
Nokia Siemens Networks, FIN 02022
Finland
Email: miguel.garcia@nsn.com
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Garcia-Martin, et al. Expires August 21, 2008 [Page 10]
Internet-Draft SIP Indirect Presence Publication February 2008
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 August 21, 2008 [Page 11]
Internet-Draft SIP Indirect Presence Publication February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Garcia-Martin, et al. Expires August 21, 2008 [Page 12]