One document matched: draft-garcia-sipping-file-event-package-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="full3978" category="std">
<front>
<title abbrev="File Event Package in SIP">
A Session Initiation Protocol (SIP) Event Package and Data
Format for Describing Files
</title>
<author initials="M." surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>P.O.Box 6</street>
<city>Nokia Siemens Networks</city>
<region>FIN</region>
<code>02022</code>
<country>Finland</country>
</postal>
<email>miguel.garcia@nsn.com</email>
</address>
</author>
<author initials="M" surname="Matuszewski" fullname="Marcin Matuszewski">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O.Box 407</street>
<city>NOKIA GROUP</city> <region>FIN</region><code>00045</code>
<country>Finland</country>
</postal>
<email>marcin.matuszewski@nokia.com</email>
</address>
</author>
<date day="16" month="November" year="2007" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>file</keyword>
<keyword>event</keyword>
<keyword>package</keyword>
<keyword>SIP</keyword>
<abstract>
<t>
This document specifies the format and semantics associated to a
'file' event package that allows SIP endpoints to publish the
availability of files. A file can be, for example, images, video
files, audio files, etc. The event package reuses the eXtended
Mark-up Language (XML) 'file-metadata' document to provide file
descriptions. This event package also allows SIP endpoints to
subscribe to changes in the availability of files, or perform
searches for the availability and location of a given
file. Support for partial notifications and publications is also
accomplished by using XML patch operations.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
There are scenarios where a SIP endpoint has a number of
available files that can be offered for public disposal or for a
limited number of authorized users. One of these cases is, for
example, when Alice takes some pictures with her camera phone
and she wants to share them within a community. This requires a
mechanism that allows Alice to describe the files she wants to share.
</t>
<t>
In another scenario, Alice might be interested in finding out
the availability of a given file, defined by a set of
parameters. Think, for example, of Alice trying to find pictures
of the bowling tournament that took place recently in her home
town. This implies a mechanism whereby Alice can perform
searches of available files. The user who performs the
search identifies one or more aspects of the file she is
searching, but probably she is not able to provide a full
description of the file.
</t>
<t>
<xref target="RFC3261">SIP </xref> provides an extensible <xref
target="RFC3265"> event mechanism </xref> that is suitable for
our needs. We enable the above scenarios by defining a SIP event
package for file metadata publication and search. We reuse the
'file-metadata' document format specified in the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format
for describing files </xref>. All together, they allow an Event
Publication Agent (EPA) to provide a description of locally
available files in a <xref target="RFC3903"> PUBLISH
request</xref>. In a community, there can be an Event State
Compositor that aggregates shared files available at different
endpoints. The Event State Compositor (ESC) that receives the
PUBLISH request processes 'file-metadata' documents according to
a well defined strategy (which is outside the scope of this
document). For example, the ESC can be a centralized
intermediary facilitator for a given community, or it can be a
super-node of a SIP Peer-to-Peer (P2P) network.
</t>
<t>
A user that searches for one or more files issues a
SUBSCRIBE request (either a subscription or a fetch of state,
see <xref target="RFC3265">RFC 3265 </xref>) to the 'file'
event package. Because a subscription to all of the files
published in the community is likely to contain a large amount
of data, the subscriber will typically attach a <xref
target="RFC4661"> filter </xref> that describes the files
under search. This will result in the generation of one or more
NOTIFY requests that contains the searched items. Once the
information on files is retrieved, the subscriber can use
any suitable mechanism (such as the one defined in <xref
target="I-D.ietf-mmusic-file-transfer-mech">"Session Description
Protocol (SDP) Offer/Answer Mechanism to Enable File
Transfer"</xref>) to actually download the file. Such file
transfer mechanisms are outside the scope of this memo.
</t>
<t>
In the file descriptor, sometimes the URI points to the file
itself itself (such as an HTTP URI that points to an image
file). In other cases the URI merely resolves to a host where
the content is available (for example, the SIP URI of a camera
phone that stores images).
</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> and indicate
requirement levels for compliant implementations.
</t>
</section>
<section title="The 'file' Event Package">
<t>
<xref target="RFC3265"> RFC 3265 </xref> defines a SIP extension
for subscribing to, and receiving notifications of changes
(events) in the state of remote nodes. It leaves the definition
of many aspects of these events to concrete extensions, known as
event packages. This document qualifies as an event package.
This section fills in the information required for all event
packages by <xref target="RFC3265">RFC 3265 </xref>.
</t>
<t>
Additionally, <xref target="RFC3903"> RFC 3903 </xref> defines
an extension that allows SIP User Agents to publish event
state. According to <xref target="RFC3903"> RFC 3903 </xref> any
event package intended to be used in conjunction with the SIP
PUBLISH method has to include a considerations section. This
section also fills the information for all event packages to be
used with PUBLISH requests.
</t>
<t>
We define a new 'file' event package. Event Publication
Agents (EPA) use PUBLISH requests to inform an Event State
Compositor (ESC) of changes in the 'file' event package. The
ESC, acting as a notifier, notifies subscribers to the
'file' event package when changes occur.
</t>
<section title="Package Name">
<t>
The name of this package is 'file'. As specified in <xref
target="RFC3265"> RFC 3265 </xref>, this value appears in the
Event header field present in SUBSCRIBE and NOTIFY
requests. As specified in the <xref target="RFC3903"> RFC 3903
</xref>, this value appears as well in the Event header field
present in PUBLISH requests.
</t>
</section>
<section title="Event Package Parameters">
<t>
<xref target="RFC3265">RFC 3265 </xref> allows event packages
to define additional parameters carried in the Event header
field. This event package, 'file', does not define
additional parameters.
</t>
</section>
<section title="SUBSCRIBE Bodies">
<t>
According to <xref target="RFC3265">RFC 3265 </xref>, a
SUBSCRIBE request can contain a body. The purpose of the body
depends on its type. Subscriptions to the 'file' event
package MAY contain a filter body according to the format
specified in <xref target="RFC4661" />. Filters are used to
reduce the number of results during searches.
</t>
</section>
<section title="Subscription duration">
<t>
From the functional point of view, there are two kinds of
subscriptions to the 'file' even package. In one, the user may
want to either perform a single search operation on the
existing files. In the other, the user may want to monitor the
changes in the state information of files. These
functionalities can be controlled by the duration of the
subscription.
</t>
<t>
A search on existing files can be implemented with a
single fetch operation (where the Expires header field is set
to zero) or by a subscription of a short duration (typically
on the order of a few minutes). The other functionality, where
a user wants to monitor the changes of a state, is typically
implemented as a lengthy subscription, on the order of hours,
as the user needs to be notified whenever a change in the
file has occurred.
</t>
<t>
Due to the lack of congruence in the two types of
subscriptions, it is hard to select a default expiration
value. We have decided to select a mean default value that
accommodate both types of subscriptions: 1800 seconds. As per
<xref target="RFC3265">RFC 3265 </xref>, the subscriber MAY
specify an alternate expiration in the Expires header
field. It is RECOMMENDED that UACs always include an explicit
Expires header field with the desired subscription value.
</t>
</section>
<section title="NOTIFY Bodies">
<t>
As described in <xref target="RFC3265">RFC 3265 </xref>, the
NOTIFY message can contain a body describing the state of the
subscribed resources. This body is either in a format listed
in the Accept header field of the SUBSCRIBE request, or in a
package-specific default format, if the Accept header field
was omitted from the SUBSCRIBE request.
</t>
<t>
In this event package, the body of the notification contains a
'file-metadata' document, specified in the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format
for describing files </xref>. A 'file-metadata'
document can be expressed as a full or partial document. An
ESC can receive 'file-metadata' documents from different EPAs
or other sources. The ESC applies a composition policy, and
composes a 'file-metadata' document that contains all the
available known files to the EPA. If the ESC is not able to
resolve a conflict, due to contradictory information provided
by two different EPAs, the ESC provides a comprehensive
information for that file, so that the subscriber can resolve
the conflict.
</t>
<t>
All subscribers and notifiers of 'file' event package MUST
support the "application/file+xml" data format described in
<xref target="I-D.garcia-app-area-file-data-format">XML Data
Format for describing files </xref>. The SUBSCRIBE request
MAY contain an Accept header field. If no such header field
is present, it has a default value of "application/file+xml"
(assuming that the Event header field contains a value of
'file'). If the Accept header field is present, it MUST
include "application/file+xml", and MAY include any other
types capable of representing 'file-metadata' documents.
</t>
<t>
When composing a 'file-metadata' document, the ESC MAY include
several <instance> elements per <file>
element. This would be the case when the ESC has acquired
information concerning the same file, for example, through
publications from different EPAs.
</t>
</section>
<section title="Notifier processing of SUBSCRIBE requests" anchor="notifier-sub">
<t>
The contents of a 'file-metadata' document can contain
sensitive information that can reveal some privacy
information. For example, it can contain a list of valuable
files and the address (SIP URI) of the SIP User Agent where
those are stored. While this information itself is not very
useful, it can be used by malicious agents, e.g., to mount an
attack to avoid other users to retrieve such a
file. Therefore, 'file-metadata' documents MUST only be sent
to authorized subscribers. In order to determine if a
subscription originates in an authorized user, the user MUST
be authenticated as described in <xref
target="notifier-sub-authentication" /> and then he MUST be
authorized to be a subscriber as described in <xref
target="notifier-sub-authorization" />.
</t>
<section title="Authentication" anchor="notifier-sub-authentication">
<t>
Notifiers SHOULD authenticate all subscription requests.
This authentication can be done using any of the mechanisms
defined in <xref target="RFC3261"> RFC 3261 </xref> and
other authentication extensions.
</t>
</section>
<section title="Authorization" anchor="notifier-sub-authorization">
<t>
Once authenticated, the notifier makes an authorization
decision. A notifier MUST NOT accept a subscription unless
authorization has been provided by the user. The means by
which authorization are provided are outside the scope of
this document. Authorization may have been provided ahead of
time through access lists, perhaps specified in a web page,
or provided with the <xref
target="RFC4745">Common Policy Framework</xref>.
</t>
</section>
</section>
<section title="Notifier Generation of NOTIFY Requests" anchor="notifier">
<t>
<xref target="RFC3265">RFC 3265 </xref> details the formatting
and structure of NOTIFY messages. However, packages are
mandated to provide detailed information on when to send a
NOTIFY request, how to compute the state of the resource, how to
generate neutral or fake state information, and whether state
information is complete or partial. This section describes
those details for the 'file' event package.
</t>
<t>
A notifier MAY send a NOTIFY at any time. The NOTIFY request
MAY contain a body containing a 'file-metadata' document or
any other type indicated by the subscriber in the Accept
header field of the SUBSCRIBE request. The times at which the
NOTIFY is sent to a particular subscriber, and the contents of
the body within that notification, are subject to any rules
specified by the authorization policy that governs the
subscription, but typically will contain an indication of
those known files for which a change has occurred.
</t>
<t>
Since 'file-metadata' documents can contain full or partial
state, the first 'file-metadata' document that a notifier
sends to subscriber MUST contain be a full 'file-metadata'
document. Subsequent documents sent to the same subscriber MAY
contain full 'file-metadata' documents or partial
'file-metadata' documents (the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format
for describing files </xref> provides further discussion about
full and partial 'file-metadata' documents).
</t>
<t>
In the case of a pending subscription, when final
authorization is determined, a NOTIFY request can be sent. If
the result of the authorization decision was success, a NOTIFY
SHOULD be sent and SHOULD contain a full 'file-metadata' document
with the current state of the files known by the notifier
at that moment. If the subscription is rejected, a NOTIFY MAY
be sent. As described in <xref target="RFC3265">RFC 3265
</xref>, the Subscription-State header field indicates the
state of the subscription.
</t>
<t>
Frequently, the notifier will have a incomplete view of the
available files described in a 'file-metadata' document. For
the duration of the subscription, the notifier can be running
searches for the availability of the searched files. When new
state information is made available to the notifier, the
notifier SHOULD provide this information to the subscribers,
typically as notifications that contain a partial
'file-metadata' document.
</t>
<t>
The body of the NOTIFY MUST be sent using one of the types
listed in the Accept header field in the most recent SUBSCRIBE
request, or using the type "application/file+xml" if no
Accept header field was present.
</t>
<t>
Notifiers will typically act as Event State Compositors (ESC)
and thus, will learn the 'file' event state via PUBLISH
requests sent from the user's Event Publication Agent (EPA)
when the user makes one or more files available or via
subscriptions passed further to other ESCs.
</t>
<t>
For reasons of privacy, it will frequently be necessary to
encrypt the contents of the notifications. This can be
accomplished using <xref target="RFC3851">S/MIME </xref>. The
encryption can be performed using the key of the subscriber as
identified in the From field of the SUBSCRIBE request.
Similarly, integrity of the notifications is important to
subscribers. As such, the contents of the notifications MAY
provide authentication and message integrity using <xref
target="RFC3851">S/MIME </xref>. This will require the
notifier to sign the content of the notification with the
notifier's private key.
</t>
</section>
<section title="Subscriber Processing of NOTIFY Requests">
<t>
<xref target="RFC3265">RFC 3265 </xref> leaves it to event
packages to describe the process followed by the subscriber
upon receipt of a NOTIFY request, including any logic required
to form a coherent resource state.
</t>
<t>
In this specification, each NOTIFY request contains either no
'file-metadata' document, a full 'file-metadata' document
representing files which are available at one or more SIP User
Agents, or a partial 'file-metadata' document that represent
changes with respect a previously notified 'file-metadata'
document. Within a dialog, when a 'file-metadata' document is
received in a NOTIFY request with a higher CSeq header field
value than a previously received NOTIFY, and when the
'version' attribute value of the <patch> element is
increased by one it contains a
partial 'file-metadata' document that updates a previously
received 'file-metadata' document (see the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format
for describing files </xref> for more details).
</t>
</section>
<section title="Handling of Forked Requests">
<t>
<xref target="RFC3265">RFC 3265 </xref> requires each package
to describe handling of forked SUBSCRIBE requests.
</t>
<t>
This specification allows several dialogs to be constructed as
a result of emitting an initial SUBSCRIBE request, i.e., in
cases where the SUBSCRIBE request forked to several
notifiers. In this case, the subscriber will keep several
simultaneous dialogs. The subscriber SHOULD merge the several
'file-metadata' documents received in NOTIFY requests. It might be
possible that new <file> elements are received in
forked 'file-metadata' documents, or it might be possible that
existing <file> elements are updated with new
information (e.g., a new <gruu> element). In both cases
the merge should provide a logical OR operation of all the
available information such as new entries and added
information to existing entries.
</t>
</section>
<section title="Rate of Notifications">
<t>
<xref target="RFC3265">RFC 3265 </xref> requires each package
to specify the maximum rate at which notifications can be
sent.
</t>
<t>
Notifiers of 'file-metadata' documents SHOULD NOT generate
notifications for a single user at a higher rate than once
every second.
</t>
</section>
<section title="State Agents">
<t>
<xref target="RFC3265">RFC 3265 </xref> requires each package
to consider the role of state agents in the package, and if
they are used, to specify how authentication and authorization
are done.
</t>
<t>
This specification allows state agents to be located in the
network. A given file might be available at different SIP
User Agents in the network. ESCs can act as state agents by
compiling and aggregating state towards, e.g., subscribers,
other networks or communities. State agents MUST use any of
the mechanism specified in <xref target="RFC3261">RFC 3261
</xref> or any other SIP extension to authenticate and
authorize users prior to accepting publications.
</t>
<t>
If the state agent acts as an aggregator, the state agent
SHOULD aggregate all the information related to the same
available file. In this case, it is expected that, because
the same file is available in different endpoints, there
might be different URIs for a given available file.
</t>
</section>
<section title="Examples">
<t>
Examples of 'file-metadata' documents are provided in the
<xref target="I-D.garcia-app-area-file-data-format">XML Data
Format for describing files</xref>.
</t>
</section>
<section title="Use of URIs to Retrieve State">
<t>
<xref target="RFC3265">RFC 3265 </xref> allows packages to use
URIs to retrieve large state documents.
</t>
<t>
A 'file-metadata' document can be of any arbitrary length, and can
also become too large to be reasonably sent in a SIP
request. To avoid the burden of transmitting large documents
through SIP proxies and to avoid potential congestion
scenarios, it is possible that the notifier instead includes a
URI that points to the contents, rather than the actual
contents. For example, the notifier can include an <xref
target="RFC2616">HTTP </xref> URI that points to the notifier
itself. Since HTTP requests are transferred via a congestion
controlled protocol (such as <xref target="RFC0793">TCP
</xref>), the inclusion of a URI to retrieve state mitigates
the problem of large 'file-metadata' documents.
</t>
<!-- Note: the Content Indirection mechanism should be elaborated -->
</section>
<section title="PUBLISH bodies">
<t>
<xref target="RFC3903">RFC 3903 </xref> requires event
packages to define the content types expected in PUBLISH
requests.
</t>
<t>
In this event package, the body of a PUBLISH request contains
a 'file-metadata' document (see the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format
for describing files </xref>). This 'file-metadata' document
describes the availability of one or more files (typically,
but not necessarily, stored at the EPA). EPAs SHOULD only
publish the description of locally available files, i.e., the
URI of the file SHOULD resolve to the EPA itself.
<!-- If an EPA publishes a file description pointing to a URI
which is not resolved to itself, the mechanism could be
easily used to enable a denial of service attack or to
hijack publications of legitimate resources -->
</t>
<t>
All EPAs and ESCs MUST support the "application/file+xml" data
format described in the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format
for describing files </xref>. and MAY support other formats.
</t>
<t>
When the EPA is composing a 'file-metadata' document, the EPA
SHOULD include only one <instance> element per
<file> element, and the data SHOULD include only the
local description of the file.
</t>
<t>
<list style='hanging'>
<t>
Allowing EPAs to provide a description of non-locally
stored files could be maliciously used for creating,
e.g., denial of service attacks.
</t>
</list>
</t>
<t>
EPAs MUST NOT publish non-local URIs in the <uri> element,
although they MAY publish several URIs for a single file,
e.g., if the file is available through several protocols and
URIs.
</t>
<t>
EPAs MUST NOT include <user-aor> containing
addresses-of-record that point to other users than the one
whose file EPA is publishing. ESCs MUST verify that a
<user-aor> element received in a PUBLISH request belongs
to the same user who published the request; this requires the
ESC to first authenticate the publisher.
</t>
</section>
<section title="PUBLISH Response Bodies">
<t>
This specification does not associate semantics to a body in a
PUBLISH response.
</t>
</section>
<section title="Multiple Sources for Event State">
<t>
<xref target="RFC3903">RFC 3903 </xref> requires event
packages to specify whether multiple sources can contribute to
the event state view at the ESC.
</t>
<t>
This event package allows different EPAs to publish the
availability of the same file. For the same file, each
EPA publishes data that is invariant with the instance of
the file, and data that is specific with each
instance. The ESC SHOULD merge the data pertaining to the same
file according to a composition policy. This policy can,
e.g., list all the difference instances where each file is
available.
</t>
</section>
<section title="Event State Segmentation">
<t>
<xref target="RFC3903">RFC 3903 </xref> defines segments
within a state document. Each segment is defined as one of
potentially many identifiable sections in the published event
state.
</t>
<t>
In this 'file' event package, each <file> element composes
a segment.
</t>
</section>
<section title="Rate of Publication">
<t>
<xref target="RFC3903">RFC 3903 </xref> allows event packages
to define their own rate of publication.
</t>
<t>
There are no rate limiting recommendations for 'file'
publication. It is expected that new files are added at
the time of creation (e.g., a new image is taken with a camera
phone), and that they are not changed often. Thus, a typical
rate of publication does not exist and there is no foreseen
need to limit the rate of publications.
</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>
TBD
</t>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank Nicklas Beijar and Juuso
Lehtinen held fruitful discussions with the authors that lead to
the design of this event package. Pekka Kuure and Arto
Leppisaari provided helpful comments during the initial review.
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="Registration of the 'file' Event Package">
<t>
This specification registers an event package, based on the
registration procedures defined in <xref target="RFC3265">RFC
3265 </xref>. The following is the information required for
such a registration:
</t>
<t>
<list style="hanging">
<t>
Package Name: file
</t>
</list>
</t>
<t>
<list style="hanging">
<t>
Package or Template-Package: This is a package.
</t>
</list>
</t>
<t>
<list style="hanging">
<t>
Published Document: RFC XXX [Replace by the RFC number of
this specification].
</t>
</list>
</t>
<t>
<list style="hanging">
<t>
Person to Contact: Miguel A. Garcia-Martin,
miguel.garcia@nsn.com
</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to
Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott
Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723'
target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486'
target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661'
target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3265"?>
<?rfc include="reference.RFC.3851"?>
<?rfc include="reference.RFC.3903"?>
<?rfc include="reference.I-D.garcia-app-area-file-data-format"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-mmusic-file-transfer-mech"?>
<?rfc include="reference.RFC.0793"?>
<?rfc include="reference.RFC.2616"?>
<?rfc include="reference.RFC.4661"?>
<?rfc include="reference.RFC.4745"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref CDATA XML
-->
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:26 |