One document matched: draft-garcia-sipping-resource-sharing-framework-00.txt
SIPPING Working Group M. Garcia-Martin
Internet-Draft M. Matuszewski
Intended status: Standards Track Nokia
Expires: December 15, 2006 N. Beijar
J. Lehtinen
Helsinki University of Technology
June 13, 2006
A Framework for Sharing Resources with the Session Initiation Protocol
(SIP)
draft-garcia-sipping-resource-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 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo proposes a SIP framework used for advertising and searching
for shared resources, such as services or files, within a given
community. The memo defines the signaling used by users to signal
the availability of resources stored in their User Agents (UA). It
Garcia-Martin, et al. Expires December 15, 2006 [Page 1]
Internet-Draft SIP Resource Sharing Framework June 2006
also provides the signaling for users to perform searches of
available resources and monitor changes in existing resources.
Additionally, we provide the signaling used to access a resource.
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. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4. Resource Publication . . . . . . . . . . . . . . . . . . . . . 6
4.1. Initial resource metadata publication . . . . . . . . . . 6
4.2. Publication of modified resource metadata . . . . . . . . 7
4.3. Actions performed by the ESC . . . . . . . . . . . . . . . 8
5. Search Operation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Sending a search request . . . . . . . . . . . . . . . . . 9
5.2. Reporting search results . . . . . . . . . . . . . . . . . 10
5.3. Propagating searches . . . . . . . . . . . . . . . . . . . 11
5.3.1. Searching based on flooding . . . . . . . . . . . . . 11
5.3.2. Searching based on distributed hash tables (DHT) . . . 12
5.4. Terminating a Search Request . . . . . . . . . . . . . . . 12
5.5. Example of a search filter . . . . . . . . . . . . . . . . 12
6. Accessing a Resource . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Garcia-Martin, et al. Expires December 15, 2006 [Page 2]
Internet-Draft SIP Resource Sharing Framework June 2006
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 'resource' event package
[I-D.draft-garcia-sipping-resource-event-package] is used to allow
SIP User Agents to publish, subscribe, and get notifications of the
availability of generic resources, where a resource can be, for
example, a file (e.g., images, video files, audio files), a chat
room, streaming content, a printer, a printer job, etc. All these
building blocks can easily be combined to provide a generic mechanism
whereby users can provide the availability at their user agents of
resources of any kind. The mechanism can also provide a directory
search within a publishing community, so that members of the
community can search for the availability of resources that have been
made available by other members of the same community, and then
further access those resources (e.g., join a chat room or download a
file, etc.).
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 resouce metadata
describing her available files. The resource metadata is stored in
the peer nodes, in the user agents of Alice's family members. 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 resource metadata. This might be useful in cases where
several instances of the same resource 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 that the server 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
Garcia-Martin, et al. Expires December 15, 2006 [Page 3]
Internet-Draft SIP Resource Sharing Framework June 2006
network. ESCs are primary nodes (super peers). In this scenario,
publication of resource 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 algorithm (e.g. Chord), or alternatively, distribute
the search request among themselves reactively as a resource is
needed.
This memo describes a framework where SIP is used for advertising and
searching for shared resources, such as services or files. The
framework defines the signaling used for users to signal the
availability of resources stored in their User Agents (UA). It also
provides the signaling used for users to perform searches of
available resources and monitor changes in existing resources.
Additionally, signaling used to access a resource 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 resources among members of the community. A
community can be composed of an enterprise, a group of friends,
family members, or members of a club.
Resource: An abstraction of a shared object, which can be a service
or information, e.g. in the form of an audio/video stream or a
static file.
Resource metadata: A set of properties describing the resource. The
resource metadata can include the hash (if resource is hashable),
name, creation date, Uniform Resource Name (URN), Uniform Resource
Identifier (URI), and other relevant information.
Resource descriptor: A subset of the resource metadata that uniquely
identifies one resource.
Resource directory: A device storing the resource descriptors of a
set of resources; also called ESC in this document.
Search operation: Signalling issued by a user to get information of
the available resources and its associated metadata. Typically
search operations are delimited with search filters.
Garcia-Martin, et al. Expires December 15, 2006 [Page 4]
Internet-Draft SIP Resource Sharing Framework June 2006
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 resource
description, etc.
File transfer operation: An operation whereby a User Agent gets a
file resource 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. Overview of Operation
Prior to starting any of the resource sharing operations, a SIP User
Agent needs to join a community. Communities can be created around a
given SIP peer-to-peer network, around a centralized server that
keeps track of shared resources, in and ad-hoc network, or by some
other means. A user may need to join the community explicitly, e.g.
using some additional signaling or manual configuration.
Alternatively, a community may be open, allowing implicit joining by
making resources available to the community.
Once a user has joined a given community, he decides to share one or
more resources with the community. Due to security restrictions, we
only consider resources that are hosted by the SIP UA that the user
is using, for example, images and videoclips taken with a digital
camera, streaming content, chat rooms hosted by the SIP UA, printers
connected to the SIP UA, etc.
Typically the operation of selecting the resources that are shared
with a given community requires some initial configuration, so that
the user decides which resources are made accesable to other users.
This may imply selection of directories where files are available or
individual selection of different resources.
Once the selection of shared resources is done, the SIP UA may
publish the availability of those resources towards an Event State
Compositor (ESC). The ESC can be a central server or a node
participating in a DHT. The step may require some configuration,
such as the URL of the ESC. Resource publication is further
discussed in Section 4.1.
Garcia-Martin, et al. Expires December 15, 2006 [Page 5]
Internet-Draft SIP Resource Sharing Framework June 2006
A user can perform a search operation, when he is interested in
accessing (downloading, joining, or obtaining service from) a
resource. Search operations are implemented as short-lived
subscriptions that include a filter to define the searched resources.
Results of search operations are conveyed in a series of notications.
Additionally, in cases where monitoring of a resource is required, a
longer-lived subscription can be installed. Search operations are
further discussed in Section 5.
Once a user has got knowledge of a resource and its availability, he
can access it by joining the resource (e.g., if it is a conference),
downloading it (if it is a file), or doing an appropriate action.
Section 6 provides further discussion.
4. Resource Publication
Resource publication is based on the PUBLISH method specified in RFC
3903 [RFC3903] together with the 'resource' event package
[I-D.draft-garcia-sipping-resource-event-package].
4.1. Initial resource metadata publication
Initial resource metadata publication is perfomed to publish metadata
about the availability of one or more resources to the ESC. Figure 1
presents the signaling flow required for an Event Publishing Agent
(EPA) to publish the availability of one or more resources towards
the Event State Compositor (ESC).
EPA ESC
| |
| SIP/2.0 PUBLISH |
| Event: resource |
| (resource metadata in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: x |
| <------------------------------------ |
| |
Figure 1: Signaling flow for publication of resource metadata
The EPA performs the initial resource metadata publication by sending
a PUBLISH [RFC3903] request to the ESC. The PUBLISH request contains
a full 'resource' document that contains metadata about one or more
resources available at the EPA. The 'resource' document is defined
in the 'resource' event package
Garcia-Martin, et al. Expires December 15, 2006 [Page 6]
Internet-Draft SIP Resource Sharing Framework June 2006
[I-D.draft-garcia-sipping-resource-event-package]. Each resource is
described using a set of invariant metadata and a set of metadata
specific to each instance of the resource, given in the <identity>
and <instance> child elements of the <resource> element.
In case of publishing availability of a file, the invariant metadata
contains the following attributes: the Uniform Resource Name (URN),
the MIME type (e.g., image/jpeg), the size and the SHA1 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 resource 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 where the file is
stored.
In case of publishing availablility of some other type of resource,
the attributes are used as applicable.
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 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.2. Publication of modified resource metadata
Whenever a resource is modified or new resources are added or deleted
from the endpoint, the EPA refreshes the previous publication by
sending a new PUBLISH request, as shown in Figure 2. This
publication carries a partial 'resource' document that contains a
number of XML patch operations that add, remove, or replace XML
elements towards the last published 'resource' document.
A resource 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 resource 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 'resource' document provide the means to
Garcia-Martin, et al. Expires December 15, 2006 [Page 7]
Internet-Draft SIP Resource Sharing Framework June 2006
synchronize versions.
EPA ESC
| |
| SIP/2.0 PUBLISH |
| SIP-If-Match: x |
| Event: resource |
| (resource description in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| SIP-ETag: y |
| <------------------------------------ |
| |
Figure 2: Signaling flow for publication of modified resource
metadata
If a resouce becomes unavailable at the EPA, e.g., as a result of a
file deletion, the resource publication contains a partial 'resource'
document that describes the resource to be removed.
4.3. Actions performed by the ESC
As the ESC receives initial or updated publications, the ESC will
typically locally store 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 the 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
the overlay SIP P2P network. This step heavily depends on the chosen
peer-to-peer algorithm. For example, if the SIP P2P 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
resource metadata and store it in the appropriate node. The actual
mechanism to update resource metadata is dependent on the specific
algorithm and out of scope of this memo.
5. Search Operation
The search of shared resources is implemented with the SIP event
framework defined in RFC 3265 [RFC3265] in conjunction with the
Garcia-Martin, et al. Expires December 15, 2006 [Page 8]
Internet-Draft SIP Resource Sharing Framework June 2006
'resource' event package
[I-D.draft-garcia-sipping-resource-event-package] and a filter
document [I-D.ietf-simple-filter-format].
The signaling flow for a search operation is shown in Figure 3.
Subscriber Notifier
| |
| SIP/2.0 SUBSCRIBE |
| Event: resource |
| (search filter in body) |
| ------------------------------------> |
| |
| 200 OK SIP/2.0 |
| <------------------------------------ |
| |
| SIP/2.0 NOTIFY |
| Event: resource |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
| SIP/2.0 NOTIFY |
| Event: resource |
| (resource descriptor in body) |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
| SIP/2.0 NOTIFY |
| Event: resource |
| Subscription-State: terminated |
| (resource descriptor in body) |
| <------------------------------------ |
| |
| 200 OK SIP/2.0 |
| ------------------------------------> |
| |
Figure 3: Signaling flow of a search operation
5.1. Sending a search request
To search for a resource, the subscriber first builds a filter
containing the data of the searched resource. The filter can
contain, for example, keywords, file names, types of files, etc. The
Garcia-Martin, et al. Expires December 15, 2006 [Page 9]
Internet-Draft SIP Resource Sharing Framework June 2006
filter conforms to the XML format for filters
[I-D.ietf-simple-filter-format]. Then it attaches the filter to a
SUBSCRIBE request for the resource 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 'resource' document according to the filtered content.
5.2. Reporting search results
After receiving the SUBSCRIBE message, and acknowledging it with a
200 OK, the Notifier sends a NOTIFY request to the Subscriber. This
request may contain a first collection of metadata about the searched
resources, if such information is already available in the ESC, in a
full 'resource' 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 metadata about the searched
resources, 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
resources, whose metadata is stored in other ESCs (see section 4.3).
Due to this propagated search, additional matching resource
descriptors may become known. New matching resource descriptors may
also become known as a result of PUBLISH requests received by the ESC
within the duration of the subscription.
To report matching resources, the ESC sends NOTIFY requests to the
Subscriber. The body of the initial NOTIFY contains a full
'resource' document that is formatted according to the 'resource'
event package [I-D.draft-garcia-sipping-resource-event-package] and
it can contain metadata about several resources that matched the
search criteria. The 'resource' event package defines all the
metadata associated to each resource, including the file name, size,
type, icon, hash, SIP URI and UE (GRUU) of the users where the file
is available, etc. In some cases, the metadata that describes a
given resource will provide more than one location of the resource.
This will typically be the case when a popular resource (e.g., a
file) is available in several endpoints. Then the 'resource' XML
document supplied in the NOTIFY request will contain more than one
<instance> child element in a given <resource>element. It may also
Garcia-Martin, et al. Expires December 15, 2006 [Page 10]
Internet-Draft SIP Resource Sharing Framework June 2006
be necessary to divide a NOTIFY request into several smaller due to
the user's preferences (rate of notifications, bandwidth consumption,
and event throttling). The NOTIFY requests are acknowledged with a
200 OK response.
The initial NOTIFY request contains a full 'resource' XML document.
Once the notifier acquires more metadata, it sends partial 'resource'
XML documents with additions, replacement, or removals. Upon
reception of a new partial 'resource' document, the subscriber
composes a full 'resource' XML document, based on the existing
previous version plus the partial notification. Then, the subscriber
UA has the new full 'resource' XML 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 resources. A given ESC is
only aware of resources 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 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 consults
its local database to find matching resources and it replies with a
NOTIFY request that may contain a 'resource' document if matching
resources are found locally. The ESC also acts as an URI-list server
[I-D.ietf-simple-event-list] 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 is still positive and provided that the ESC
hasn't already processed the same request. The generation and
maintenance of the neighbor table is out of scope of this memo.
The ESC will receive NOTIFY requests from other neighbor nodes, each
of the requests containing a different 'resource' document. The ESC
Garcia-Martin, et al. Expires December 15, 2006 [Page 11]
Internet-Draft SIP Resource Sharing Framework June 2006
will aggregates and composes a single 'resource' 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 resources or new instances of existing resources.
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 resource). For file
resources the search key is the hash. 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 to that ESC. Finally the SUBSCRIBE will reach
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 (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 3 provides the signaling flow for a search operation. The
SUBSCRIBE request contains a filter body, formatted according to the
filter data format [I-D.ietf-simple-filter-format]. Figure 4 shows
an example of the SUBSCRIBE request carrying a filter. The filter
selects a few XML elements of a resource 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
Max-Forwards: 70
From: <sip:alice@example.net>;tag=31415
To: <sip:bob@example.com>
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 61 SUBSCRIBE
Event: resource
Expires: 180
Garcia-Martin, et al. Expires December 15, 2006 [Page 12]
Internet-Draft SIP Resource Sharing Framework June 2006
Accept: application/resource+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:resource"/>
</ns-bindings>
<filter id="ad982" uri="sip:bob@example.com">
<what>
<include type="xpath">
/rs:resource-set/rs:resource
</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">
/rs:resource-set/rs:resource/rs:instance[rs:keyword="vacation"]
</include>
</what>
</filter>
</filter-set>
Figure 4: Example of a search filter
Garcia-Martin, et al. Expires December 15, 2006 [Page 13]
Internet-Draft SIP Resource Sharing Framework June 2006
6. Accessing a Resource
Once the search operation is complete, the user can select whether to
do any further operation on a given resource, and if so, on which
instance to operate. This heavily depends on the type of resource
that has been shared. File resources 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. This mechanism is described
in [I-D.garcia-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 <resource>. 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 resource
in the <urn> or <uri> elements of that <resource>. The mechanism to
retrieve or receive service from the resource is dependent on it.
For example, an HTTP URI requires an HTTP GET request to retrieve the
resource. Similarly FTP URIs require the establishment of an FTP
session.
7. Security Considerations
TBD
8. References
8.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.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
Garcia-Martin, et al. Expires December 15, 2006 [Page 14]
Internet-Draft SIP Resource Sharing Framework June 2006
[I-D.draft-garcia-sipping-resource-event-package]
Garcia-Martin, M. and M. Matuszewski, "A Session
Initiation Protocol (SIP) Event Package and Data Format
for Publication and Searching Generic Resources",
draft-garcia-sipping-resource-event-package-00 (work in
progress), June 2006.
8.2. Informative References
[I-D.garcia-mmusic-file-transfer-mech]
Garcia-Martin, M., Isomaki, M., Camarillo, G., and S.
Loreto, "Session Description Protocol (SDP) Offer/Answer
Mechanism to Enable File Transfer",
draft-garcia-mmusic-file-transfer-mech-00 (work in
progress), June 2006.
[I-D.ietf-simple-filter-format]
Khartabil, H., "An Extensible Markup Language (XML) Based
Format for Event Notification Filtering",
draft-ietf-simple-filter-format-05 (work in progress),
March 2005.
[I-D.ietf-simple-event-list]
Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", draft-ietf-simple-event-list-07 (work in
progress), January 2005.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: miguel.an.garcia@nokia.com
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Garcia-Martin, et al. Expires December 15, 2006 [Page 15]
Internet-Draft SIP Resource Sharing Framework June 2006
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
Helsinki University of Technology
P.O.Box 3000
TKK, FIN 02015
Finland
Phone: +358 9 451 2472
Email: juuso@netlab.tkk.fi
URI: http://www.netlab.tkk.fi/
Garcia-Martin, et al. Expires December 15, 2006 [Page 16]
Internet-Draft SIP Resource Sharing Framework June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 15, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:55 |