One document matched: draft-garcia-sipping-file-sharing-framework-01.xml
<?xml version="1.0"?>
<!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='SIP File Sharing'>Sharing Files with the
Session Initiation Protocol (SIP)</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>
<author initials="N." surname="Beijar" fullname="Nicklas Beijar">
<organization>Helsinki University of Technology</organization>
<address>
<postal>
<street>P.O.Box 3000</street>
<city>TKK</city>
<region>FIN</region>
<code>02015</code>
<country>Finland</country>
</postal>
<phone>+358 9 451 5303</phone>
<email>nbeijar@netlab.tkk.fi</email>
<uri>http://www.netlab.tkk.fi/</uri>
</address>
</author>
<author initials="J." surname="Lehtinen" fullname="Juuso Lehtinen">
<organization>Tellabs</organization>
<address>
<postal>
<street>Sinimaentie 6</street>
<city>Espoo</city>
<region>FI</region>
<code>02630</code>
<country>Finland</country>
</postal>
<phone>+358 40 820 5223</phone>
<email>juuso.lehtinen@tellabs.com </email>
</address>
</author>
<date day="16" month="November" year="2007" />
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>file</keyword>
<keyword>sharing</keyword>
<keyword>SIP</keyword>
<keyword>peer-to-peer</keyword>
<abstract>
<t>
This memo proposes a SIP framework used for advertising and
searching for shared files within a given community. The memo
defines the signaling that users to announce the availability
of files stored in their User Agents (UA). It also
provides the signaling for users to perform searches of
available files and monitor changes in those
files. Additionally, this memo describes the signaling used to
access a file. These methods can be used in (but are not
limited to) SIP peer-to-peer systems based on centralized,
semi-centralized or fully distributed architectures.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The <xref target="RFC3261">Session Initiation Protocol (SIP)</xref>
is a text-based protocol for initiating and managing communication
sessions. The protocol is extended by the <xref
target="RFC3265">SIP-events framework</xref> to provide a mechanism
whereby a user can subscribe to state changes of resources and get
notifications when the state of the resource changes. SIP also
provides a <xref target="RFC3903">publication mechanism</xref> that
allows a user to supply resource metadata related to the state and
changes in the state of such resource. A <xref
target="I-D.garcia-sipping-file-event-package">'file' event
package</xref> is used to allow SIP User Agents to publish,
subscribe, and get notifications of the availability of files, such
as images, video files, audio files, etc. The 'file' event package
reuses the <xref target="I-D.garcia-app-area-file-data-format">XML
Data Format for descibing files </xref>. All these building blocks
can be easily combined to provide a mechanism whereby users can
supply the availability of files stored in their user agents. The
mechanism can also provide a directory search within a publishing
community, so that members of the community can search for the
availability of files that have been made available by other
members of the same community, and then further download selected
files.
</t>
<t>
Think for example of a user, Alice, who wants to make a set of
image files available to members of her family. She sets up a SIP
peer-to-peer network with her family, and publishes the file
metadata describing her available files. The file metadata is
stored in the peer nodes, for example, in each Alice's family user
agents. Then, Bob, a member of the same SIP peer-to-peer network,
wants to acquire those pictures, tagged with a keyword
'vacation'. He defines the search criteria; his SIP UA creates an
appropriate filter and sets up a short subscription by sending it
to the SIP peer-to-peer network. Then he receives notifications
from the different peer nodes, containing a metadata describing the
searched files.
</t>
<t>
In another scenario, a centralized server can be used to aggregate
all the state file metadata. This might be useful in cases
where several instances of the same file are available at
different SIP user agents. The server will act as a state agent
(defined in <xref target="RFC3265">RFC 3265</xref>) and Event State
Compositor (ESC) (defined in <xref target="RFC3903">RFC
3903</xref>). The aggregation the server performs relieves the
endpoints from doing the aggregation itself, so this is an
interesting scenario in deployments that involve endpoints with
limited processing capability and network bandwidth.
</t>
<t>
A hybrid scenario is also possible, where, for example, User Agents
act as secondary nodes (ordinary peers) in a SIP peer-to-peer
network. ESCs are primary nodes (super peers). In this scenario,
publication of file metadata and search operations takes place
between the secondary and the primary nodes. The primary nodes keep
the state consistent among themselves proactively according to a
well-defined Distributed Hash Table (DHT) algorithm (e.g. Chord),
or alternatively, distribute the search request among themselves
reactively when a file is needed.
</t>
<t>
This memo describes a framework where SIP is used for advertising
and searching for shared files. The
framework defines the signaling used for users to signal the
availability of files stored in their User Agents (UA). It also
describes the signaling used for users to perform searches of
available files and monitor changes in existing
files. Additionally, signaling used to download a file from a
remote UA is provided. These methods can be used in (but are not
limited to) SIP peer-to-peer systems based on centralized,
semi-centralized or fully distributed architectures. While other
protocols and mechanisms can be used to achieve similar purposes,
it is a beneficial to provide the means to use SIP in order to
minimize the protocol implementation support, especially in
endpoints with limited resources.
</t>
</section>
<section title="Definitions and Document Conventions">
<t>
In addition to the definitions of <xref target="RFC3265">RFC
3265</xref>, and <xref target="RFC3903">RFC 3903</xref>, this
document introduces the following new terms:
</t>
<t><list style='hanging'>
<t hangText="Community:">
A collection of loosely coupled SIP user agents that agree to
share files among members of the community. A community can
be composed of, e.g., an enterprise, a group of friends, family
members, or members of a club. The community concept implies that
there are only duly authenticated and authorized users who can access
files.
</t>
<t hangText="File metadata:">
A set of properties describing a file. The file
metadata can include the hash of the file, its name,
creation date, Uniform Resource Name (URN), Uniform Resource
Identifier (URI), and other relevant information.
</t>
<t hangText="File descriptor:">
A subset of the file metadata that uniquely identifies the file.
</t>
<t hangText="File directory:">
A device storing the file descriptors of a set of files;
also called ESC in this document.
</t>
<t hangText="Search operation:">
Signalling issued by a user to get information of the available
files and its associated metadata. Typically search
operations are delimited with search filters.
</t>
<t hangText="Search filter:">
A set of properties used in search operations to set the limits
of the search, based on user's input. A search filter can consist
of, e.g., a file name, file type, a files description,
etc.
</t>
<t hangText="File transfer operation:">
An operation whereby a UA downloads a file from a remote UA.
</t>
</list></t>
<t>
In this document, 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="Use Cases">
<t>
This section describes a number of use cases that are addressed
later in this document. The use cases are just examples, and do not
intend to limit the applicability of the file sharing
framework.
</t>
<section title="File Publication">
<t>
Alice is on holiday in Monaco. While visiting the Casino, she sees
a famous painting which she takes a picture of with her camera
phone. After taking the photo, she tags it with the following tags:
Alice, Holiday, Monaco, Painting, Casino. These tags are there to
help her and her friends to locate the picture later.
</t>
<t>
Alice knows that her friends are also interested in art, so she
wants to make this picture available for anyone to download. Alice
selects the picture of the painting, along with some other pictures
she took later that day, in the picture browser application and
selects the publish option to make the picture available for others
to see. Once the selection of shared files is done, the SIP UA
publishes the availability of those pictures towards an Event
State Compositor (ESC). The actual files are not transmitted until
someone requests them.
</t>
<t>
File publication is further discussed in <xref target="publication"/>.
</t>
</section>
<section title="File Search">
<t>
While talking with Charlie on the phone, Bob learns that Alice is
currently on vacation in Monaco. Bob knows that Alice likes to take
photos and share them with her friends, so he opens up his search
application and types in a few keywords: 'Alice' and 'Monaco'. Once
Bob hits the search button, his SIP UA sends the search message to
the ESC. After a while, the ESC sends the search results back to
Bob's SIP UA in a series of notifications. Now Bob can see the
names of all pictures Alice has taken when she was in Monaco. Bob's
application may also download and display thumbnails of the
pictures. Bob also finds a couple of pictures taken by Alice's
friend, Eve, which have been tagged with the tags: 'Alice' and
'Monaco'.
</t>
<t>
Dave is a student of art. On the bus he meets his friend Eve. While
chatting, Eve tells about the painting she has seen on her recent
visit in Monaco. Dave wonders if there are some pictures of it, and
enters the keywords 'Monaco' and 'Painting' into the application on
his mobile phone. Dave hits the search button, and his SIP UA sends
the search message to the ESC. After a while, the ESC sends the
search results back to his SIP UA in a series of notifications. The
application displays a list of files matching the keywords,
including the pictures Alice and other visitors have taken. To his
surprise, Dave also finds a video stream presenting the art museums
of Monaco.
</t>
<t>
Search operations are further discussed in <xref
target="search-operation"/>.
</t>
</section>
<section title="File Directory Through Presence Information">
<t>
Charlie is a good friend of Alice. Therefore he is interested to
know about new pictures that Alice publishes. In this case he can
just subscribe to Alice's presence information. Attached with
conventional the presence information, he receives the information
about the files Alice is hosting in her UAs.
</t>
<t>
Instead of periodical searching for files tagged with Alice's name,
Charlie can just subscribe to Alice's presence information, and get
notification every time Alice adds new pictures to her shared
files.
</t>
<t>
The same file browsing functionality can be used also in multi-user
chat between Alice, Charlie, Eve, and Bob. In the chat application,
Bob sees names of every participant in the user list displayed on
his screen. When clicking anyone's name, he gets list of files that
the selected participant is hosting attached with the conventional
presence information of this person.
</t>
<t>
This document does not specify implementation of the file browsing
via presence information. A solution is described in the
Internet-Draft <xref
target="I-D.garcia-sipping-file-desc-pidf">'File
Descriptions Extension to the PIDF'</xref>.
</t>
<t>
File directory through presence information is further
discussed in <xref target="directory-through-presence"/>.
</t>
</section>
<section title="File Download">
<t>
Once a Bob has found an interesting file called 'Alice and Eve at
the Casino', e.g., by using the search functionality or by browsing
Alice's presence information for files, he wants to display that
picture on his device. To initiate the download, Bob selects the
picture and hits the download button. Bob's SIP UA sends a download
request to Alice's SIP UA. Alice's terminal will automatically
approve the request and their UAs will establish a file transfer
session. After the file transfer, Bob is presented with a dialog of
file transfer completion, and asked if he wants to open the file
immediately in the picture viewer.
</t>
<t>
<xref target="downloading"/> provides further discussion on
downloading files.
</t>
</section>
</section>
<section title="Publication of File Metadata">
<t>
Publication of File Metadata is based on the PUBLISH method
specified in <xref target="RFC3903">RFC 3903</xref>. We proposed
two variants of publication, depending on whether the publication
supports search operations or directory operations. To support the
former, publication is done with the <xref
target="I-D.garcia-sipping-file-event-package">'file' event
package</xref> and the <xref
target="I-D.garcia-app-area-file-data-format">'file-metadata' XML
format </xref>. To support the later, the <xref
target="RFC3863">Presence Information Data Format (PIDF) </xref>
is extended to provide a description of available files together
with the presence information of the presentity.
</t>
<!-- The difference between search operations and directory operations
is not clear. If we have time, we need to add a section before that
describes clearly the differences between both and provide some
definitions -->
<section title="File Metadata Publication in Support of Search
Operations">
<section title="Initial File Metadata Publication" anchor="publication">
<t>
Initial file metadata publication is perfomed to publish
metadata about the availability of one or more files to the
ESC. <xref target="publication-signaling"></xref> presents the
signaling flow required for an Event Publishing Agent (EPA) to
publish the availability of one or more files towards the
Event State Compositor (ESC).
</t>
<figure title="Signaling flow for publication of file metadata"
anchor="publication-signaling" align="center"><artwork>
EPA ESC
| |
| SIP/2.0 PUBLISH |
| Event: file |
| (file-metadata document) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: x |
| <------------------------------------ |
| |
</artwork></figure>
<t>
The EPA performs the initial file metadata publication by sending
a <xref target="RFC3903">PUBLISH</xref> request to the ESC. The
PUBLISH request contains a full 'file-metadata' document that
contains metadata about one or more files available at the
EPA. The 'file-metadata' document is defined in the <xref
target="I-D.garcia-app-area-file-data-format">XML data format for
describing files</xref>. Each file is described using a set of
invariant file metadata and a set of file metadata specific to
each instance of the file, given in the <identity> and
<instance> child elements of the <file> element.
</t>
<t>
The invariant file metadata contains the following attributes: the
Uniform Resource Name (URN), the MIME type (e.g., image/jpeg), the
size and the SHA-1 hash of the file. For each identical copy of
the file, the instance-specific metadata contains any of: the SIP
URI of the file, the file name, a short description, a set of
keywords describing the file, the file creation date, the file
modification date, the file read date, a link to an icon, and
other file metadata that is associated to the file. Additionally
the instance-specific metadata contains the SIP AOR (e.g. URI) and
GRUU of the user's endpoint hosting the file.
</t>
<t>
The PUBLISH request is routed to the ESC. The ESC sends a 200 OK
response that, according to <xref target="RFC3903">RFC
3903</xref>, includes a SIP-ETag header field that contains the
entity-tag allocated to the resource. The EPA stores this
entity-tag for future references to the publication.
</t>
<t><list style='empty'>
<t>
Note that the actual file is not transmitted at any point to the
ESC: only the metadata associated with the file is transmitted.
</t>
</list></t>
</section>
<section title="Publication of Modified File Metadata" anchor="publication-modified">
<t>
Whenever a file is modified or new files are added or
deleted from the endpoint, the EPA refreshes the previous
publication by sending a new PUBLISH request, as shown in <xref
target="modified-publication-signaling"></xref>. This publication
carries a partial 'file-metadata' document that contains a number of
XML patch operations that add, remove, or replace XML elements
towards the last published 'file-metadata' document.
</t>
<t><list style='empty'>
<t>
A file modification occurs, e.g., when an image file is
edited to suppress red eyes, an audio file is edited to suppress
silence or apply some noise filter, or when some audio/music
stream provided by the UE changes its bitrate. Any kind of
modification to the file owned by the UE implies a change in
the metadata.</t>
</list></t>
<t>
<xref target="RFC3903">RFC 3903</xref> contains provisions to
allow the ESC to distinguish an initial publication from a
refreshment-based one with the aid of the entity tags and the
SIP-ETag and SIP-If-Match header fields. The SIP-Etags in
conjunction with the 'version' attribute of the root element of
the 'file' document provide the means to synchronize
versions.
</t>
<!-- Miguel: I am not sure if the above paragraph is completely
true. In some draft I've seen some discussion, where I think it was
written that the 'version' attribute wasn't used, and only the etags
were used. I need to check this. It can be in the XCAP diff, partial
presence/publication/notification drafts... -->
<figure title="Signaling flow for publication of modified file
metadata" anchor="modified-publication-signaling" align="center"><artwork>
EPA ESC
| |
| SIP/2.0 PUBLISH |
| SIP-If-Match: x |
| Event: file |
| (file-metadata document) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: y |
| <------------------------------------ |
| |
</artwork></figure>
<t>
If a resouce becomes unavailable at the EPA, e.g., as a result of
a file deletion, the file metadata publication contains a partial
'file-metadata' document that describes the file to be removed.
</t>
</section>
<section title="Actions Performed by the ESC">
<t>
When the ESC receives initial or updated publications, the ESC
typically locally stores the published metadata, but in some
cases, depending on the usage scenario, storage of metadata will
take place in other nodes, for example, in other primary nodes
which are members of a DHT.
</t>
<t>
The ESC may act as a primary node in an overlay SIP P2P
network. Thus, upon reception of a publication from one of its
secondary nodes, the primary node may need to publish or update the
metadata in the overlay P2PSIP network. This step heavily depends
on the chosen peer-to-peer algorithm. For example, if the P2PSIP
distribution algorithm is based on flooding, the primary node may
not need to contact any other primary node, but just wait for
search queries from them. However, if the overlay is based on a
Distributed Hash Table (DHT) based algorithm, then the primary node
may need to update file metadata and store it in the
appropriate node. The actual mechanism to update file metadata
is dependent on the specific algorithm and out of scope of this
memo.
</t>
</section>
</section>
<section title="File Metadata Publication in Support of Directory
Operations">
<t>
Publication of file metadata in support of directory operations is
done by extending the presence information data format (PIDF). PIDF
is commonly used in publications and notifications of presence
information. The publisher composes a <xref target="RFC3863">PIDF
</xref> document according to the <xref target="RFC4479">Presence
Data Model </xref>. The <device> element of the data model
contains the file metadata. This is further described in a the
Internet-Draft <xref
target="I-D.garcia-sipping-file-desc-pidf">'File Descriptions
Extension to the PIDF'</xref>.
</t>
<t>
Publication of presence information contains a number of mechanisms
that complement publication operations, for example, partial
publication, presence authorization rules, etc., are always at the
presentity's disposal.
</t>
<figure title="Signaling flow for publication of presence
information that includes file metadata"
anchor="publication-presence" align="center"><artwork>
EPA ESC
| |
| SIP/2.0 PUBLISH |
| Event: presence |
| (PIDF + data model + |
| file-metadata in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: x |
| <------------------------------------ |
| |
</artwork></figure>
<t>
Publication of modified file metadata in the PIDF is done
similarly to the publication of modified file metadata (see <xref
target="publication-modified"/>), but the event package is set to
presence.
</t>
</section>
</section>
<section title="Search Operation" anchor="search-operation">
<t>
The search of shared files is implemented with the SIP event
framework defined in <xref target="RFC3265">RFC 3265</xref> in
conjunction with the <xref
target="I-D.garcia-sipping-file-event-package">'file'
event package</xref> and a <xref
target="RFC4661">filter document</xref>.
</t>
<t>
The signaling flow for a search operation is shown in <xref
target="search-signaling"></xref>.
</t>
<figure title="Signaling flow of a search operation"
anchor='search-signaling' align="center"><artwork>
Subscriber Notifier
| |
| SIP/2.0 SUBSCRIBE |
| Event: file |
| (search filter in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| <------------------------------------ |
| |
| SIP/2.0 NOTIFY |
| Event: file |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
| SIP/2.0 NOTIFY |
| Event: file |
| (file-metadata document in body) |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
| SIP/2.0 NOTIFY |
| Event: file |
| Subscription-State: terminated |
| (file-metadata document in body) |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
</artwork></figure>
<section title="Sending a Search Request">
<t>
To search for a particular file, the subscriber first builds a filter
containing the data of the searched file. The filter can
contain, for example, keywords, file names, types of files,
etc. The filter conforms to the <xref
target="RFC4661">XML format for
filters</xref>. Then the subscriber attaches the filter to a SUBSCRIBE
request for the 'file' event package. The subscription duration
will be short, typically on the order of a few minutes. This
subscription time provides enough time for a primary node in a
SIP peer-to-peer network to propagate the search within the
overlay network and get responses before the subscription
expires. Eventually, the SUBSCRIBE request is sent to a notifier
(either a peer or an ESC) that will provide one or more NOTIFY
requests including a 'file-metadata' document according to the
filtered content.
</t>
</section>
<section title="Reporting Search Results">
<t>
After receiving the SUBSCRIBE request and acknowledging it with a
200 (OK) response, the notifier sends a NOTIFY request to the
subscriber. This request may contain a first collection of file
metadata about the searched file, if such information is already
available in the ESC, in a full 'file-metadata'
document. Information may be available immediately in case there
is matching metadata stored in the ESC, due to push operations
according to the peer-to-peer algorithm, or due to cached
information from previous searches. In many cases, however, this
NOTIFY request does not contain a 'file-metadata' document about
the searched file, and it is sent just because the protocol
(<xref target="RFC3265">RFC 3265</xref>) requires an immediate
NOTIFY after each successful SUBSCRIBE request. The NOTIFY
request is acknowledged with a 200 (OK) response.
</t>
<t>
The ESC may, depending on algorithm, invoke a search for
additional files, whose metadata is stored in other ESCs (see
section 4.3). Due to this propagated search, additional matching
file descriptors may become known. New matching file
descriptors may also become known as a result of PUBLISH requests
received by the ESC within the duration of the subscription.
</t>
<t>
To report matching files, the ESC sends NOTIFY requests to the
subscriber. The body of the initial NOTIFY contains follows the
procedures of the <xref
target="I-D.garcia-sipping-file-event-package">'file' event
package </xref> and contains a full 'file-metadata' document that
is formatted according to the <xref
target="I-D.garcia-app-area-file-data-format">XML Data Format for
describing files</xref>. The 'file-metadata' document contains
metadata about several files that matched the search criteria,
including the file name, size, type, icon, hash, SIP URI and UE
(GRUU) of the users (and UAs) where the file is available,
etc. In some cases, the file metadata that describes a given file
will provide more than one location of the file. This will
typically be the case when a popular file is available in several
endpoints. Then the 'file-metadata' document supplied with the
NOTIFY request contains more than one <instance> child
element in a given <file>element. It may also be necessary
to divide a NOTIFY request into several smaller due to the user's
preferences (rate of notifications, bandwidth consumption, and
event throttling). NOTIFY requests are acknowledged with 200 (OK)
responses.
</t>
<t>
The initial NOTIFY request contains a full 'file-metadata'
document. Once the notifier acquires more metadata, it sends
partial 'file-metadata' documents with additions, replacements,
or removals. Upon reception of a new partial 'file-metadata'
document, the subscriber composes a full 'file-metadata'
document, based on the existing previous version plus the partial
notification. Then, the subscriber UA has the new full
'file-metadata' document at his disposal, so it can, e.g.,
display the metadata sequentially to the user, as soon as new
results are received.
</t>
</section>
<section title="Propagating Searches">
<t>
In many cases, such as in P2P systems, the metadata is
distributed in several ESCs. We consider two special cases:
</t>
<t><list style="numbers">
<t>
In a flooding based architecture, several or all ESCs need to
be queried in order to find the matching file. A given ESC
is only aware of file that have been published into its
local database.
</t>
<t>
In a DHT based architecture, such as Chord, a specific ESC is
responsible for a specific set of metadata.
</t>
</list></t>
<t>
In both cases, the ESC/ESCs containing the required file metadata may
be another ESC than the one receiving the SUBSCRIBE request.
</t>
<section title="Searching Based on Flooding">
<t>
In a flooding based search, the SUBSCRIBE request is first
processed by the local ESC itself, and then distributed to all
ESCs in the system. The distribution is, however, limited by the
value of the Max-Forwards header field. An ESC receiving the
SUBSCRIBE request consults its local database to find matching
file descriptors and it replies with a NOTIFY request that may contain a
'file-metadata' document if matching file descriptors are found
locally. The ESC also acts as an <xref target="RFC4662">URI-list
server</xref> where the URI-list is locally stored. It then
forwards a SUBSCRIBE request with the same filter document to
each of the ESCs stored in its neighbor table, providing that the
Max-Forwards header field is still positive and provided that the ESC
has not yet processed the same request. The generation and
maintenance of the neighbor table is out of scope of this memo.
</t>
<t>
The ESC will receive NOTIFY requests from other neighbor nodes,
each of the requests containing a different 'file-metadata'
document. The ESC will aggregates and composes a single
'file-metadata' document, and sends partial notifications to the
subscriber, according to the rate of notifications.
</t>
<t>
The subscriber is getting periodic partial notifications, each
one adding new files or new instances of existing
files to the list of file descriptors.
</t>
</section>
<section title="Searching Based on Distributed Hash Tables (DHT)">
<t>
In a DHT based system, a single node (a notifier) is responsible
for the metadata related to a given search key (the
file). When searching a file, the hash of the file is the key
in the DHT. An ESC receiving a SUBSCRIBE request consults its
routing table (finger table in Chord) to locate the notifier
whose key is the closest one to the search key, and forwards the
SUBSCRIBE request to that ESC. Eventually the SUBSCRIBE request
reaches the node responsible for the given search key. The
definition of 'closest' is depending on the actual DHT used.
</t>
</section>
</section>
<section title="Terminating a Search Request">
<t>
When the last results are made available, or when the search
operation expires, the server sends a last NOTIFY request to the
user, containing the latest available results in a
'file-metadata' document (if any), and setting the
Subscription-State header field to "terminated" to indicate the
end of the search operation, as per procedures of <xref
target="RFC3265">RFC 3265</xref>.
</t>
<t>
The user can also cancel the search operation by sending a
re-SUBSCRIBE request that contains a Expires header field set to
zero, according also to the procedures of <xref
target="RFC3265">RFC 3265</xref>.
</t>
</section>
<section title="Example of a Search Filter">
<t>
<xref target="search-signaling"></xref> provides the signaling
flow for a search operation. The SUBSCRIBE request contains a
filter body, formatted according to the <xref
target="RFC4661">filter data
format</xref>. <xref target="search-filter-example"></xref> shows
an example of the SUBSCRIBE request carrying a filter. The filter
selects a few XML elements of a file that contains the string
"vacation" in a <keyword> element.
</t>
<figure title="Example of a search filter"
anchor="search-filter-example" align="center"><artwork>
SUBSCRIBE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.example.net;branch=z9hG4bKnashds7
Max-Forwards: 70
From: <sip:alice@example.net>;tag=31415
To: <sip:bob@example.com>
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 61 SUBSCRIBE
Event: file
Expires: 180
Accept: application/file+xml;q=0.3
Contact: <sip:alice.example.com>
Content-Type: application/simple-filter+xml
Content-Length: [length]
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="rs" urn="urn:ietf:params:xml:ns:file"/>
</ns-bindings>
<filter id="ad982" uri="sip:bob@example.com">
<what>
<include type="xpath">
/rs:file-set/rs:file
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:identity/rs:urn
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:identity/rs:mime-type
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:identity/rs:size
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:identity/rs:sha-1
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:instance/rs:uri
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:instance/rs:user-uri
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:instance/rs:user-gruu
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:instance/rs:description
</include>
<include type="xpath">
/rs:file-set/rs:file/rs:instance[rs:keyword="vacation"]
</include>
</what>
</filter>
</filter-set>
</artwork></figure>
</section>
</section>
<section title="Directory Operations Through Presence Information" anchor="directory-through-presence">
<t>
Directory operations through presence information allows an
authorized watcher of presence information to be updated on the
list available files stored at a presentity's device. In <xref
target="directory-presence"/>, the watcher does a
regular subscription to the presentity's presence information,
either directly between the two endpoints, or with the support of a
Presence Agent (PA). Once the subscription is duly authorized, the
subscriber receives updated presence information in NOTIFY
requests. The request contains a PIDF document structured according
to the presence data model. The 'device' part of the data model
contains a list of available files that the presentity provides
at the subscriber's disposal.
</t>
<t>
All the presence mechanisms are available also in directory
operations. For example, partial notifications, presence
authorization rules, filters, etc., are applicable.
</t>
<figure title="Signaling flow of a directory operation through presence"
anchor='directory-presence' align="center"><artwork>
Subscriber PA
| |
| SIP/2.0 SUBSCRIBE |
| Event: presence |
| (search filter in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| <------------------------------------ |
| |
| SIP/2.0 NOTIFY |
| Event: presence |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
| SIP/2.0 NOTIFY |
| Event: presence |
| (PIDF + data model + |
| file descriptor in body) |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
</artwork></figure>
</section>
<section title="Downloading a file" anchor="downloading">
<t>
Once the search operation is complete, the user can select whether
to do any further operation on a given file, and if so, on which
instance to operate. A file can be downloaded, for example, by
setting up an MSRP session towards the user's SIP URI, and
providing a file description in the SDP offer. This mechanism is
described in <xref
target="I-D.ietf-mmusic-file-transfer-mech"></xref>. In this case,
the SIP INVITE request is addressed (Request-URI) to the URI
contained in a <user-gruu> (preferred option) or
<user-uri> elements of the chosen <identity> for that
<file>. The file requester creates an SDP description of
an MSRP session that contains the SDP file description extensions
to describe the file. If the hash of the file is available, it is
RECOMMENDED to include it, as it uniquely identifies the file.
</t>
<t>
In other cases, there can be a URN or URI that describes the
file in the <urn> or <uri> elements of that
<file>. The mechanism to retrieve or receive service from
the file is dependent on the type of URI scheme. For example, an
HTTP URI requires an HTTP GET request to retrieve the
file. Similarly FTP URIs require the establishment of an FTP
session.
</t>
</section>
<section title="Security Considerations">
<t>
TBD
</t>
</section>
<section title="IANA Considerations">
<t>
This document contains no actions to IANA.
</t>
</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.3863"?>
<?rfc include="reference.RFC.3903"?>
<?rfc include="reference.RFC.4479"?>
<reference anchor="I-D.garcia-sipping-file-event-package">
<front>
<title abbrev='File Event Package'>A Session
Initiation Protocol (SIP) Event Package and Data
Format for File Metadata Description</title>
<author initials="M." surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
</author>
<author initials="M." surname="Matuszewski" fullname="Marcin Matuszewski">
<organization>Nokia</organization>
</author>
<date year='2007' month='November' />
</front>
<seriesInfo name='Internet-Draft' value='draft-garcia-sipping-file-event-package-01' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-garcia-sipping-file-event-package-01.txt' />
</reference>
<reference anchor="I-D.garcia-sipping-file-desc-pidf">
<front>
<title abbrev='File Descriptions in PIDF'>File
Descriptions Extension to the Presence Information
Data Format (PIDF)</title>
<author initials="M." surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
</author>
<author initials="M." surname="Matuszewski" fullname="Marcin Matuszewski">
<organization>Nokia</organization>
</author>
<date year='2007' month='June' />
</front>
<seriesInfo name='Internet-Draft' value='draft-garcia-sipping-file-desc-pidf-00' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-garcia-sipping-file-desc-pidf-00.txt' />
</reference>
<?rfc include="reference.I-D.garcia-app-area-file-data-format"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4661"?>
<?rfc include="reference.RFC.4662"?>
<?rfc include="reference.I-D.ietf-mmusic-file-transfer-mech"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:25:52 |