One document matched: draft-garcia-sipping-file-sharing-framework-00.txt
SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Matuszewski
Expires: December 10, 2007 Nokia
N. Beijar
Helsinki University of Technology
J. Lehtinen
Tellabs
June 8, 2007
Sharing Files with the Session Initiation Protocol (SIP)
draft-garcia-sipping-file-sharing-framework-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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
Garcia-Martin, et al. Expires December 10, 2007 [Page 1]
Internet-Draft SIP File Sharing June 2007
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Document Conventions . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. File Publication . . . . . . . . . . . . . . . . . . . . . 5
3.2. File Search . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. File Directory Through Presence Information . . . . . . . 6
3.4. File Download . . . . . . . . . . . . . . . . . . . . . . 7
4. Publication of File Metadata . . . . . . . . . . . . . . . . . 7
4.1. File Metadata Publication in Support of Search
Operations . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Initial File Metadata Publication . . . . . . . . . . 7
4.1.2. Publication of Modified File Metadata . . . . . . . . 8
4.1.3. Actions Performed by the ESC . . . . . . . . . . . . . 9
4.2. File Metadata Publication in Support of Directory
Operations . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Search Operation . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Sending a Search Request . . . . . . . . . . . . . . . . . 12
5.2. Reporting Search Results . . . . . . . . . . . . . . . . . 12
5.3. Propagating Searches . . . . . . . . . . . . . . . . . . . 13
5.3.1. Searching Based on Flooding . . . . . . . . . . . . . 13
5.3.2. Searching Based on Distributed Hash Tables (DHT) . . . 14
5.4. Terminating a Search Request . . . . . . . . . . . . . . . 14
5.5. Example of a Search Filter . . . . . . . . . . . . . . . . 14
6. Directory Operations Through Presence Information . . . . . . 16
7. Downloading a file . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Garcia-Martin, et al. Expires December 10, 2007 [Page 2]
Internet-Draft SIP File Sharing June 2007
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] is a text-based
protocol for initiating and managing communication sessions. The
protocol is extended by the SIP-events framework [RFC3265] 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 publication mechanism [RFC3903] that
allows a user to supply resource metadata related to the state and
changes in the state of such resource. A 'file' event package
[I-D.garcia-sipping-file-event-package] 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.
All these building blocks can be easily combined to provide a
mechanism whereby users can provide 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.
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.
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 RFC
3265 [RFC3265]) and Event State Compositor (ESC) (defined in RFC 3903
[RFC3903]). 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.
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
Garcia-Martin, et al. Expires December 10, 2007 [Page 3]
Internet-Draft SIP File Sharing June 2007
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.
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.
2. Definitions and Document Conventions
In addition to the definitions of RFC 3265 [RFC3265], and RFC 3903
[RFC3903], this document introduces the following new terms:
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.
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.
File descriptor: A subset of the file metadata that uniquely
identifies the file.
File directory: A device storing the file descriptors of a set of
files; also called ESC in this document.
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.
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.
Garcia-Martin, et al. Expires December 10, 2007 [Page 4]
Internet-Draft SIP File Sharing June 2007
File transfer operation: An operation whereby a UA downloads a file
from a remote UA.
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
Indented passages such as this one are used in this document to
provide additional information and clarifying text. They do not
contain descriptions of normative protocol behavior.
3. Use Cases
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.
3.1. File Publication
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.
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.
File publication is further discussed in Section 4.1.1.
3.2. File Search
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
Garcia-Martin, et al. Expires December 10, 2007 [Page 5]
Internet-Draft SIP File Sharing June 2007
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'.
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.
Search operations are further discussed in Section 5.
3.3. File Directory Through Presence Information
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.
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.
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.
This document does not specify implementation of the file browsing
via presence information. A solution is described in the Internet-
Draft 'File Descriptions Extension to the PIDF'
[I-D.garcia-sipping-file-desc-pidf].
File directory through presence information is further discussed in
Section 6.
Garcia-Martin, et al. Expires December 10, 2007 [Page 6]
Internet-Draft SIP File Sharing June 2007
3.4. File Download
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.
Section 7 provides further discussion on downloading files.
4. Publication of File Metadata
Publication of File Metadata is based on the PUBLISH method specified
in RFC 3903 [RFC3903]. We proposed two variants of publication,
depending on whether the publication supports search operations or
directory operations. To support the former, publication is done
together with the 'file' event package
[I-D.garcia-sipping-file-event-package]. To support the later, the
Presence Information Data Format (PIDF) [RFC3863] is extended to
provide a description of available files together with the presence
information of the presentity.
4.1. File Metadata Publication in Support of Search Operations
4.1.1. Initial File Metadata Publication
Initial file metadata publication is perfomed to publish metadata
about the availability of one or more files to the ESC. Figure 1
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).
Garcia-Martin, et al. Expires December 10, 2007 [Page 7]
Internet-Draft SIP File Sharing June 2007
EPA ESC
| |
| SIP/2.0 PUBLISH |
| Event: file |
| (file-metadata document) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: x |
| <------------------------------------ |
| |
Figure 1: Signaling flow for publication of file metadata
The EPA performs the initial file metadata publication by sending a
PUBLISH [RFC3903] 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 'file' event package
[I-D.garcia-sipping-file-event-package]. 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.
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.
The PUBLISH request is routed to the ESC. The ESC sends a 200 OK
response that, according to RFC 3903 [RFC3903], 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.
Note that the actual file is not transmitted at any point to the
ESC: only the metadata associated with the file is transmitted.
4.1.2. Publication of Modified File Metadata
Whenever a file is modified or new files are added or deleted from
the endpoint, the EPA refreshes the previous publication by sending a
Garcia-Martin, et al. Expires December 10, 2007 [Page 8]
Internet-Draft SIP File Sharing June 2007
new PUBLISH request, as shown in Figure 2. 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.
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.
RFC 3903 [RFC3903] 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.
EPA ESC
| |
| SIP/2.0 PUBLISH |
| SIP-If-Match: x |
| Event: file |
| (file-metadata document) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: y |
| <------------------------------------ |
| |
Figure 2: Signaling flow for publication of modified file metadata
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.
4.1.3. Actions Performed by the ESC
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.
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
Garcia-Martin, et al. Expires December 10, 2007 [Page 9]
Internet-Draft SIP File Sharing June 2007
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.
4.2. File Metadata Publication in Support of Directory Operations
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 PIDF [RFC3863] document
according to the Presence Data Model [RFC4479]. The <device> element
of the data model contains the file metadata. This is further
described in a the Internet-Draft 'File Descriptions Extension to the
PIDF' [I-D.garcia-sipping-file-desc-pidf].
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.
EPA ESC
| |
| SIP/2.0 PUBLISH |
| Event: presence |
| (PIDF + data model + |
| file-metadata in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: x |
| <------------------------------------ |
| |
Figure 3: Signaling flow for publication of presence information that
includes file metadata
Publication of modified file metadata in the PIDF is done similarly
to the publication of modified file metadata (see Section 4.1.2), but
the event package is set to presence.
Garcia-Martin, et al. Expires December 10, 2007 [Page 10]
Internet-Draft SIP File Sharing June 2007
5. Search Operation
The search of shared files is implemented with the SIP event
framework defined in RFC 3265 [RFC3265] in conjunction with the
'file' event package [I-D.garcia-sipping-file-event-package] and a
filter document [RFC4661].
The signaling flow for a search operation is shown in Figure 4.
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 |
| ------------------------------------> |
| |
Figure 4: Signaling flow of a search operation
Garcia-Martin, et al. Expires December 10, 2007 [Page 11]
Internet-Draft SIP File Sharing June 2007
5.1. Sending a Search Request
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 XML format for filters [RFC4661]. 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.
5.2. Reporting Search Results
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 (RFC 3265 [RFC3265]) requires an immediate
NOTIFY after each successful SUBSCRIBE request. The NOTIFY request
is acknowledged with a 200 (OK) response.
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.
To report matching files, the ESC sends NOTIFY requests to the
subscriber. The body of the initial NOTIFY contains a full 'file-
metadata' document that is formatted according to the 'file' event
package [I-D.garcia-sipping-file-event-package] and it can contain
metadata about several files that matched the search criteria. The
'file' event package defines all the file metadata, 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
Garcia-Martin, et al. Expires December 10, 2007 [Page 12]
Internet-Draft SIP File Sharing June 2007
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.
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.
5.3. Propagating Searches
In many cases, such as in P2P systems, the metadata is distributed in
several ESCs. We consider two special cases:
1. 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.
2. In a DHT based architecture, such as Chord, a specific ESC is
responsible for a specific set of metadata.
In both cases, the ESC/ESCs containing the required file metadata may
be another ESC than the one receiving the SUBSCRIBE request.
5.3.1. Searching Based on Flooding
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 URI-list server [RFC4662] 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
Garcia-Martin, et al. Expires December 10, 2007 [Page 13]
Internet-Draft SIP File Sharing June 2007
this memo.
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.
The subscriber is getting periodic partial notifications, each one
adding new files or new instances of existing files to the list of
file descriptors.
5.3.2. Searching Based on Distributed Hash Tables (DHT)
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.
5.4. Terminating a Search Request
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 RFC 3265 [RFC3265].
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 RFC 3265 [RFC3265].
5.5. Example of a Search Filter
Figure 4 provides the signaling flow for a search operation. The
SUBSCRIBE request contains a filter body, formatted according to the
filter data format [RFC4661]. Figure 5 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.
SUBSCRIBE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.example.net;branch=z9hG4bKnashds7
Garcia-Martin, et al. Expires December 10, 2007 [Page 14]
Internet-Draft SIP File Sharing June 2007
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:resource-set/rs:resource/rs:identity/rs:urn
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:identity/rs:mime-type
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:identity/rs:size
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:identity/rs:sha-1
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:instance/rs:uri
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:instance/rs:user-aor
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:instance/rs:user-gruu
</include>
<include type="xpath">
/rs:resource-set/rs:resource/rs:instance/rs:description
</include>
<include type="xpath">
Garcia-Martin, et al. Expires December 10, 2007 [Page 15]
Internet-Draft SIP File Sharing June 2007
/rs:resource-set/rs:resource/rs:instance[rs:keyword="vacation"]
</include>
</what>
</filter>
</filter-set>
Figure 5: Example of a search filter
6. Directory Operations Through Presence Information
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 Figure 6, 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.
All the presence mechanisms are available also in directory
operations. For example, partial notifications, presence
authorization rules, filters, etc., are applicable.
Garcia-Martin, et al. Expires December 10, 2007 [Page 16]
Internet-Draft SIP File Sharing June 2007
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 |
| ------------------------------------> |
| |
Figure 6: Signaling flow of a directory operation through presence
7. Downloading a file
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
[I-D.ietf-mmusic-file-transfer-mech]. In this case, the SIP INVITE
request is addressed (Request-URI) to the URI contained in a <user-
gruu> (preferred option) or <user-aor> 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.
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
Garcia-Martin, et al. Expires December 10, 2007 [Page 17]
Internet-Draft SIP File Sharing June 2007
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.
8. Security Considerations
TBD
9. IANA Considerations
This document contains no actions to IANA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[I-D.garcia-sipping-file-event-package]
Garcia-Martin, M. and M. Matuszewski, "A Session
Initiation Protocol (SIP) Event Package and Data Format
for File Metadata Description",
draft-garcia-sipping-file-event-package-00 (work in
progress), June 2007.
Garcia-Martin, et al. Expires December 10, 2007 [Page 18]
Internet-Draft SIP File Sharing June 2007
[I-D.garcia-sipping-file-desc-pidf]
Garcia-Martin, M. and M. Matuszewski, "File Descriptions
Extension to the Presence Information Data Format (PIDF)",
draft-garcia-sipping-file-desc-pidf-00 (work in progress),
June 2007.
10.2. Informative References
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format
for Event Notification Filtering", RFC 4661,
September 2006.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[I-D.ietf-mmusic-file-transfer-mech]
Garcia-Martin, M., "A Session Description Protocol (SDP)
Offer/Answer Mechanism to Enable File Transfer",
draft-ietf-mmusic-file-transfer-mech-03 (work in
progress), June 2007.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia Siemens Networks
P.O.Box 6
Nokia Siemens Networks, FIN 02022
Finland
Email: miguel.garcia@nsn.com
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Garcia-Martin, et al. Expires December 10, 2007 [Page 19]
Internet-Draft SIP File Sharing June 2007
Nicklas Beijar
Helsinki University of Technology
P.O.Box 3000
TKK, FIN 02015
Finland
Phone: +358 9 451 5303
Email: nbeijar@netlab.tkk.fi
URI: http://www.netlab.tkk.fi/
Juuso Lehtinen
Tellabs
Sinimaentie 6
Espoo, FI 02630
Finland
Phone: +358 40 820 5223
Email: juuso.lehtinen@tellabs.com
Garcia-Martin, et al. Expires December 10, 2007 [Page 20]
Internet-Draft SIP File Sharing June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Garcia-Martin, et al. Expires December 10, 2007 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 04:04:25 |