One document matched: draft-garcia-geopriv-indirect-publish-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" 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 fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<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>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 242 212915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<date year="2009"/>
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<keyword>SIP</keyword>
<keyword>indirect</keyword>
<keyword>PUBLISH</keyword>
<abstract>
<t>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.
</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</xref> 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 <xref target="RFC3863">Presence Information Data Format
(PIDF)</xref> documents.</t>
<t>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 <xref target="RFC3903">RFC 3903</xref>.</t>
<t>Many existing elements of presence 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>, 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.
</t>
<t>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 <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref>. 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.
</t>
<t>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.
</t>
<t>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.
</t>
<!-- This mechanism builds on <xref target="RFC5264">RFC 5264</xref> to allow for publication
of partial presence information. We wish: RFC 5264 cannot be extended. -->
<t>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.
</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>[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.]
</t>
<t>The <xref target="RFC4119">PIDF location object (PIDF-LO)</xref> 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 (<xref
target="RFC4480"/>).
</t>
<t>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 <xref target="I-D.ietf-geopriv-arch">Location Information Server
(LIS)</xref> to acquire that information.
</t>
<t><xref target="fig-current-protocols"/> 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.
</t>
<figure anchor="fig-current-protocols"
title="Presence and Geolocation Protocols (Values)">
<artwork><![CDATA[
+-----------+ +------------+
| | | Location |
| LIS | | Recipient/ |
| | | Presence |
| | | Agent |
+-----------+ +------------+
^ ^ ^
| | //
Location | | Location //
Configuration| | Dereference //
Protocol | | Protocol //
(1) | | (2) //
| | // Location Conveyance
v v // Protocol (e.g., SIP)
+------------+ // (3)
| | //
| Target / | //
| Presentity |<
| |
+------------+
]]></artwork>
</figure>
<t>The following three steps are followed in <xref target="fig-current-protocols"/>:
<list style="format (%d).">
<t>The presentity user agent (or Target) acquires a location URI from the Location
Information Server (LIS) using a Location Configuration Protocol (LCP).
</t>
<t>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.
</t>
<t>Finally, the presentity user agent assembles an updated presence document and publishes
this to the presence agent.
</t>
</list></t>
<t>A <xref target="I-D.ietf-geopriv-lbyr-requirements">location URI</xref> 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.
</t>
<t>This document enables the scenario shown in <xref target="fig-proposed-protocols"/>,
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).
</t>
<figure anchor="fig-proposed-protocols"
title="Presence and Geolocation Protocols (References)">
<artwork><![CDATA[
+-----------+ +------------+
| | Location | Location |
| LIS |<------------->| Recipient/ |
| | Dereference | Presence |
| | Protocol (3) | Agent |
+-----------+ +------------+
^ ^
| //
| Location //
| Configuration //
| Protocol //
| (1) //
| // Location Conveyance
v // Protocol (e.g., SIP)
+-------------+ // (2)
| | //
| Target / | //
| Presentity |<
| |
+-------------+
]]></artwork>
</figure>
</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 document uses SIP events terminology from <xref target="RFC3265"/>, presence
terminology from <xref target="RFC3903"/>, and Geopriv terminology from <xref
target="I-D.ietf-geopriv-arch"/>.
</t>
</section>
</section>
<section title="Indirect Presence Publish" anchor="sec-overview">
<t>A presentity user agent first acquires a reference to presence information in the form of a
URI.
</t>
<t><list style="empty"><t>For location information, a location URI can be obtained using a
location configuration protocol, such as <xref
target="I-D.ietf-geopriv-http-location-delivery"> HELD </xref>. For HELD, this is done by
including a <spanx style="verb">locationType</spanx> element with the value set to <spanx
style="verb">locationURI</spanx>.
</t></list></t>
<t>The presentity user agent then publishes the URI (or URIs) to a presence agent, using the
<spanx style="verb">Location</spanx> header (see <xref target="header"/>).
</t>
<t><list style="empty"><t>This header is not specific to physical location information. Do
not confuse the <spanx style="verb">Location:</spanx> header with the <spanx
style="verb">Geolocation:</spanx> header. The former inherits its meaning from the <xref
target="RFC2616">HTTP</xref> header of the same name, the name being a logical location or
address. The latter is specifically restricted to physical location
information.</t></list></t>
<t>The presence agent de-references URIs to acquire the referenced information. A <spanx
style="verb">sip:</spanx>, <spanx style="verb">sips:</spanx> or <spanx
style="verb">pres:</spanx> URI is dereferenced by subscribing for the presence event package
at the given URI; a <spanx style="verb">http:</spanx> or <spanx style="verb">https:</spanx>
URI is dereferenced following the rules in <xref
target="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.
</t>
<section title="Multiple Presence Sources">
<t>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 <spanx style="verb">Location</spanx> header.
</t>
<t>The presence agent acquires presence information from each source. This results in
multiple presence documents. These documents are combined to produce a single document.
</t>
<t>The single presence document contains the union of the set of tuples (or the <xref
target="RFC4479"/> equivalents of <spanx style="verb">device</spanx> or <spanx
style="verb">person</spanx>) 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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>A <xref target="RFC5264">partial presence document</xref> MAY be used if the presence
agent supports this format. In this case, partial differences (<spanx
style="verb">pidf-diff</spanx> documents) provided from a given source are applied the
information retrieved previously from the same source.
</t>
</section>
</section>
<section anchor="header" title="Location header">
<t>The <spanx style="verb">Location</spanx> header includes a URI for information that might
otherwise be included in the body of a request. It is defined by the following <xref
target="RFC5234">ABNF</xref>, using the conventions and definitions in <xref
target="RFC3261"/>:
</t>
<figure>
<artwork type="abnf"><![CDATA[
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
]]></artwork>
</figure>
<t>This document defines the <spanx style="verb">Location</spanx> header field as valid in
<xref target="RFC3903">SIP PUBLISH</xref> requests only.
</t>
<t>Each URI in the <spanx style="verb">Location</spanx> header MAY be tagged with a <spanx
style="verb">src</spanx> 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 <spanx style="verb">src</spanx> parameter is
considered to have a different <spanx style="verb">src</spanx> parameter to any other
included URI. URIs with identical <spanx style="verb">src</spanx> parameters indicate that
they are alternative URIs (possibly with different schemes) for the same information.
</t>
<t>A presence agent MUST only attempt to use a single URI from each set with a unique <spanx
style="verb">src</spanx> parameter. Presence information from any given URI can only be
updated or replaced with presence information from a URI with the same <spanx
style="verb">src</spanx> parameter.
</t>
<t>Each PUBLISH message contains a complete set of URIs. The presence agent MUST NOT use a
URI if the most recent <spanx style="verb">Location</spanx> header received does not include
that URI. The <spanx style="verb">Location</spanx> header can be omitted in a request, which
does not alter the set of URIs used by the presence agent. Providing an empty <spanx
style="verb">Location</spanx> header stops the presence agent from using any URIs.
</t>
<!--
<t>An <spanx style="verb">expires</spanx> attribute MAY be provided to give the presence
agent an indication on the lifetime of the URI. After this time, the presence agent MUST
remove any associated presence information acquired from the URI and stop any attempts to
de-reference the URI. </t>
-->
</section>
<section title="Indicating and Requiring Support of Indirect Publish">
<t>A SIP option tag of <spanx style="verb">indirectpub</spanx> is created for use in the
<spanx style="verb">Require</spanx> 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.
</t>
<t>Attempts to publish indirectly MUST use this option tag in the <spanx
style="verb">Require</spanx> header. If an attempt to publish information indirectly fails,
the presence agent includes the tag in the <spanx style="verb">Unsupported</spanx> 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.
</t>
</section>
<section title="De-reference Errors">
<t>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:
<list style="symbols">
<t>the indicated host might be unreachable
</t>
<t>the URI might be badly formed or it might refer to a non-existent destination
</t>
<t>the URI schemes - and the de-reference mechanisms they indicate - provided might not be
supported by the presence agent</t>
<t>the URI might produce information that is not presence data
</t>
<t>the presence agent might not be authorized to retrieve the indicated data and the
de-reference request might be rejected by the server
</t>
</list>
</t>
<t>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.
</t>
<t>[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.]
</t>
<t>[The lessons of the Geolocation header might be of some use here.]
</t>
</section>
<section title="The Geolocation Header">
<t>[ED: Useful? Unnecessary complication? Initial inclination is toward the latter.]</t>
<t>A presence agent MAY choose to treat a <xref
target="I-D.ietf-sipcore-location-conveyance">Geolocation header</xref> in a PUBLISH request
as though it were a <spanx style="verb">Location</spanx> header. The <spanx
style="verb">Require</spanx> header of the request MUST include <spanx
style="verb">indirectpub</spanx> in this case; if it does not, the presence agent cannot
assume that the information was intended to be published.
</t>
<t>The contents of the <spanx style="verb">Geolocation</spanx> header MUST be ignored if a
<spanx style="verb">Location</spanx> header is present.
</t>
</section>
<section title="Example">
<t>In the <xref target="flow"/>, 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.
</t>
<figure anchor="flow"><artwork><![CDATA[
PUA PS PA WATCHER
| | | |
|<-- Acquire -->| |<-- Establish -->|
| Reference | | Subscription |
| | | |
|------- M1: Publish Reference ----->| |
| | | |
| |<-- M2: Subscribe --| |
| | | |
| |--- M3: Notify ---->| |
| | | |
| | |-- M4: Notify -->|
| | | |
| | ... | |
| | | |
| |----- Notify ------>| |
| | | |
| | |---- Notify ---->|
| | | |
. . . .
]]></artwork></figure>
<t>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.
</t>
<figure>
<preamble>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.
</preamble>
<artwork><![CDATA[
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>
]]></artwork>
</figure>
<figure>
<preamble>The presence agent selects one location from each source and de-references this
URI. For a SIP URI (<spanx style="verb">sip:</spanx>, <spanx style="verb">sips:</spanx>, or
<spanx style="verb">pres:</spanx>) this requires a presence event package subscription.
</preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<figure>
<preamble>The presence source provides a notification containing presence information
selects one location from each source and de-references this URI. For a SIP URI (<spanx
style="verb">sip:</spanx>, <spanx style="verb">sips:</spanx>, or <spanx
style="verb">pres:</spanx>) this requires a presence event package subscription.
</preamble>
<artwork><![CDATA[
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>
]]></artwork>
</figure>
<figure>
<preamble>The presence agent then provides a notification to the watcher with this new
presence data.
</preamble>
<artwork><![CDATA[
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>
]]></artwork>
</figure>
<t>From this point, changes in presence state at the source trigger notifications to the
presence agent. This in turn triggers notifications to any watchers.
</t>
</section>
<section title="IANA Considerations" anchor="sec-iana">
<t> TBD: register SIP header, <spanx style="verb">indirectpub</spanx> option tag and establish
parameter registry (pah).</t>
</section>
<section title="Security considerations" anchor="security">
<t>The security considerations described in SIP Location Conveyance <xref
target="I-D.ietf-sip-location-conveyance"/>are applicable to this document. </t>
<t>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 </t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3265"?>
<?rfc include="reference.RFC.5234" ?>
<?rfc include="reference.I-D.winterbottom-geopriv-deref-protocol"?>
<?rfc include="reference.I-D.ietf-sipcore-location-conveyance"?>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.2616" ?>
<?rfc include="reference.RFC.3863" ?>
<?rfc include="reference.RFC.3903" ?>
<?rfc include="reference.RFC.4119" ?>
<?rfc include="reference.RFC.4479" ?>
<?rfc include="reference.RFC.4480" ?>
<?rfc include="reference.RFC.4481" ?>
<?rfc include="reference.RFC.5264"?>
<?rfc include="reference.W3C.REC-xml-20060816"?>
<?rfc include="reference.W3C.REC-xmlschema-0-20041028"?>
<?rfc include="reference.I-D.ietf-sip-location-conveyance"?>
<?rfc include="reference.I-D.ietf-geopriv-http-location-delivery"?>
<?rfc include="reference.I-D.ietf-geopriv-lbyr-requirements"?>
<?rfc include="reference.I-D.ietf-geopriv-arch"?>
</references>
<section title="Alternative Solutions Considered">
<t>[ED: this section is a mess; it should be cleaned up and moved to an appendix.]
</t>
<t>The following alternative solutions were considered in the design of this solution:
<list style="numbers">
<t>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.
</t>
<t>Integration with <xref target="RFC5264">partial presence publish</xref> was considered.
Including a URI in a <spanx style="verb">pidf-diff</spanx> 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.
</t>
<t>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 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.
</t>
<t>The <xref target="I-D.ietf-sip-location-conveyance">SIP Location Conveyance</xref>
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.
</t>
<!--
<t>Insert the URI 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 user agent 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>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:16:13 |