One document matched: draft-garcia-sipping-file-event-package-01.txt
Differences from 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: May 19, 2008 Nokia
November 16, 2007
A Session Initiation Protocol (SIP) Event Package and Data Format for
Describing Files
draft-garcia-sipping-file-event-package-01
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 May 19, 2008.
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. The event package reuses the eXtended
Mark-up Language (XML) 'file-metadata' document to provide file
descriptions. This event package also allows SIP endpoints to
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 1]
Internet-Draft File Event Package in SIP November 2007
subscribe to changes in the availability of files, or perform
searches for the availability and location of a given file. Support
for partial notifications and publications is also accomplished by
using XML patch operations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The 'file' Event Package . . . . . . . . . . . . . . . . . . . 4
3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5
3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5
3.4. Subscription duration . . . . . . . . . . . . . . . . . . 5
3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 6
3.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 6
3.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7
3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7
3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8
3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9
3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
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. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. Registration of the 'file' Event Package . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 2]
Internet-Draft File Event Package in SIP November 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
reuse the 'file-metadata' document format specified in the XML Data
Format for describing files [I-D.garcia-app-area-file-data-format].
All together, they allow 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.
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 3]
Internet-Draft File Event Package in SIP November 2007
In the file descriptor, sometimes the URI points to the file itself
itself (such as an HTTP URI that points to an image file). In other
cases the URI merely resolves to a host where the content is
available (for example, the SIP URI of a camera phone that stores
images).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, 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.
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 4]
Internet-Draft File Event Package in SIP November 2007
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.
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-
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 5]
Internet-Draft File Event Package in SIP November 2007
metadata' document, specified in the XML Data Format for describing
files [I-D.garcia-app-area-file-data-format]. A 'file-metadata'
document can be expressed as a full or partial document. An ESC can
receive 'file-metadata' documents from different EPAs or other
sources. The ESC applies a composition policy, and composes a 'file-
metadata' document that contains all the available known files to the
EPA. If the ESC is not able to resolve a conflict, due to
contradictory information provided by two different EPAs, the ESC
provides a comprehensive information for that file, so that the
subscriber can resolve the conflict.
All subscribers and notifiers of 'file' event package MUST support
the "application/file+xml" data format described in XML Data Format
for describing files [I-D.garcia-app-area-file-data-format]. 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.
When composing a 'file-metadata' document, the ESC MAY include
several <instance> elements per <file> element. This would be the
case when the ESC has acquired information concerning the same file,
for example, through publications from different EPAs.
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.
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 6]
Internet-Draft File Event Package in SIP November 2007
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
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 or any other
type indicated by the subscriber in the Accept header field of the
SUBSCRIBE request. The times at which the NOTIFY is sent to a
particular subscriber, and the contents of the body within that
notification, are subject to any rules specified by the authorization
policy that governs the subscription, but typically will contain an
indication of those known files for which a change has occurred.
Since 'file-metadata' documents can contain full or partial state,
the first 'file-metadata' document that a notifier sends to
subscriber MUST contain be a full 'file-metadata' document.
Subsequent documents sent to the same subscriber MAY contain full
'file-metadata' documents or partial 'file-metadata' documents (the
XML Data Format for describing files
[I-D.garcia-app-area-file-data-format] 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
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 7]
Internet-Draft File Event Package in SIP November 2007
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
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 it contains a partial 'file-metadata' document that
updates a previously received 'file-metadata' document (see the XML
Data Format for describing files
[I-D.garcia-app-area-file-data-format] for more details).
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 8]
Internet-Draft File Event Package in SIP November 2007
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.
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.
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 9]
Internet-Draft File Event Package in SIP November 2007
3.12. Examples
Examples of 'file-metadata' documents are provided in the XML Data
Format for describing files [I-D.garcia-app-area-file-data-format].
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.
In this event package, the body of a PUBLISH request contains a
'file-metadata' document (see the XML Data Format for describing
files [I-D.garcia-app-area-file-data-format]). 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 the XML Data Format for describing files
[I-D.garcia-app-area-file-data-format]. and MAY support other
formats.
When the EPA is composing a 'file-metadata' document, the EPA SHOULD
include only one <instance> element per <file> element, and the data
SHOULD include only the local description of the file.
Allowing EPAs to provide a description of non-locally stored files
could be maliciously used for creating, e.g., denial of service
attacks.
EPAs MUST NOT publish non-local URIs in the <uri> element, although
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 10]
Internet-Draft File Event Package in SIP November 2007
they MAY publish several URIs for a single file, e.g., if the file is
available through several protocols and URIs.
EPAs MUST NOT include <user-aor> containing addresses-of-record that
point to other users than the one whose file EPA is publishing. ESCs
MUST verify that a <user-aor> element received in a PUBLISH request
belongs to the same user who published the request; this requires the
ESC to first authenticate the publisher.
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 May 19, 2008 [Page 11]
Internet-Draft File Event Package in SIP November 2007
4. Security Considerations
TBD
5. Acknowledgements
The authors would like to thank Nicklas Beijar and Juuso Lehtinen
held fruitful discussions with the authors that lead to the design of
this event package. Pekka Kuure and Arto Leppisaari provided helpful
comments during the initial review.
6. IANA Considerations
6.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. References
7.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.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 12]
Internet-Draft File Event Package in SIP November 2007
RFC 3851, July 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[I-D.garcia-app-area-file-data-format]
Garcia-Martin, M. and M. Matuszewski, "An Extensible Data
Format (XML) for Describing Files",
draft-garcia-app-area-file-data-format-00 (work in
progress), November 2007.
7.2. Informative References
[I-D.ietf-mmusic-file-transfer-mech]
Garcia-Martin, M., Isomaki, M., Camarillo, G., and S.
Loreto, "A Session Description Protocol (SDP) Offer/Answer
Mechanism to Enable File Transfer",
draft-ietf-mmusic-file-transfer-mech-04 (work in
progress), October 2007.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[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
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 13]
Internet-Draft File Event Package in SIP November 2007
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Garcia-Martin & Matuszewski Expires May 19, 2008 [Page 14]
Internet-Draft File Event Package in SIP November 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 May 19, 2008 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 06:09:56 |