One document matched: draft-garcia-sipping-file-event-package-00.txt
SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Matuszewski
Expires: December 10, 2007 Nokia
June 8, 2007
A Session Initiation Protocol (SIP) Event Package and Data Format for
Describing Files
draft-garcia-sipping-file-event-package-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 document specifies the format and semantics associated to a
'file' event package that allows SIP endpoints to publish the
availability of files. A file can be, for example, images, video
files, audio files, etc. File descriptors are provided in an
eXtended Mark-up Language (XML) 'file-metadata' document. This event
package also allows SIP endpoints to subscribe to changes in the
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 1]
Internet-Draft File Event Package in SIP June 2007
availability of files, or perform searches for the availability and
location of a given file. Support for partial notifications and
publications is also accomplished by using XML patch operations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The 'file' Event Package . . . . . . . . . . . . . . . . . . . 5
3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5
3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
3.4. Subscription duration . . . . . . . . . . . . . . . . . . 6
3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 7
3.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7
3.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7
3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7
3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9
3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10
3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 10
3.14. PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 10
3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 11
3.16. Multiple Sources for Event State . . . . . . . . . . . . . 11
3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 11
3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 11
4. The 'file-metadata' Document . . . . . . . . . . . . . . . . . 12
4.1. Full 'file-metadata' document . . . . . . . . . . . . . . 12
4.2. Partial 'file-metadata' document: patch operations . . . . 15
4.3. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1. Example of a full 'file-document' document in a
publication . . . . . . . . . . . . . . . . . . . . . 19
4.4.2. Example of a partial 'file-metadata' document used
in a publication . . . . . . . . . . . . . . . . . . . 21
4.4.3. Example of a full 'file-metadata' document used in
a notification . . . . . . . . . . . . . . . . . . . . 22
4.4.4. Example of a partial 'file-metadata' document used
in a notification . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Registration of the 'file' Event Package . . . . . . . . . 25
7.2. Registration of the "application/file+xml" MIME type . . . 25
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 2]
Internet-Draft File Event Package in SIP June 2007
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 3]
Internet-Draft File Event Package in SIP June 2007
1. Introduction
There are scenarios where a SIP endpoint has a number of available
files that can be offered for public disposal or for a limited number
of authorized users. One of these cases is, for example, when Alice
takes some pictures with her camera phone and she wants to share them
within a community. This requires a mechanism that allows Alice to
describe the files she wants to share.
In another scenario, Alice might be interested in finding out the
availability of a given file, defined by a set of parameters. Think,
for example, of Alice trying to find pictures of the bowling
tournament that took place recently in her home town. This implies a
mechanism whereby Alice can perform searches of available files. The
user who performs the search identifies one or more aspects of the
file she is searching, but probably she is not able to provide a full
description of the file.
SIP [RFC3261] provides an extensible event mechanism [RFC3265] that
is suitable for our needs. We enable the above scenarios by defining
a SIP event package for file metadata publication and search. We
define a 'file-metadata' document that allows an Event Publication
Agent (EPA) to provide a description of locally available files in a
PUBLISH request [RFC3903]. In a community, there can be an Event
State Compositor that aggregates shared files available at different
endpoints. The Event State Compositor (ESC) that receives the
PUBLISH request processes 'file-metadata' documents according to a
well defined strategy (which is outside the scope of this document).
For example, the ESC can be a centralized intermediary facilitator
for a given community, or it can be a super-node of a SIP Peer-to-
Peer (P2P) network.
A user that searches for one or more files issues a SUBSCRIBE request
(either a subscription or a fetch of state, see RFC 3265 [RFC3265])
to the 'file' event package. Because a subscription to all of the
files published in the community is likely to contain a large amount
of data, the subscriber will typically attach a filter [RFC4661] that
describes the files under search. This will result in the generation
of one or more NOTIFY requests that contains the searched items.
Once the information on files is retrieved, the subscriber can use
any suitable mechanism (such as the one defined in "Session
Description Protocol (SDP) Offer/Answer Mechanism to Enable File
Transfer" [I-D.ietf-mmusic-file-transfer-mech]) to actually download
the file. Such file transfer mechanisms are outside the scope of
this memo.
In the file descriptor, smetimes the URI points to the file itself
itself (such as an HTTP URI that points to an image file). In other
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 4]
Internet-Draft File Event Package in SIP June 2007
cases the URI merely resolves to a host where the content is
available (for example, the SIP URI of a camera phone that stores
images).
2. Terminology
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.
3. The 'file' Event Package
RFC 3265 [RFC3265] defines a SIP extension for subscribing to, and
receiving notifications of changes (events) in the state of remote
nodes. It leaves the definition of many aspects of these events to
concrete extensions, known as event packages. This document
qualifies as an event package. This section fills in the information
required for all event packages by RFC 3265 [RFC3265].
Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP
User Agents to publish event state. According to RFC 3903 [RFC3903]
any event package intended to be used in conjunction with the SIP
PUBLISH method has to include a considerations section. This section
also fills the information for all event packages to be used with
PUBLISH requests.
We define a new 'file' event package. Event Publication Agents (EPA)
use PUBLISH requests to inform an Event State Compositor (ESC) of
changes in the 'file' event package. The ESC, acting as a notifier,
notifies subscribers to the 'file' event package when changes occur.
3.1. Package Name
The name of this package is 'file'. As specified in RFC 3265
[RFC3265], this value appears in the Event header field present in
SUBSCRIBE and NOTIFY requests. As specified in the RFC 3903
[RFC3903], this value appears as well in the Event header field
present in PUBLISH requests.
3.2. Event Package Parameters
RFC 3265 [RFC3265] allows event packages to define additional
parameters carried in the Event header field. This event package,
'file', does not define additional parameters.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 5]
Internet-Draft File Event Package in SIP June 2007
3.3. SUBSCRIBE Bodies
According to RFC 3265 [RFC3265], a SUBSCRIBE request can contain a
body. The purpose of the body depends on its type. Subscriptions to
the 'file' event package MAY contain a filter body according to the
format specified in [RFC4661]. Filters are used to reduce the number
of results during searches.
3.4. Subscription duration
From the functional point of view, there are two kinds of
subscriptions to the 'file' even package. In one, the user may want
to either perform a single search operation on the existing files.
In the other, the user may want to monitor the changes in the state
information of files. These functionalities can be controlled by the
duration of the subscription.
A search on existing files can be implemented with a single fetch
operation (where the Expires header field is set to zero) or by a
subscription of a short duration (typically on the order of a few
minutes). The other functionality, where a user wants to monitor the
changes of a state, is typically implemented as a lengthy
subscription, on the order of hours, as the user needs to be notified
whenever a change in the file has occurred.
Due to the lack of congruence in the two types of subscriptions, it
is hard to select a default expiration value. We have decided to
select a mean default value that accommodate both types of
subscriptions: 1800 seconds. As per RFC 3265 [RFC3265], the
subscriber MAY specify an alternate expiration in the Expires header
field. It is RECOMMENDED that UACs always include an explicit
Expires header field with the desired subscription value.
3.5. NOTIFY Bodies
As described in RFC 3265 [RFC3265], the NOTIFY message can contain a
body describing the state of the subscribed resources. This body is
either in a format listed in the Accept header field of the SUBSCRIBE
request, or in a package-specific default format, if the Accept
header field was omitted from the SUBSCRIBE request.
In this event package, the body of the notification contains a 'file-
metadata' document (see Section 4), expressed as either a full 'file-
metadata' document or a partial 'file-metadata' document. The ESC
can receive 'file-metadata' documents from different EPAs or other
sources. The ESC applies a composition policy, and composes a 'file-
metadata' document that contains all the available known files to the
EPA. If the ESC is not able to resolve a conflict, due to
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 6]
Internet-Draft File Event Package in SIP June 2007
contradictory information provided by two different EPAs, the ESC
provides a comprehensive information for that file, so that the
subscriber can resolve the conflict.
All subscribers and notifiers of 'file' event package MUST support
the "application/file+xml" data format described in Section 4. The
SUBSCRIBE request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/
file+xml" (assuming that the Event header field contains a value of
'file'). If the Accept header field is present, it MUST include
"application/file+xml", and MAY include any other types capable of
representing 'file-metadata' documents.
3.6. Notifier processing of SUBSCRIBE requests
The contents of a 'file-metadata' document can contain sensitive
information that can reveal some privacy information. For example,
it can contain a list of valuable files and the address (SIP URI) of
the SIP User Agent where those are stored. While this information
itself is not very useful, it can be used by malicious agents, e.g.,
to mount an attack to avoid other users to retrieve such a file.
Therefore, 'file-metadata' documents MUST only be sent to authorized
subscribers. In order to determine if a subscription originates in
an authorized user, the user MUST be authenticated as described in
Section 3.6.1 and then he MUST be authorized to be a subscriber as
described in Section 3.6.2.
3.6.1. Authentication
Notifiers SHOULD authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in RFC
3261 [RFC3261] and other authentication extensions.
3.6.2. Authorization
Once authenticated, the notifier makes an authorization decision. A
notifier MUST NOT accept a subscription unless authorization has been
provided by the user. The means by which authorization are provided
are outside the scope of this document. Authorization may have been
provided ahead of time through access lists, perhaps specified in a
web page, or provided with the Common Policy Framework [RFC4745].
3.7. Notifier Generation of NOTIFY Requests
RFC 3265 [RFC3265] details the formatting and structure of NOTIFY
messages. However, packages are mandated to provide detailed
information on when to send a NOTIFY request, how to compute the
state of the resource, how to generate neutral or fake state
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 7]
Internet-Draft File Event Package in SIP June 2007
information, and whether state information is complete or partial.
This section describes those details for the 'file' event package.
A notifier MAY send a NOTIFY at any time. The NOTIFY request MAY
contain a body containing a 'file-metadata' document. The times at
which the NOTIFY is sent to a particular subscriber, and the contents
of the body within that notification, are subject to any rules
specified by the authorization policy that governs the subscription,
but typically will contain an indication of those known files for
which a change has occurred.
Since 'file-metadata' documents can contain full or partial state,
the first 'file-metadata' document that a notifier sends to
subscriber MUST contain be a full 'file-metadata' document.
Subsequent documents sent to the same subscriber MAY contain full
'file-metadata' documents or partial 'file-metadata' documents
(Section 4 provides further discussion about full and partial 'file-
metadata' documents).
In the case of a pending subscription, when final authorization is
determined, a NOTIFY request can be sent. If the result of the
authorization decision was success, a NOTIFY SHOULD be sent and
SHOULD contain a full 'file-metadata' document with the current state
of the files known by the notifier at that moment. If the
subscription is rejected, a NOTIFY MAY be sent. As described in RFC
3265 [RFC3265], the Subscription-State header field indicates the
state of the subscription.
Frequently, the notifier will have a incomplete view of the available
files described in a 'file-metadata' document. For the duration of
the subscription, the notifier can be running searches for the
availability of the searched files. When new state information is
made available to the notifier, the notifier SHOULD provide this
information to the subscribers, typically as notifications that
contain a partial 'file-metadata' document.
The body of the NOTIFY MUST be sent using one of the types listed in
the Accept header field in the most recent SUBSCRIBE request, or
using the type "application/file+xml" if no Accept header field was
present.
Notifiers will typically act as Event State Compositors (ESC) and
thus, will learn the 'file' event state via PUBLISH requests sent
from the user's Event Publication Agent (EPA) when the user makes one
or more files available or via subscriptions passed further to other
ESCs.
For reasons of privacy, it will frequently be necessary to encrypt
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 8]
Internet-Draft File Event Package in SIP June 2007
the contents of the notifications. This can be accomplished using
S/MIME [RFC3851]. The encryption can be performed using the key of
the subscriber as identified in the From field of the SUBSCRIBE
request. Similarly, integrity of the notifications is important to
subscribers. As such, the contents of the notifications MAY provide
authentication and message integrity using S/MIME [RFC3851]. This
will require the notifier to sign the content of the notification
with the notifier's private key.
3.8. Subscriber Processing of NOTIFY Requests
RFC 3265 [RFC3265] leaves it to event packages to describe the
process followed by the subscriber upon receipt of a NOTIFY request,
including any logic required to form a coherent resource state.
In this specification, each NOTIFY request contains either no 'file-
metadata' document, a full 'file-metadata' document representing
files which are available at one or more SIP User Agents, or a
partial 'file-metadata' document that represent changes with respect
a previously notified 'file-metadata' document. Within a dialog,
when a 'file-metadata' document is received in a NOTIFY request with
a higher CSeq header field value than a previously received NOTIFY,
and when the 'version' attribute value of the <patch> element is
increased by one (see Section 4 for more details) it contains a
partial 'file-metadata' document that updates a previously received
'file-metadata' document.
3.9. Handling of Forked Requests
RFC 3265 [RFC3265] requires each package to describe handling of
forked SUBSCRIBE requests.
This specification allows several dialogs to be constructed as a
result of emitting an initial SUBSCRIBE request, i.e., in cases where
the SUBSCRIBE request forked to several notifiers. In this case, the
subscriber will keep several simultaneous dialogs. The subscriber
SHOULD merge the several 'file-metadata' documents received in NOTIFY
requests. It might be possible that new <file> elements are received
in forked 'file-metadata' documents, or it might be possible that
existing <file> elements are updated with new information (e.g., a
new <gruu> element). In both cases the merge should provide a
logical OR operation of all the available information such as new
entries and added information to existing entries.
3.10. Rate of Notifications
RFC 3265 [RFC3265] requires each package to specify the maximum rate
at which notifications can be sent.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 9]
Internet-Draft File Event Package in SIP June 2007
Notifiers of 'file-metadata' documents SHOULD NOT generate
notifications for a single user at a higher rate than once every
second.
3.11. State Agents
RFC 3265 [RFC3265] requires each package to consider the role of
state agents in the package, and if they are used, to specify how
authentication and authorization are done.
This specification allows state agents to be located in the network.
A given file might be available at different SIP User Agents in the
network. ESCs can act as state agents by compiling and aggregating
state towards, e.g., subscribers, other networks or communities.
State agents MUST use any of the mechanism specified in RFC 3261
[RFC3261] or any other SIP extension to authenticate and authorize
users prior to accepting publications.
If the state agent acts as an aggregator, the state agent SHOULD
aggregate all the information related to the same available file. In
this case, it is expected that, because the same file is available in
different endpoints, there might be different URIs for a given
available file.
3.12. Examples
Examples of 'file-metadata' documents are provided in Section 4.4.
3.13. Use of URIs to Retrieve State
RFC 3265 [RFC3265] allows packages to use URIs to retrieve large
state documents.
A 'file-metadata' document can be of any arbitrary length, and can
also become too large to be reasonably sent in a SIP request. To
avoid the burden of transmitting large documents through SIP proxies
and to avoid potential congestion scenarios, it is possible that the
notifier instead includes a URI that points to the contents, rather
than the actual contents. For example, the notifier can include an
HTTP [RFC2616] URI that points to the notifier itself. Since HTTP
requests are transferred via a congestion controlled protocol (such
as TCP [RFC0793]), the inclusion of a URI to retrieve state mitigates
the problem of large 'file-metadata' documents.
3.14. PUBLISH bodies
RFC 3903 [RFC3903] requires event packages to define the content
types expected in PUBLISH requests.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 10]
Internet-Draft File Event Package in SIP June 2007
In this event package, the body of a PUBLISH request contains a
'file-metadata' document (see Section 4). This 'file-metadata'
document describes the availability of one or more files (typically,
but not necessarily, stored at the EPA). EPAs SHOULD only publish
the description of locally available files, i.e., the URI of the file
SHOULD resolve to the EPA itself.
All EPAs and ESCs MUST support the "application/file+xml" data format
described in Section 4 and MAY support other formats.
3.15. PUBLISH Response Bodies
This specification does not associate semantics to a body in a
PUBLISH response.
3.16. Multiple Sources for Event State
RFC 3903 [RFC3903] requires event packages to specify whether
multiple sources can contribute to the event state view at the ESC.
This event package allows different EPAs to publish the availability
of the same file. For the same file, each EPA publishes data that is
invariant with the instance of the file, and data that is specific
with each instance. The ESC SHOULD merge the data pertaining to the
same file according to a composition policy. This policy can, e.g.,
list all the difference instances where each file is available.
3.17. Event State Segmentation
RFC 3903 [RFC3903] defines segments within a state document. Each
segment is defined as one of potentially many identifiable sections
in the published event state.
In this 'file' event package, each <file> element composes a segment.
3.18. Rate of Publication
RFC 3903 [RFC3903] allows event packages to define their own rate of
publication.
There are no rate limiting recommendations for 'file' publication.
It is expected that new files are added at the time of creation
(e.g., a new image is taken with a camera phone), and that they are
not changed often. Thus, a typical rate of publication does not
exist and there is no foreseen need to limit the rate of
publications.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 11]
Internet-Draft File Event Package in SIP June 2007
4. The 'file-metadata' Document
A 'file-metadata' document is an XML document [W3C.REC-xml-20001006]
that MUST be well-formed and SHOULD be valid. A 'file-metadata'
document MUST be based on XML 1.0 and MUST be encoded using UTF-8
[RFC3629]. This specification makes use of XML namespaces for
identifying 'file-metadata' documents. The namespace URI for
elements defined by this specification is a URN [RFC2141], using the
namespace identifier 'ietf'. This URN is:
urn:ietf:params:xml:ns:file
The 'file-metadata' documents are identified with the MIME type
"application/file+xml" and are instances of the XML schema defined in
Section 4.3.
The XML schema that defines the constrains of the 'file-metadata'
document provides support for full and partial 'file-metadata'
documents in both publications and notifications. The XML schema
contains provisions for two root elements, namely <file-set> and
<patch>, of which only one MUST be present in a valid 'file-metadata'
document. The <file-set> element is used to describe a full 'file-
metadata' document, i.e., one containing a full state of the
available files. A full 'file-metadata' document MUST be used in any
initial publication or initial notification. On the contrary, the
<patch> element is used to describe a partial 'file-metadata'
document. The <patch> element contains a number of patch operations
that, once applied to a previous version of a full 'file-metadata'
document, create an updated full document. Non-initial publications
and non-initial notifications MAY use the partial publication and
partial notification mechanism provided with the <patch> element.
The XML schema rules require that only one root element is present
in an XML document. Therefore, a 'file-metadata' document
compliant with the XML schema definition contains either a <file-
set> root element or a <patch> root element, but not both.
Due to the duality of a 'file-metadata' document, depending on
whether it contains a full or a partial 'file-metadata' document, we
describe separately each of them in Section 4.1 and Section 4.2,
respectively.
4.1. Full 'file-metadata' document
A full 'file-metadata' document begins with the root element tag
<file-set> that describes a collection of files. The <file-set>
element contains a mandatory 'version' attribute. The first
publication or notification selects an initial value for the
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 12]
Internet-Draft File Event Package in SIP June 2007
'version' attribute of the <file-set> element. Subsequent
publications or notifications, no matter whether they are full or
partial, MUST increment the value of the 'version' attribute by one,
and add it either to the <file-set> or <patch> element, as
appropriate (depending on whether the SIP request contains a full of
partial 'file' document). As a consequence, the counter of the
'version' attribute is shared between <file-set< and <patch>
elements.
The <file-set> element consists of one or more child <file> elements.
The <file-set> element MAY contain other elements and attributes from
different namespaces for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
Each <file> element represents the description data of a file. It
includes an 'id' attribute that contains a unique identifier. The
value of the 'id' attribute MUST be unique within the 'file-metadata'
document.
The <file> element consists of one <identity> element and one or more
<instance> elements. The <file> element MAY also contain other
elements and attributes from different namespaces for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be
ignored.
The <identity> element groups a number of elements that represent the
invariant data of the file, i.e., file metadata that is common across
different instances of the file. For example, the <identity> element
provides a description for the hash or size of a file. On the
contrary, data that is specific to the location of the file (such as
the user's address-of-record who hosts the file, or a human readable
description) are grouped in the <instance> element.
The <identity> element contains an 'id' attribute whose value MUST be
unique within the XML document.
The <identity> element contains zero or one <urn>, <mime-type>,
<size>, and <sha1> elements. The <identity> element MAY also contain
other elements and attributes from different namespaces for the
purposes of extensibility; elements or attributes from unknown
namespaces MUST be ignored.
The <urn> element contains a persistent, location-independent,
resource identifier expressed as a Uniform Resource Name (URN)
[RFC2141] that is allocated to the file and uniquely identifies it.
If present, the value of the <urn> element MUST be formatted
according to the URN syntax specified in RFC 2141 [RFC2141].
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 13]
Internet-Draft File Event Package in SIP June 2007
The <mime-type> element contains the Multipurpose Internet Mail
Extensions (MIME) type of the file. If present, the value of the
<mime-type> element SHOULD contain an IANA registered MIME media type
expressed as type/subtype format.
The <size> element contains the file size in octets.
The <sha1> element contains the results of a hashing operation on the
file. The hashing operation MUST be computed using the US Secure
Hash Algorithm 1 (SHA1) [RFC3174] and MUST be expressed in
hexadecimal format.
One or more <instance> elements can be included in the <file>
element. Each <instance> element provides information that is
related to a particular instance of the file, rather than the file
itself. In publications, EPAs SHOULD include only one <instance>
element per <file> element, and the data SHOULD include only the
local description of the file. In notifications, ESCs MAY include
several <instance> elements per <file> element. This would be the
case when the ESC has acquired such information, for example, through
publications from different EPAs.
Allowing EPAs to provide a description of non-locally stored files
could be maliciously used for creating, e.g., denial of service
attacks.
Each <instance> element contains an 'id' attribute whose value MUST
be unique within the XML document. The <instance> element also
contains one or more <uri> elements, and zero or one <user-aor>,
<user-gruu>, <name>, <description> <iconptr>, <creation-date>,
<modification-date>, <read-date> and <keywords> elements.
Additionally, the <instance> element MAY contain other elements and
attributes from different namespaces for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be
ignored.
The <uri> element contains a location-dependent, typically protocol-
specific file identifier expressed as a Uniform Resource Identifier
(URI) [RFC3986]. If present, the value of the <uri> element MUST be
formatted according to the URN syntax specified in RFC 3986
[RFC3986]. EPAs MUST NOT publish non-local URIs in the <uri>
element, although they MAY publish several URIs for a single file,
e.g., if the file is available through several protocols and URIs.
The <user-aor> provides a container for a SIP, SIPS or similar type
of URI that resolves to the address-of-record of the user where the
file is available. This might be useful when it is not possible to
provide a URI (in the <uri> element) that resolves to the file
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 14]
Internet-Draft File Event Package in SIP June 2007
itself, but instead, there is a URI that resolves to the user that
hosts the file. EPAs MUST NOT include <user-aor> containing
addresses-of-record that point to other users than the one whose file
EPA is publishing. ESCs MUST verify that a <user-aor> received in a
PUBLISH request belongs to the same user who published the request;
this requires the ESC to first authenticate the publisher.
The <user-gruu> provides a Globally Routable User Agent URI (GRUU)
[I-D.ietf-sip-gruu] that points to the SIP instance in the User Agent
where the file is available. This element completes the <user-aor>
by providing an pointer to the SIP instance that is hosting the file.
The <name> element contains the filename.
The <description> element contains a human readable text describing
the file.
The <iconptr> element contains a URI that points to an icon that
represents the file. This is typically applicable to image or video
files.
The <creation-date> element indicates the date and time at which the
file was created.
The <modification-date> element indicates the date and time at which
the file was last modified.
The <read-date> element indicates the date and time at which the file
was last read.
The <keywords> element is a container of keywords associated to the
file. Its main purpose is to assist indexing and search engines.
The <keywords> element contains one or more <keyword> elements
(notice the singular form of the child elements). The <keywords>
element MAY contain other attributes from different namespaces for
the purposes of extensibility; attributes from unknown namespaces
MUST be ignored.
Each <keyword> element contains one word that represents a keyword
associated to the file. A <keyword> element SHOULD NOT contain any
white spaces. If several keywords are to be included, each one
should be included in a separate <keyword> element.
4.2. Partial 'file-metadata' document: patch operations
A partial 'file-metadata' document begins with the root element tag
<patch> that describes a collection of XML patch operations
[I-D.ietf-simple-xml-patch-ops] that are to be applied to a previous
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 15]
Internet-Draft File Event Package in SIP June 2007
version of a full 'file-metadata' document. The <patch> element
contains a mandatory 'version' attribute whose counter is shared with
the 'version' attribute of the <file-set> element. Each new partial
'file-metadata' document MUST increment the 'version' attribute value
by one, with respect the previously sent version. The value of the
'version' attribute can be used to ensure consistent updates as the
recipient of the document can use the 'version' number to properly
order received documents and to ensure that updates have not been
lost.
The <patch> element consists of one or more child <add>, <replace>,
or <remove> elements whose type definitions are included from the XML
Patch Operations [I-D.ietf-simple-xml-patch-ops] identified with the
namespace "urn:ietf:params:xml:schema:xml-patch-ops".
The <patch> element MAY contain other elements and attributes from
different namespaces for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
The <add> element is used to add new content to the 'file-metadata'
document. The details of the <add> element are discussed in the XML
Patch Operations [I-D.ietf-simple-xml-patch-ops].
The <replace> element is used to update content in the 'file-
metadata' document. The details of the <replace> element are
discussed in the XML Patch Operations
[I-D.ietf-simple-xml-patch-ops].
The <remove> element is used to remove content from the 'file-
metadata' document. The details of the <remove> element are
discussed in the XML Patch Operations
[I-D.ietf-simple-xml-patch-ops].
Once all the patch operations have been applied to the previous full
'file-metadata' document, a new full 'file-metadata' document is
created with the same 'version' attribute value, letting a subsequent
partial 'file-metadata' document operate on the last full document.
4.3. XML Schema
Implementations according to this specification MUST comply to the
following XML schema that defines the constraints of the 'file-
metadata' document:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:file"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:file"
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 16]
Internet-Draft File Event Package in SIP June 2007
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition to provide information about
available files at a host.
</xs:documentation>
</xs:annotation>
<!-- include xml-patch-ops type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:xml-patch-ops"/>
<xs:element name="file-set" type="file-setType"/>
<xs:element name="patch" type="patchType"/>
<xs:complexType name="file-setType">
<xs:sequence>
<xs:element name="file" type="fileType"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:unsignedInt"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="fileType">
<xs:sequence>
<xs:element name="identity" type="identityType" />
<xs:element name="instance" type="instanceType"
maxOccurs="unbounded" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="identityType">
<xs:sequence>
<xs:element name="urn" type="xs:anyURI" minOccurs="0"/>
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 17]
Internet-Draft File Event Package in SIP June 2007
<xs:element name="mime-type" type="xs:string" minOccurs="0"/>
<xs:element name="size" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="sha1" type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="instanceType">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="user-aor" type="xs:anyURI" minOccurs="0"/>
<xs:element name="user-gruu" type="xs:anyURI" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:element name="iconptr" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="creation-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="modification-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="read-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="keywords" type="keywordsType"
minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="keywordsType">
<xs:sequence>
<xs:element name="keyword" type="xs:token"
maxOccurs="unbounded" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="patchType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 18]
Internet-Draft File Event Package in SIP June 2007
<xs:element name="add" type="add"/>
<xs:element name="replace" type="replace"/>
<xs:element name="remove" type="remove"/>
</xs:choice>
<xs:attribute name="version" type="xs:unsignedInt"/>
</xs:complexType>
</xs:schema>
Figure 1: 'file-metadata' document XML schema
4.4. Examples
4.4.1. Example of a full 'file-document' document in a publication
Figure 2 is an example of a 'file-metadata' document that can be
present in a PUBLISH request:
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 19]
Internet-Draft File Event Package in SIP June 2007
<?xml version="1.0" encoding="UTF-8"?>
<file-set xmlns="urn:ietf:params:xml:ns:file"
version="123">
<file id="id38sh12jd">
<identity id="id9d8c9">
<mime-type>image/jpeg</mime-type>
<size>230432</size>
<sha1>72245FE8653DDAF371362F86D471913EE4A2CE2E</sha1>
<identity>
<instance id="idc989c00">
<name>coolpic.jpg</name>
<description>
This is my latest cool picture from my summer vacation
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-aor>sip:miguel.an.garcia@example.com</user-aor>
<creation-date>2006-05-09T09:30:47+03:00</creation-date>
<modification-date>
2006-05-09T10:24:34+03:00
</modification-date>
<read-date>2006-05-10T14:24:32+03:00</read-date>
<icon-ptr>http://www.example.com/coolpic-icon.jpg</icon-ptr>
<keywords>
<keyword>summer</keyword>
<keyword>vacation</keyword>
</keywords>
</instance>
</file>
</file-set>
Figure 2: Example of a full 'file-metadtaa' document used in a
publication
The example in Figure 2 shows a full 'file-metadata' document that an
EPA provides to the ESC. The example contains the description of a
single file: an image file. The EPA provides description of the file
(an <file> element) that contains the static data of the file
included in the <identity> element and the variable data (that
depends on the actual instance of the file) in the <instance>
element. The <identity> element contains a number of characteristics
of the file that would not change across different instances, such as
the MIME type, the size, and the hash of the file. On the contrary,
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 20]
Internet-Draft File Event Package in SIP June 2007
the <instance> element contains the data related to the particular
instance of the file, such as the name assigned by the user to the
file, a human readable description, the GRUU that points to the SIP
User Agent where the file is stored, the creation, modification, and
read dates, etc.
4.4.2. Example of a partial 'file-metadata' document used in a
publication
Figure 3 is an example of a partial 'file-metadata' document that can
be present in a PUBLISH request:
<?xml version="1.0" encoding="UTF-8"?>
<patch xmlns="urn:ietf:params:xml:ns:file"
version="124">
<add sel="file-set">
<file id="b390d92">
<identity id="mm8b8d">
<mime-type>message/msrp</mime-type>
</identity>
<instance id="hhdu23">
<name>IETFers chat room</name>
<description>
Dedicated chat room for IETF discussions
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-aor>sip:miguel.an.garcia@example.com</user-aor>
</instance>
</file>
</add>
</patch>
Figure 3: Example of a partial 'file-metadata' document used in a
publication
The example in Figure 3 shows an example of a partial 'file-metadata'
document that a EPA is sending to an ESC. The document contains the
patch operations that adds one more new files to the existing list.
The 'version' attribute of the <patch> element is incremented by one
with respect the 'version' attribute of the <file-set> element of the
full 'file-metadata' document in Figure 2.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 21]
Internet-Draft File Event Package in SIP June 2007
4.4.3. Example of a full 'file-metadata' document used in a
notification
Figure 4 is an example of a full 'file-metadata' document that can be
present in a NOTIFY request:
<?xml version="1.0" encoding="UTF-8"?>
<file-set xmlns="urn:ietf:params:xml:ns:file"
version="312">
<file id="nkcdn0">
<identity id="aa77d7">
<mime-type>audio/3gpp</mime-type>
<size>34987</size>
<sha1>E05DA01A590E31F6E3100AD7BEC39C63464A1CD0</sha1>
<identity>
<instance id="idea1dof">
<name>recording-1.3gp</name>
<description>
Bob's speech at a conference
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-aor>sip:miguel.an.garcia@example.com</user-aor>
<creation-date>2006-05-01T01:30:47+03:00</creation-date>
<modification-date>
2006-05-02T02:24:34+03:00
</modification-date>
<read-date>2006-05-03T03:24:32+03:00</read-date>
<keywords>
<keyword>Bob</keyword>
<keyword>speech</keyword>
</keywords>
</instance>
<instance id="kxf-312">
<name>bob-speech.3gp</name>
<description>
Bob talking about nanotechnology
</description>
<user-gruu>
sip:alice@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-4de9-00a2ac4e398a
</user-gruu>
<user-aor>sip:alice@example.com</user-aor>
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 22]
Internet-Draft File Event Package in SIP June 2007
<creation-date>2006-05-01T01:30:47+03:00</creation-date>
<modification-date>
2006-05-02T02:24:34+03:00
</modification-date>
<read-date>2006-05-24T05:12:07+02:00</read-date>
<keywords>
<keyword>Bob</keyword>
<keyword>nanotechnology</keyword>
</keywords>
</instance>
</file>
</file-set>
Figure 4: Example of a full 'file-metadata' document used in
notifications
The example in Figure 4 shows an example of a full 'file-metadata'
document that a ESC is sending to a subscriber. The document
describes a single audio file, which is available at two difference
hosts, thus, the 'file-metadata' document starts with a <file-set>
element that contains the description of the file in the <file>
element. The <file> element contains an <identity> element and two
<instance> elements. The <identity> element contains descriptive
invariant data of the file. Each of the <instance> elements contains
data related to the particular instance where the file is available.
4.4.4. Example of a partial 'file-metadata' document used in a
notification
Figure 5 is an example of a partial 'file-metadata' document that can
be present in a NOTIFY request:
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 23]
Internet-Draft File Event Package in SIP June 2007
<?xml version="1.0" encoding="UTF-8"?>
<patch xmlns="urn:ietf:params:xml:ns:file"
version="313">
<add sel="file-set/file[@id='nkcdn0']">
<instance id="ak6v3d">
<name>nanotalk.3gp</name>
<description>
Nanotechnology speech
</description>
<user-gruu>
sip:bob@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-5d3a-bbc333431122
</user-gruu>
<user-aor>sip:bob@example.com</user-aor>
</instance>
</add>
<replace sel="id=('idea1dof')/read-date/text()"
>2006-06-07T17:26:04+03:00</replace>
</patch>
Figure 5: Example of a partial 'file-metadata' document used in a
notification
Figure 5 contains a number of XML patch operations to be applied to
the full 'file-metadata' document included in Figure 4. The document
in Figure 5 starts with a <patch> root element, indicating that it is
a partial 'file-metadata' document. The 'version' attribute is
incremented by one with respect the 'version' attribute of the <file-
set> element of the full 'file-metadata' document of Figure 4.
The document contains an <add> element that first selects the <file>
element whose 'id' attribute is set to "nkcdn0". Then it appends, at
then of the existing child elements, a new <instance> element that
describes the availability of the same file at a different endpoint.
The <replace> element selects the <read-date> element of the
<instance> whose 'id' attribute is set to "idea1dof" and replaces the
value with a new date and time.
Note: the 'sel' attribute of the <replace> element in Figure 5 is
split in two lines due to formatting restrictions. It will appear
as a single line in XML documents.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 24]
Internet-Draft File Event Package in SIP June 2007
5. Security Considerations
TBD
6. Acknowledgements
The authors want to thank Jari Urpalainen for providing extensive
guidance with the XML schema definition and support for partial
publication and notification. Nicklas Beijar and Juuso Lehtinen held
fruitful discussions with the authors that lead to the design of this
event package. Pekka Kuure and Arto Leppisaari provided helpful
comments during the initial review.
7. IANA Considerations
7.1. Registration of the 'file' Event Package
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [RFC3265]. The following
is the information required for such a registration:
Package Name: file
Package or Template-Package: This is a package.
Published Document: RFC XXX [Replace by the RFC number of this
specification].
Person to Contact: Miguel A. Garcia-Martin, miguel.garcia@nsn.com
7.2. Registration of the "application/file+xml" MIME type
To: ietf-types@iana.org
Subject: Registration of MIME media type application/file+xml
MIME media type name: application
MIME subtype name: file+xml
Required parameters: (none)
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 25]
Internet-Draft File Event Package in SIP June 2007
Optional parameters: charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 [RFC3629].
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], Section 3.2.
Security considerations: TBD
Interoperability considerations: none
Published specification: RFC XXXX (this document).
Applications which use this media type: publication and share of
file availability.
Additional information: none
Person & email address to contact for further information: Miguel
A. Garcia-Martin, miguel.garcia@nsn.com
Intended usage: Limited use, file sharing for SIP user agents.
Author/Change controller: IETF, SIPPING Worknig Group.
Other information: This media type is a specialization of
application/xml RFC 3023 [RFC3023], and many of the considerations
described there also apply to application/file+xml.
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.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 26]
Internet-Draft File Event Package in SIP June 2007
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[W3C.REC-xml-20001006]
Paoli, J., Maler, E., Sperberg-McQueen, C., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
World Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-13 (work in progress),
April 2007.
[I-D.ietf-simple-xml-patch-ops]
Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-02 (work in
progress), March 2006.
8.2. Informative References
[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.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 27]
Internet-Draft File Event Package in SIP June 2007
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745,
February 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 & Matuszewski Expires December 10, 2007 [Page 28]
Internet-Draft File Event Package in SIP 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 & Matuszewski Expires December 10, 2007 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 09:45:11 |