One document matched: draft-garcia-geopriv-indirect-publish-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<rfc ipr="trust200902" docName="draft-garcia-geopriv-indirect-publish-00.txt" category="std">
<front>
<title abbrev="SIP Indirect Presence Publication"> Indirect Presence Publication with the
Session Initiation Protocol(SIP) </title>
<author initials="M" surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Ericsson</organization>
<address>
<postal>
<street>Calle Via de los Poblados 13</street>
<city>Madrid</city>
<region>ES</region>
<code>28033</code>
<country>Spain</country>
</postal>
<email>miguel.a.garcia@ericsson.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at/</uri>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<phone>+1 212 939 7042</phone>
<email>schulzrinne@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu/~hgs</uri>
</address>
</author>
<date year="2009"/>
<area>RAI</area>
<workgroup>GEOPRIV Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>indirect</keyword>
<keyword>PUBLISH</keyword>
<abstract>
<t>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.</t>
<t>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. </t>
<t> 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sec-intro">
<t> The <xref target="RFC3261">Session Initiation Protocol (SIP)
</xref> is extended by the <xref target="RFC3265"> SIP-events
framework </xref> to provide subscriptions and notifications of
SIP events. One example of such event notification mechanism is
'presence'. The presence information is typically carried in
<xref target="W3C.REC-xml-20060816" >Extensible Markup Language
(XML) </xref> documents that are compliant with a given <xref
target="W3C.REC-xmlschema-0-20041028">XML schema </xref>. These
presence documents are called <xref target="RFC3863">Presence
Information Data Format (PIDF) documents </xref>. </t>
<t> The SIP PUBLISH method specified in <xref
target="RFC3903">RFC 3903</xref> 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 <xref target="RFC4479">Presence Data
Model </xref>, <xref target="RFC4480">Rich Presence Extensions
to PIDF (RPID) </xref>, or the <xref target="RFC4481">Contact
Information to the Presence Information Data Format
(CIPID)</xref>. </t>
<t> 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 <xref
target="I-D.ietf-geopriv-http-location-delivery">HELD server
</xref>. The HELD client on the end host can request Location
URI (location by reference) as opposed to as a value (location
by value).</t>
<!-- The subsequent section illustrates an example of an end host
that obtains location URIs that are subsequently published to a
presence server. -->
<section title="Geolocation Protocols Relationship" anchor="sec-geo-prots">
<t>
<xref target="fig-current-protocols"/> 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 <xref
target="fig-current-protocols"/>). We assume this location
information is delivered in the format of a reference.
</t>
<t>
Then the LCP client needs to de-reference the acquired
reference. This done in step 2 in <xref
target="fig-current-protocols"/> 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 <xref
target="fig-current-protocols"/>) and send it to a location
recipient, such as a presence server.
</t>
<figure anchor="fig-current-protocols"
title="Current Geolocation Protocols Relationship">
<artwork><![CDATA[
+-----------+ +------------+
| | | 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|
+-----------+
]]></artwork>
</figure>
<t>
This document, though, discusses proposals for the scenario
envisioned in <xref target="fig-proposed-protocols"/>, where
the target or end hosts acquires a reference via the
location configuration protocol (step 1 in <xref
target="fig-proposed-protocols"/>), 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).
</t>
<t>
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. <xref
target="sec-location-uris"/> discusses location URIs.
</t>
<figure anchor="fig-proposed-protocols"
title="Proposed Geolocation Protocols Relationship">
<artwork><![CDATA[
+-----------+ 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|
+-----------+
]]></artwork>
</figure>
</section>
<section title="Case Study: Location URIs" anchor="sec-location-uris">
<t> 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. </t>
<t>
Depending on the value returned as an invocation to the
reference URI, we can classify location URI in two cases:
</t>
<t>
<list style="hanging">
<t hangText="Static location URIs:"><vspace
blankLines="1"/> 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.
</t>
<t hangText="Dynamic location URIs:"><vspace
blankLines="1"/> 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.
</t>
</list>
</t>
<t>
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.
</t>
<t>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. </t>
</section>
<section title="Terminology">
<t> 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, <xref target="RFC2119">RFC 2119</xref>. </t>
<t>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.</t>
</section>
</section>
<section title="Overview of Operation" anchor="sec-overview">
<t>A presentity first send a <xref target="I-D.ietf-geopriv-http-location-delivery"> location
request </xref> 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: </t>
<t>[[Editor's Note: We have several options here. We need to pick one.]]</t>
<t>
<list style="numbers">
<t> Inserts the value of the locationURI in a Geolocation header field, as specified in
the <xref target="I-D.ietf-sipcore-location-conveyance">SIP Location Conveyance
document</xref>. Then, it sends it in a PUBLISH request, which may also contain a
regular PIDF document. <vspace blankLines="1"/><list style="empty">
<t>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.<vspace blankLines="1"/>
</t>
</list>
</t>
<t>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. <vspace blankLines="1"/><list style="empty">
<t> 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.<vspace blankLines="1"/>
</t>
</list>
</t>
<t>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. <vspace blankLines="1"/><list style="empty">
<t> 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.<vspace blankLines="1"/></t>
</list>
</t>
</list>
</t>
<t> 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. </t>
</section>
<section title="IANA Considerations" anchor="sec-iana">
<t> This document has no actions for IANA. </t>
</section>
<section title="Security considerations" anchor="security">
<t>The security considerations described in SIP Location Conveyance <xref
target="I-D.ietf-sipcore-location-conveyance"/>are applicable to this document. </t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3265"?>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.3863" ?>
<?rfc include="reference.RFC.3903" ?>
<?rfc include="reference.RFC.4479" ?>
<?rfc include="reference.RFC.4480" ?>
<?rfc include="reference.RFC.4481" ?>
<?rfc include="reference.W3C.REC-xml-20060816"?>
<?rfc include="reference.W3C.REC-xmlschema-0-20041028"?>
<?rfc include="reference.I-D.ietf-sipcore-location-conveyance"?>
<?rfc include="reference.I-D.ietf-geopriv-http-location-delivery"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref CDATA -->
<!--
Request:
<?xml version="1.0" encoding="UTF-8"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<locationType exact="true">locationURI</locationType>
</locationRequest>
Response:
<?xml version="1.0" encoding="UTF-8"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:geopriv:held file:/C:/Documents%20and%20Settings/demsjn18/Desktop/held.xsd"
code="success" message="OK">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</locationURI>
<locationURI>sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com</locationURI>
</locationUriSet>
</locationResponse>
-->
| PAFTECH AB 2003-2026 | 2026-04-23 11:21:20 |