idnits 2.17.1 draft-garcia-sipping-file-event-package-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-04 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia-Martin 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track M. Matuszewski 5 Expires: May 19, 2008 Nokia 6 November 16, 2007 8 A Session Initiation Protocol (SIP) Event Package and Data Format for 9 Describing Files 10 draft-garcia-sipping-file-event-package-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies the format and semantics associated to a 44 'file' event package that allows SIP endpoints to publish the 45 availability of files. A file can be, for example, images, video 46 files, audio files, etc. The event package reuses the eXtended 47 Mark-up Language (XML) 'file-metadata' document to provide file 48 descriptions. This event package also allows SIP endpoints to 49 subscribe to changes in the availability of files, or perform 50 searches for the availability and location of a given file. Support 51 for partial notifications and publications is also accomplished by 52 using XML patch operations. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The 'file' Event Package . . . . . . . . . . . . . . . . . . . 4 59 3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5 61 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Subscription duration . . . . . . . . . . . . . . . . . . 5 63 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5 64 3.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 6 65 3.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 6 66 3.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7 67 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 68 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 69 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9 70 3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 71 3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 10 74 3.14. PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 10 75 3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 11 76 3.16. Multiple Sources for Event State . . . . . . . . . . . . . 11 77 3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 11 78 3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 11 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. Registration of the 'file' Event Package . . . . . . . . . 12 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 Intellectual Property and Copyright Statements . . . . . . . . . . 15 89 1. Introduction 91 There are scenarios where a SIP endpoint has a number of available 92 files that can be offered for public disposal or for a limited number 93 of authorized users. One of these cases is, for example, when Alice 94 takes some pictures with her camera phone and she wants to share them 95 within a community. This requires a mechanism that allows Alice to 96 describe the files she wants to share. 98 In another scenario, Alice might be interested in finding out the 99 availability of a given file, defined by a set of parameters. Think, 100 for example, of Alice trying to find pictures of the bowling 101 tournament that took place recently in her home town. This implies a 102 mechanism whereby Alice can perform searches of available files. The 103 user who performs the search identifies one or more aspects of the 104 file she is searching, but probably she is not able to provide a full 105 description of the file. 107 SIP [RFC3261] provides an extensible event mechanism [RFC3265] that 108 is suitable for our needs. We enable the above scenarios by defining 109 a SIP event package for file metadata publication and search. We 110 reuse the 'file-metadata' document format specified in the XML Data 111 Format for describing files [I-D.garcia-app-area-file-data-format]. 112 All together, they allow an Event Publication Agent (EPA) to provide 113 a description of locally available files in a PUBLISH request 114 [RFC3903]. In a community, there can be an Event State Compositor 115 that aggregates shared files available at different endpoints. The 116 Event State Compositor (ESC) that receives the PUBLISH request 117 processes 'file-metadata' documents according to a well defined 118 strategy (which is outside the scope of this document). For example, 119 the ESC can be a centralized intermediary facilitator for a given 120 community, or it can be a super-node of a SIP Peer-to-Peer (P2P) 121 network. 123 A user that searches for one or more files issues a SUBSCRIBE request 124 (either a subscription or a fetch of state, see RFC 3265 [RFC3265]) 125 to the 'file' event package. Because a subscription to all of the 126 files published in the community is likely to contain a large amount 127 of data, the subscriber will typically attach a filter [RFC4661] that 128 describes the files under search. This will result in the generation 129 of one or more NOTIFY requests that contains the searched items. 130 Once the information on files is retrieved, the subscriber can use 131 any suitable mechanism (such as the one defined in "Session 132 Description Protocol (SDP) Offer/Answer Mechanism to Enable File 133 Transfer" [I-D.ietf-mmusic-file-transfer-mech]) to actually download 134 the file. Such file transfer mechanisms are outside the scope of 135 this memo. 137 In the file descriptor, sometimes the URI points to the file itself 138 itself (such as an HTTP URI that points to an image file). In other 139 cases the URI merely resolves to a host where the content is 140 available (for example, the SIP URI of a camera phone that stores 141 images). 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in BCP 14, RFC 2119 148 [RFC2119] and indicate requirement levels for compliant 149 implementations. 151 3. The 'file' Event Package 153 RFC 3265 [RFC3265] defines a SIP extension for subscribing to, and 154 receiving notifications of changes (events) in the state of remote 155 nodes. It leaves the definition of many aspects of these events to 156 concrete extensions, known as event packages. This document 157 qualifies as an event package. This section fills in the information 158 required for all event packages by RFC 3265 [RFC3265]. 160 Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP 161 User Agents to publish event state. According to RFC 3903 [RFC3903] 162 any event package intended to be used in conjunction with the SIP 163 PUBLISH method has to include a considerations section. This section 164 also fills the information for all event packages to be used with 165 PUBLISH requests. 167 We define a new 'file' event package. Event Publication Agents (EPA) 168 use PUBLISH requests to inform an Event State Compositor (ESC) of 169 changes in the 'file' event package. The ESC, acting as a notifier, 170 notifies subscribers to the 'file' event package when changes occur. 172 3.1. Package Name 174 The name of this package is 'file'. As specified in RFC 3265 175 [RFC3265], this value appears in the Event header field present in 176 SUBSCRIBE and NOTIFY requests. As specified in the RFC 3903 177 [RFC3903], this value appears as well in the Event header field 178 present in PUBLISH requests. 180 3.2. Event Package Parameters 182 RFC 3265 [RFC3265] allows event packages to define additional 183 parameters carried in the Event header field. This event package, 184 'file', does not define additional parameters. 186 3.3. SUBSCRIBE Bodies 188 According to RFC 3265 [RFC3265], a SUBSCRIBE request can contain a 189 body. The purpose of the body depends on its type. Subscriptions to 190 the 'file' event package MAY contain a filter body according to the 191 format specified in [RFC4661]. Filters are used to reduce the number 192 of results during searches. 194 3.4. Subscription duration 196 From the functional point of view, there are two kinds of 197 subscriptions to the 'file' even package. In one, the user may want 198 to either perform a single search operation on the existing files. 199 In the other, the user may want to monitor the changes in the state 200 information of files. These functionalities can be controlled by the 201 duration of the subscription. 203 A search on existing files can be implemented with a single fetch 204 operation (where the Expires header field is set to zero) or by a 205 subscription of a short duration (typically on the order of a few 206 minutes). The other functionality, where a user wants to monitor the 207 changes of a state, is typically implemented as a lengthy 208 subscription, on the order of hours, as the user needs to be notified 209 whenever a change in the file has occurred. 211 Due to the lack of congruence in the two types of subscriptions, it 212 is hard to select a default expiration value. We have decided to 213 select a mean default value that accommodate both types of 214 subscriptions: 1800 seconds. As per RFC 3265 [RFC3265], the 215 subscriber MAY specify an alternate expiration in the Expires header 216 field. It is RECOMMENDED that UACs always include an explicit 217 Expires header field with the desired subscription value. 219 3.5. NOTIFY Bodies 221 As described in RFC 3265 [RFC3265], the NOTIFY message can contain a 222 body describing the state of the subscribed resources. This body is 223 either in a format listed in the Accept header field of the SUBSCRIBE 224 request, or in a package-specific default format, if the Accept 225 header field was omitted from the SUBSCRIBE request. 227 In this event package, the body of the notification contains a 'file- 228 metadata' document, specified in the XML Data Format for describing 229 files [I-D.garcia-app-area-file-data-format]. A 'file-metadata' 230 document can be expressed as a full or partial document. An ESC can 231 receive 'file-metadata' documents from different EPAs or other 232 sources. The ESC applies a composition policy, and composes a 'file- 233 metadata' document that contains all the available known files to the 234 EPA. If the ESC is not able to resolve a conflict, due to 235 contradictory information provided by two different EPAs, the ESC 236 provides a comprehensive information for that file, so that the 237 subscriber can resolve the conflict. 239 All subscribers and notifiers of 'file' event package MUST support 240 the "application/file+xml" data format described in XML Data Format 241 for describing files [I-D.garcia-app-area-file-data-format]. The 242 SUBSCRIBE request MAY contain an Accept header field. If no such 243 header field is present, it has a default value of "application/ 244 file+xml" (assuming that the Event header field contains a value of 245 'file'). If the Accept header field is present, it MUST include 246 "application/file+xml", and MAY include any other types capable of 247 representing 'file-metadata' documents. 249 When composing a 'file-metadata' document, the ESC MAY include 250 several elements per element. This would be the 251 case when the ESC has acquired information concerning the same file, 252 for example, through publications from different EPAs. 254 3.6. Notifier processing of SUBSCRIBE requests 256 The contents of a 'file-metadata' document can contain sensitive 257 information that can reveal some privacy information. For example, 258 it can contain a list of valuable files and the address (SIP URI) of 259 the SIP User Agent where those are stored. While this information 260 itself is not very useful, it can be used by malicious agents, e.g., 261 to mount an attack to avoid other users to retrieve such a file. 262 Therefore, 'file-metadata' documents MUST only be sent to authorized 263 subscribers. In order to determine if a subscription originates in 264 an authorized user, the user MUST be authenticated as described in 265 Section 3.6.1 and then he MUST be authorized to be a subscriber as 266 described in Section 3.6.2. 268 3.6.1. Authentication 270 Notifiers SHOULD authenticate all subscription requests. This 271 authentication can be done using any of the mechanisms defined in RFC 272 3261 [RFC3261] and other authentication extensions. 274 3.6.2. Authorization 276 Once authenticated, the notifier makes an authorization decision. A 277 notifier MUST NOT accept a subscription unless authorization has been 278 provided by the user. The means by which authorization are provided 279 are outside the scope of this document. Authorization may have been 280 provided ahead of time through access lists, perhaps specified in a 281 web page, or provided with the Common Policy Framework [RFC4745]. 283 3.7. Notifier Generation of NOTIFY Requests 285 RFC 3265 [RFC3265] details the formatting and structure of NOTIFY 286 messages. However, packages are mandated to provide detailed 287 information on when to send a NOTIFY request, how to compute the 288 state of the resource, how to generate neutral or fake state 289 information, and whether state information is complete or partial. 290 This section describes those details for the 'file' event package. 292 A notifier MAY send a NOTIFY at any time. The NOTIFY request MAY 293 contain a body containing a 'file-metadata' document or any other 294 type indicated by the subscriber in the Accept header field of the 295 SUBSCRIBE request. The times at which the NOTIFY is sent to a 296 particular subscriber, and the contents of the body within that 297 notification, are subject to any rules specified by the authorization 298 policy that governs the subscription, but typically will contain an 299 indication of those known files for which a change has occurred. 301 Since 'file-metadata' documents can contain full or partial state, 302 the first 'file-metadata' document that a notifier sends to 303 subscriber MUST contain be a full 'file-metadata' document. 304 Subsequent documents sent to the same subscriber MAY contain full 305 'file-metadata' documents or partial 'file-metadata' documents (the 306 XML Data Format for describing files 307 [I-D.garcia-app-area-file-data-format] provides further discussion 308 about full and partial 'file-metadata' documents). 310 In the case of a pending subscription, when final authorization is 311 determined, a NOTIFY request can be sent. If the result of the 312 authorization decision was success, a NOTIFY SHOULD be sent and 313 SHOULD contain a full 'file-metadata' document with the current state 314 of the files known by the notifier at that moment. If the 315 subscription is rejected, a NOTIFY MAY be sent. As described in RFC 316 3265 [RFC3265], the Subscription-State header field indicates the 317 state of the subscription. 319 Frequently, the notifier will have a incomplete view of the available 320 files described in a 'file-metadata' document. For the duration of 321 the subscription, the notifier can be running searches for the 322 availability of the searched files. When new state information is 323 made available to the notifier, the notifier SHOULD provide this 324 information to the subscribers, typically as notifications that 325 contain a partial 'file-metadata' document. 327 The body of the NOTIFY MUST be sent using one of the types listed in 328 the Accept header field in the most recent SUBSCRIBE request, or 329 using the type "application/file+xml" if no Accept header field was 330 present. 332 Notifiers will typically act as Event State Compositors (ESC) and 333 thus, will learn the 'file' event state via PUBLISH requests sent 334 from the user's Event Publication Agent (EPA) when the user makes one 335 or more files available or via subscriptions passed further to other 336 ESCs. 338 For reasons of privacy, it will frequently be necessary to encrypt 339 the contents of the notifications. This can be accomplished using 340 S/MIME [RFC3851]. The encryption can be performed using the key of 341 the subscriber as identified in the From field of the SUBSCRIBE 342 request. Similarly, integrity of the notifications is important to 343 subscribers. As such, the contents of the notifications MAY provide 344 authentication and message integrity using S/MIME [RFC3851]. This 345 will require the notifier to sign the content of the notification 346 with the notifier's private key. 348 3.8. Subscriber Processing of NOTIFY Requests 350 RFC 3265 [RFC3265] leaves it to event packages to describe the 351 process followed by the subscriber upon receipt of a NOTIFY request, 352 including any logic required to form a coherent resource state. 354 In this specification, each NOTIFY request contains either no 'file- 355 metadata' document, a full 'file-metadata' document representing 356 files which are available at one or more SIP User Agents, or a 357 partial 'file-metadata' document that represent changes with respect 358 a previously notified 'file-metadata' document. Within a dialog, 359 when a 'file-metadata' document is received in a NOTIFY request with 360 a higher CSeq header field value than a previously received NOTIFY, 361 and when the 'version' attribute value of the element is 362 increased by one it contains a partial 'file-metadata' document that 363 updates a previously received 'file-metadata' document (see the XML 364 Data Format for describing files 365 [I-D.garcia-app-area-file-data-format] for more details). 367 3.9. Handling of Forked Requests 369 RFC 3265 [RFC3265] requires each package to describe handling of 370 forked SUBSCRIBE requests. 372 This specification allows several dialogs to be constructed as a 373 result of emitting an initial SUBSCRIBE request, i.e., in cases where 374 the SUBSCRIBE request forked to several notifiers. In this case, the 375 subscriber will keep several simultaneous dialogs. The subscriber 376 SHOULD merge the several 'file-metadata' documents received in NOTIFY 377 requests. It might be possible that new elements are received 378 in forked 'file-metadata' documents, or it might be possible that 379 existing elements are updated with new information (e.g., a 380 new element). In both cases the merge should provide a 381 logical OR operation of all the available information such as new 382 entries and added information to existing entries. 384 3.10. Rate of Notifications 386 RFC 3265 [RFC3265] requires each package to specify the maximum rate 387 at which notifications can be sent. 389 Notifiers of 'file-metadata' documents SHOULD NOT generate 390 notifications for a single user at a higher rate than once every 391 second. 393 3.11. State Agents 395 RFC 3265 [RFC3265] requires each package to consider the role of 396 state agents in the package, and if they are used, to specify how 397 authentication and authorization are done. 399 This specification allows state agents to be located in the network. 400 A given file might be available at different SIP User Agents in the 401 network. ESCs can act as state agents by compiling and aggregating 402 state towards, e.g., subscribers, other networks or communities. 403 State agents MUST use any of the mechanism specified in RFC 3261 404 [RFC3261] or any other SIP extension to authenticate and authorize 405 users prior to accepting publications. 407 If the state agent acts as an aggregator, the state agent SHOULD 408 aggregate all the information related to the same available file. In 409 this case, it is expected that, because the same file is available in 410 different endpoints, there might be different URIs for a given 411 available file. 413 3.12. Examples 415 Examples of 'file-metadata' documents are provided in the XML Data 416 Format for describing files [I-D.garcia-app-area-file-data-format]. 418 3.13. Use of URIs to Retrieve State 420 RFC 3265 [RFC3265] allows packages to use URIs to retrieve large 421 state documents. 423 A 'file-metadata' document can be of any arbitrary length, and can 424 also become too large to be reasonably sent in a SIP request. To 425 avoid the burden of transmitting large documents through SIP proxies 426 and to avoid potential congestion scenarios, it is possible that the 427 notifier instead includes a URI that points to the contents, rather 428 than the actual contents. For example, the notifier can include an 429 HTTP [RFC2616] URI that points to the notifier itself. Since HTTP 430 requests are transferred via a congestion controlled protocol (such 431 as TCP [RFC0793]), the inclusion of a URI to retrieve state mitigates 432 the problem of large 'file-metadata' documents. 434 3.14. PUBLISH bodies 436 RFC 3903 [RFC3903] requires event packages to define the content 437 types expected in PUBLISH requests. 439 In this event package, the body of a PUBLISH request contains a 440 'file-metadata' document (see the XML Data Format for describing 441 files [I-D.garcia-app-area-file-data-format]). This 'file-metadata' 442 document describes the availability of one or more files (typically, 443 but not necessarily, stored at the EPA). EPAs SHOULD only publish 444 the description of locally available files, i.e., the URI of the file 445 SHOULD resolve to the EPA itself. 447 All EPAs and ESCs MUST support the "application/file+xml" data format 448 described in the XML Data Format for describing files 449 [I-D.garcia-app-area-file-data-format]. and MAY support other 450 formats. 452 When the EPA is composing a 'file-metadata' document, the EPA SHOULD 453 include only one element per element, and the data 454 SHOULD include only the local description of the file. 456 Allowing EPAs to provide a description of non-locally stored files 457 could be maliciously used for creating, e.g., denial of service 458 attacks. 460 EPAs MUST NOT publish non-local URIs in the element, although 461 they MAY publish several URIs for a single file, e.g., if the file is 462 available through several protocols and URIs. 464 EPAs MUST NOT include containing addresses-of-record that 465 point to other users than the one whose file EPA is publishing. ESCs 466 MUST verify that a element received in a PUBLISH request 467 belongs to the same user who published the request; this requires the 468 ESC to first authenticate the publisher. 470 3.15. PUBLISH Response Bodies 472 This specification does not associate semantics to a body in a 473 PUBLISH response. 475 3.16. Multiple Sources for Event State 477 RFC 3903 [RFC3903] requires event packages to specify whether 478 multiple sources can contribute to the event state view at the ESC. 480 This event package allows different EPAs to publish the availability 481 of the same file. For the same file, each EPA publishes data that is 482 invariant with the instance of the file, and data that is specific 483 with each instance. The ESC SHOULD merge the data pertaining to the 484 same file according to a composition policy. This policy can, e.g., 485 list all the difference instances where each file is available. 487 3.17. Event State Segmentation 489 RFC 3903 [RFC3903] defines segments within a state document. Each 490 segment is defined as one of potentially many identifiable sections 491 in the published event state. 493 In this 'file' event package, each element composes a segment. 495 3.18. Rate of Publication 497 RFC 3903 [RFC3903] allows event packages to define their own rate of 498 publication. 500 There are no rate limiting recommendations for 'file' publication. 501 It is expected that new files are added at the time of creation 502 (e.g., a new image is taken with a camera phone), and that they are 503 not changed often. Thus, a typical rate of publication does not 504 exist and there is no foreseen need to limit the rate of 505 publications. 507 4. Security Considerations 509 TBD 511 5. Acknowledgements 513 The authors would like to thank Nicklas Beijar and Juuso Lehtinen 514 held fruitful discussions with the authors that lead to the design of 515 this event package. Pekka Kuure and Arto Leppisaari provided helpful 516 comments during the initial review. 518 6. IANA Considerations 520 6.1. Registration of the 'file' Event Package 522 This specification registers an event package, based on the 523 registration procedures defined in RFC 3265 [RFC3265]. The following 524 is the information required for such a registration: 526 Package Name: file 528 Package or Template-Package: This is a package. 530 Published Document: RFC XXX [Replace by the RFC number of this 531 specification]. 533 Person to Contact: Miguel A. Garcia-Martin, miguel.garcia@nsn.com 535 7. References 537 7.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 543 A., Peterson, J., Sparks, R., Handley, M., and E. 544 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 545 June 2002. 547 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 548 Event Notification", RFC 3265, June 2002. 550 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 551 Extensions (S/MIME) Version 3.1 Message Specification", 552 RFC 3851, July 2004. 554 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 555 for Event State Publication", RFC 3903, October 2004. 557 [I-D.garcia-app-area-file-data-format] 558 Garcia-Martin, M. and M. Matuszewski, "An Extensible Data 559 Format (XML) for Describing Files", 560 draft-garcia-app-area-file-data-format-00 (work in 561 progress), November 2007. 563 7.2. Informative References 565 [I-D.ietf-mmusic-file-transfer-mech] 566 Garcia-Martin, M., Isomaki, M., Camarillo, G., and S. 567 Loreto, "A Session Description Protocol (SDP) Offer/Answer 568 Mechanism to Enable File Transfer", 569 draft-ietf-mmusic-file-transfer-mech-04 (work in 570 progress), October 2007. 572 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 573 RFC 793, September 1981. 575 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 576 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 577 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 579 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 580 Requena, "An Extensible Markup Language (XML)-Based Format 581 for Event Notification Filtering", RFC 4661, 582 September 2006. 584 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 585 Polk, J., and J. Rosenberg, "Common Policy: A Document 586 Format for Expressing Privacy Preferences", RFC 4745, 587 February 2007. 589 Authors' Addresses 591 Miguel A. Garcia-Martin 592 Nokia Siemens Networks 593 P.O.Box 6 594 Nokia Siemens Networks, FIN 02022 595 Finland 597 Email: miguel.garcia@nsn.com 598 Marcin Matuszewski 599 Nokia 600 P.O.Box 407 601 NOKIA GROUP, FIN 00045 602 Finland 604 Email: marcin.matuszewski@nokia.com 606 Full Copyright Statement 608 Copyright (C) The IETF Trust (2007). 610 This document is subject to the rights, licenses and restrictions 611 contained in BCP 78, and except as set forth therein, the authors 612 retain all their rights. 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Intellectual Property 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org. 646 Acknowledgment 648 Funding for the RFC Editor function is provided by the IETF 649 Administrative Support Activity (IASA).