idnits 2.17.1 draft-ietf-simple-event-filter-funct-05.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1386. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 15, 2005) is 6975 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 (ref. '3') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2633 (ref. '6') (Obsoleted by RFC 3851) == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-01 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE H. Khartabil 3 Internet-Draft Telio 4 Expires: September 16, 2005 E. Leppanen 5 M. Lonnfors 6 J. Costa-Requena 7 Nokia 8 March 15, 2005 10 Functional Description of Event Notification Filtering 11 draft-ietf-simple-event-filter-funct-05 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 16, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The SIP event notification framework describes the usage of the 47 Session Initiation Protocol (SIP) for subscriptions and notifications 48 of changes to a state of a resource. The document does not describe 49 a mechanism of how filtering of event notification information can be 50 achieved. 52 This document describes the operations a subscriber performs in order 53 to put in place filtering rules associated with a subscription to 54 event notification information. The handling, by the subscriber, of 55 responses to subscriptions carrying filtering rules and the handling 56 of notifications with filtering rules applied to them is also 57 described. Furthermore, the document conveys how the notifier 58 behaves when receiving such filtering rules and how a notification is 59 constructed. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Client Operation . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1 Transport Mechanism . . . . . . . . . . . . . . . . . . . 5 67 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 68 3.3 Subscriber Generating SUBSCRIBE Requests . . . . . . . . . 5 69 3.3.1 Defining The Filtering Rules . . . . . . . . . . . . . 5 70 3.3.2 Request-URI vs. Filter URI . . . . . . . . . . . . . . 6 71 3.3.3 Changing Filters within a Dialog . . . . . . . . . . . 6 72 3.3.4 Subscriber Interpreting SIP responses . . . . . . . . 7 73 3.4 Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 74 4. Resource List Server Behaviour . . . . . . . . . . . . . . . . 7 75 4.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . 8 76 4.2 Changing Filters within a Dialog . . . . . . . . . . . . . 10 77 5. Server Operation . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.1 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2 Notifier Processing SUBSCRIBE Requests . . . . . . . . . . 10 80 5.2.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . 11 81 5.2.2 Changing Filters within a Dialog . . . . . . . . . . . 11 82 5.3 Notifier Generating NOTIFY Requests . . . . . . . . . . . 12 83 5.3.1 Generation of NOTIFY Contents . . . . . . . . . . . . 13 84 5.3.2 Handling of Notification Triggering Rules . . . . . . 14 85 5.4 Handling Abnormal Cases . . . . . . . . . . . . . . . . . 14 86 6. XML Document Validation . . . . . . . . . . . . . . . . . . . 14 87 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.1 Presence Specific Examples . . . . . . . . . . . . . . . . 15 89 7.1.1 Subscriber Requests Messaging Related Information . . 15 90 7.1.2 Subscriber Fetches Information about "Open" 91 Communication Means . . . . . . . . . . . . . . . . . 17 92 7.1.3 Subscriber Requests Notifications when 93 Presentity's Status Changes . . . . . . . . . . . . . 19 94 7.2 Watcher Information Specific Examples . . . . . . . . . . 21 95 7.2.1 Watcher Subscriber Makes Subscription to Get All 96 the Information about Active Watchers . . . . . . . . 22 98 7.2.2 Watcher Subscriber Requests Information of 99 Watchers with Specific Subscription Duration 100 Conditions . . . . . . . . . . . . . . . . . . . . . . 24 101 7.2.3 Watcher Subscriber Requests Specific Watcher Info 102 On Specific Triggers . . . . . . . . . . . . . . . . . 25 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 11.1 Normative References . . . . . . . . . . . . . . . . . . . 28 108 11.2 Informative References . . . . . . . . . . . . . . . . . . 29 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 110 Intellectual Property and Copyright Statements . . . . . . . . 31 112 1. Introduction 114 SIP event notification is described in [3]. It defines a general 115 framework for sending subscriptions and receiving notifications in 116 SIP based systems. It introduces the concept of event packages, 117 which are concrete applications of the general event framework to a 118 specific usage of events. 120 Filtering is a mechanism for controlling the content of event 121 notifications. Additionally, the subscriber may specify the rules 122 for when a notification should be sent to it. The filtering 123 mechanism is expected to be particularly valuable to users of mobile 124 wireless access devices. The characteristics of the devices 125 typically include high latency, low bandwidth, low data processing 126 capabilities, small display, and limited battery power. Such devices 127 can benefit from the ability to filter the amount of information 128 generated at the source of the event notification. However, 129 implementers need to be aware of the computational burden on the 130 source of the event notification. This is discussed further in 131 Section 8. 133 It is stated in [3] that the notifier may send a NOTIFY at any time, 134 but typically it is sent when the state of the resource changes. It 135 also states that the notifications would contain the complete and 136 current state of the resource authorized for a certain subscriber to 137 see. The format of such resource state information is package 138 specific. In this memo, we assume that the NOTIFY for any package 139 contains an XML document. 141 This document, togheter with [5], presents a mechanism for filtering 142 whereby a subscriber describes its preference of when notifications 143 are to be sent to it and what they are to contain. It also describes 144 how the notifier functions when generating notifications by taking 145 into account filters and default functionality of the 146 package/service. 148 The XML format for defining the filter is described in [5]. 150 2. Conventions 152 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 153 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 154 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 155 and indicate requirement levels for compliant implementations. 157 "Content" refers to the XML document that appears in a notification 158 reflecting the state of a resource. 160 3. Client Operation 162 3.1 Transport Mechanism 164 Transportation of the filter to the server is achieved by inserting 165 the XML document, as defined in [5], in the body of the SUBSCRIBE 166 request. Alternatively, the XML document can be uploaded to the 167 server using means outside the scope of this document. 169 3.2 SUBSCRIBE Bodies 171 SIP entities compliant with this specification MUST support the 172 content type 'application/simple-filter+xml'. 174 3.3 Subscriber Generating SUBSCRIBE Requests 176 This section presents additional functionality required from the 177 subscriber when filters are used in the bodies of the SUBSCRIBE 178 requests. Normal operations of services, e.g., as defined in [8], 179 [10] and [4] are otherwise followed. 181 As defined in [3], the SUBSCRIBE message MAY contain a body. This 182 body would serve the purpose of carrying filtering information. 183 Honouring those filters is at the discretion of the notifier and 184 might depend on local policies. 186 No content in the body of a SUBSCRIBE indicates to the notifier that 187 no filter is being requested so that the notifier is instructed to 188 send all the NOTIFY requests using the notifier's own or service 189 specific policy. Note that e.g. in the list case [4] the filter 190 might have been uploaded to the server beforehand (by means outside 191 the scope of this document). 193 If the body of the SUBSCRIBE includes the filter, the body MUST be of 194 the MIME-Type 'application/simple-filter+xml'. 196 3.3.1 Defining The Filtering Rules 198 Multiple filters MAY be included in one SUBSCRIBE. This is achieved 199 by including multiple elements in the filter [5]. Each 200 element may include a URI attribute. 202 A SUBSCRIBE request destined to a list URI [4] MAY include multiple 203 filters specific to individual resources. This is achieved by 204 including multiple elements with different URIs of resources 205 in each of those elements. This resource specific filter overrides 206 any list specific filter, if any. The list specific filter may or 207 may not include a URI. 209 Furthermore, regardless whether the SUBSCRIBE is destined to a list 210 URI or not, there can only be one filter applicable to a single 211 resource or domain within a single SUBSCRIBE. I.e. Each filter 212 within a subscription MUST uniquely identify one resource or one 213 domain. 215 A filter can be enabled and disabled using the 'enabled' attribute in 216 the element as desribed in [5]. 218 3.3.2 Request-URI vs. Filter URI 220 The URI in the filter defines the target resource, e.g. in the 221 Presence service case; it is the presentity's presence information to 222 which the filter is applied. The subscriber MAY choose to leave the 223 URI in the filter undefined. If the URI is not defined within the 224 filter, the filter applies to the resource identified in the 225 Request-URI. Similarly, the subscriber MAY define a filter URI. If 226 the Request-URI is a list URI [4], the filter URI MUST be the list 227 URI, a sub-list URI or resource who's URI is one of the URIs that 228 result from a lookup, by an RLS, on the Request-URI. If not, the 229 filter may be ignored or may be rejected. URI matching is done 230 according to the matching rules defined for a particular scheme (SIP 231 URI matching rules are defined in RFC3261 [2]. 233 A filter may also be addressed to a domain using the "domain" 234 attribute instead of the "uri" attribute. In this case, the filter 235 applies to resources in that domain. This can be used when a 236 subscription is for a resource that is an event list with many 237 resources from differing domains. If an individual resource specific 238 filter is present along with the domain filter, this resource 239 specific filter overrides any domain specific filter, if any. 241 3.3.3 Changing Filters within a Dialog 243 The client MAY reset or change the filter by re-issuing a new 244 SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the 245 exiting dialog that does not contain a filter is assumed to maintain 246 existing filters. This means that filters are persistent and are 247 only explicitly removed. 249 A client requiring removal of a filter may do so by using the 250 'remove="true"' attribute as defined in [5]. 252 In the case the URI in the filter is that of a list, a client may 253 override the existing filter with a filter for an individual 254 resource, that is part of the list subscribed to earlier, by issuing 255 a new SUBSCRIBE within the existing dialog and including a filter 256 specific for that individual resource. The new filter need not 257 include the original filter since a filter is only removed in the 258 manner indicated above. 260 A filter is replaced by the client re-issuing the filter using the 261 same filter ID and replacing the contents of the filter. Replacing a 262 filter by changing the filter ID and keeping the resource URI is 263 considered an error since this causes the server to assume that two 264 filters are placed for the same resource. 266 Again, filter can be disabled and re-enabled using the 'enabled' 267 attribute in the element as desribed in [5]. 269 3.3.4 Subscriber Interpreting SIP responses 271 The SUBSCRIBE request will be confirmed with a final response. A 272 200-class responses indicate that the subscription has been accepted, 273 and that a NOTIFY will be sent immediately. A "200" response 274 indicates that the subscription has been accepted and the filter is 275 accepted. A "202" response merely indicates that the subscription 276 has been understood, the content type has been accepted, and that 277 authorization may or may not have been granted. A "202" response 278 also indicates that the filter has not been accepted yet. The 279 acceptance of the filter MAY arrive in a subsequent NOTIFY. 281 A non-200 class final responses indicate that no subscription or 282 dialog has been created, and no subsequent NOTIFY message will be 283 sent. All non-200 class final responses have the same meanings and 284 handling as described in [2] and [3]. 286 Specifically, a "415" response indicates that the MIME type 287 'application/simple-filter+xml' is not understood by the notifier. A 288 "488" response indicates that the content type (filter) is understood 289 but some aspects of it were either not understood or not accepted. 291 3.4 Subscriber Processing of NOTIFY Requests 293 If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that 294 follows MAY contain a body that describes the present state of the 295 resource after the filters have been applied. 297 If the NOTIFY indicates that a subscription has been terminated [3], 298 the subscription is assumed to be terminated. Behaviour in such 299 events is also described in [3]. 301 If the subscription is indicated as active, NOTIFY requests are 302 handled as described in package specific documents and [3]. 304 4. Resource List Server Behaviour 306 The Resource List Server is defined in [4]. This section describes 307 how such entity behaves in the presence of a filter in a subscription 308 to a list. 310 4.1 Request-URI vs. Filter URI 312 If the URI is not defined within the filter, the filter applies to 313 the resource list identified in the Request-URI of the SUBSCRIBE 314 request. This results in the filter being applied to all the 315 notifications that the RLS issues to this subscription. The same 316 processing applies to a filter that defines a URI that matches the 317 request-URI of the SUBSCRIBE request. I.e. The filter applies to 318 all notifications that the RLS issues to this subscription. 320 If the URI indicated by the filter is for one resource whose URI is 321 one of the URIs that result from a lookup, by the RLS, on the 322 Request-URI, the filter for that particular resource is extracted and 323 propagated in the SUBSCRIBE request sent to that resource. It is 324 possible to have more than one filter in a SUBSCRIBE request body, 325 and therefore a filter specific to a resource MUST be extracted and 326 only that is propagated. For example, if the Request-URI in a 327 SUBSCRIBE has the value "sip:mybuddies@example.com" where 328 "bob@example.com" is a resource belonging to that list, and the URI 329 in a filter is "sip:bob@example.com", the filter specific for Bob is 330 extracted and placed in the body of the SUBSCRIBE sent to 331 "bob@example.com". 333 If the URI indicated by the filter is for one resource whose URI is 334 NOT under the RLS administrative control, the RLS propagates the 335 filter to all the fanned out subscriptions sent to destinations 336 outside the administrative domain of the RLS. This is to accommodate 337 the scenario where the subscriber knows that there are sub-lists in 338 the event list that are under a different administrative domain than 339 where the original subscription was sent to, and the subscriber 340 wishes to set a filter for a resource in that sub-list. 342 If the URI indicated by the filter is for one resource whose URI is 343 under the RLS administrative control but is not part of the resource 344 list that the subscription was addressed to, the filter is not 345 propagated. In this case, it is the RLS responsibility to make sure 346 than this filter is applied to notifications issued, if information 347 about that resource is present. 349 For example: If we have 2 lists, each located on its own RLS: 351 List1 (list1@example.com) on RLS1 has: bob@example.com 352 list2@biloxi.com 354 List2 on RLS2 has: alice@biloxi.com sarah@example.com 355 (Note: list2 is a resource in list1) 357 RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is for 358 addressed to list1 and contains 2 filters: one for sarah@example.com 359 and the other for alice@biloxi.com): 361 SUBSCRIBE sip:List1@example.com SIP/2.0 362 ... 363 364 365 366 367 368 369 370 371 urn:ietf:params:xml:ns:pidf 372 373 //pidf:tuple/pidf:note 374 375 376 377 378 379 //pidf:tuple/pidf:status/pidf:basic 380 381 382 384 RLS1 fans out subscriptions to resources on list1. The text above 385 suggests that if a filter is destined to a resource that is not part 386 of the list and is outside the administrative domain of an RLS, then 387 that filter is propagated. The rest are consumed. In our example, 388 only the filter to alice@biloxi.com is propagated since biloxi.com is 389 not under the administrative domain of RLS1. The filter to 390 sarah@example.com is consumed, and RLS1 needs to apply that filter to 391 notifications it receives. 393 URI matching is done according to the matching rules defined for a 394 particular scheme (SIP URI matching rules are defined in RFC3261 395 [2]. 397 A filter may also be addressed to a domain using the "domain" 398 attribute instead of the "uri" attribute. In this case, the filter 399 applies to resources in that domain and the RLS MUST NOT apply 400 filters to any notifications it sends, but instead MUST forward the 401 filter with all fanned out subscriptions to the notifiers. 403 As indicated in Section 3.3.1, multiple filters can be present in a 404 SUBSCRIBE request. Filters can also be added or modified as 405 indicated in Section 3.3.3. In such circumstances, an RLS MUST check 406 that there are no filters addressed to the same resource or domain 407 and if so, it MUST reject the SUBSCRIBE request with a "488" error 408 response. 410 4.2 Changing Filters within a Dialog 412 If an RLS receives a subscription refresh request with no filters 413 specified (empty payload), the RLS assumes that the client does not 414 wish to update the filters. If an RLS receives a subscription 415 refresh with a filter containing the 'remove="true"' attribute as 416 defined in [5], the RLS assumes that the client is removing that 417 filter identified by the filter ID. 419 If an RLS receives a subscription refresh request with a filter that 420 already exists (i.e. having the same filter ID), the RLS interprets 421 it as a replacement of the existing filter. Replacing a filter by 422 changing the filter ID and keeping the resource URI is considered an 423 error since this causes the RLS to assume that two filters are placed 424 for the same resource. 426 5. Server Operation 428 5.1 NOTIFY Bodies 430 SIP entities compliant with this specification MUST support 431 content-type 'application/simple-filter+xml'. 433 5.2 Notifier Processing SUBSCRIBE Requests 435 This section presents additional functionality required from the 436 notifier when filters are used in the bodies of the SUBSCRIBE 437 requests. Normal package specific functionality are otherwise 438 followed. 440 The notifier will examine the Content-Type header field and will 441 return a 415 response if it does not understand the content type 442 'application/simple-filter+xml'. 444 A 200-class responses indicate that the subscription has been 445 accepted, and the NOTIFY will be sent immediately. A "200" response 446 indicates that the subscription has been accepted, the user is 447 authorized and the filter is accepted. A "202" response merely 448 indicates that the subscription has been understood, but the 449 authorization may or may not have been granted. A "202" response 450 also indicates that the filters have not been accepted yet. The 451 acceptance of the filters MAY arrive in a subsequent NOTIFY. 453 Procedures described in section Section 5.4 are followed if an error 454 is encountered. 456 As indicated in Section 3.3.1, multiple filters can be present in a 457 SUBSCRIBE request. Filters can also be added or modified as 458 indicated in Section 3.3.3. In such circumstances, a server MUST 459 check that there are no filters addressed to the same resource or 460 domain and if so, it MUST reject the SUBSCRIBE request with a "488" 461 error response. 463 5.2.1 Request-URI vs. Filter URI 465 The subscriber may have chosen to leave the URI in the filter 466 undefined. If the URI is not defined within the filter, the filter 467 applies to the resource identified in the Request-URI. 469 Similarly, the subscriber may have chosen to include a URI in the 470 filter. In this case, the filter applies to all notifications sent 471 with content associated with the resource with that URI, for this 472 subscription. If the Request-URI and the URI in the filter mismatch, 473 the filter may be ignored or may be rejected. URI matching is done 474 according to the matching rules defined for a particular scheme (SIP 475 URI matching rules are defined in RFC3261 [2]. 477 A filter may also be addressed to a domain using the "domain" 478 attribute instead of the "uri" attribute. In this case, the filter 479 applies to resources in that domain. The notifier MUST NOT apply 480 filters to any notifications it sends if the domain is not that of 481 its own, and MUST ignore it. Notifiers belonging to the domain MUST 482 apply the filter to all notifications it sends for that subscription, 483 unless policy dictates otherwise. 485 5.2.2 Changing Filters within a Dialog 487 If a server receives a subscription refresh request with no filters 488 specified (empty payload), it assumes that the client does not wish 489 to update the filters. If it receives a subscription refresh with a 490 filter containing the 'remove="true"' attribute as defined in [5], 491 the server assumes that the client is removing that filter identified 492 by the filter ID. 494 If the server receives a subscription refresh request with a filter 495 that already exists (i.e. having the same filter ID), it interprets 496 it as a replacement of the existing filter. Replacing a filter by 497 changing the filter ID and keeping the resource URI is considered an 498 error since this causes the server to assume that two filters are 499 placed for the same resource. 501 5.3 Notifier Generating NOTIFY Requests 503 Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD 504 retain the filter as long as the subscription persists. The filter 505 MAY be incorporated within an existing subscription (in an active 506 dialog) by sending a re-SUBSCRIBE that includes the filter in the 507 body. 509 If the response sent to the SUBSCRIBE was a "202" and the "202" was 510 chosen because the filter could not be accepted that time, the NOTIFY 511 MAY be used to terminate the subscription if the filter was found 512 unacceptable. 514 As described in [3], the NOTIFY message MAY contain a body that 515 describes the state of the resource. This body is in one of the 516 formats listed in the Accept header field of the SUBSCRIBE, or the 517 package specific default if the Accept header field is omitted. 519 Based on the contects of a filter, the following processing occurs: 521 o A filter with only a element will result in sending the 522 requested resource state information in that element 523 whenever there is a change in the resource state. 525 o A filter with only a element will result in sending all 526 resource state information whenever there is a change in the 527 resource state that matches the triggers. 529 o A filter with a and elements will result in 530 sending the requested resource state information in that 531 element whenever there is a change in the resource state that 532 matches the triggers. 534 When a filter is disabled (by setting the 'enabled' attribute to 535 "false"), all state and state changes are reported. A disabled 536 filter means the same thing as the absence of that filter. I.e. All 537 changes to a resource state result in issuing a notification to the 538 subscriber (assuming there are no other filters). 540 When a filter is re-enabled, (by setting the 'enabled' attribute to 541 "true", or by omitting the 'enabled' attribute), the notifier behaves 542 as if the filter has just been placed by the SUBSCRIBE request 543 enabling it. Immediate NOTIFY rules as stated in Section 5.3.1 544 apply. 546 5.3.1 Generation of NOTIFY Contents 548 If the NOTIFY being sent is the immediate one sent after a 2xx 549 response to the original SUBSCRIBE, its contents MUST be populated 550 according to the filter element unless the processing of the 551 filters will take too long or the NOTIFY request is following a "202" 552 response to the SUBSCRIBE request and is terminating the 553 subscription. In the case that the filter is taking too long to 554 process, the NOTIFY request being sent may be empty or may be 555 populated with a pre-configured value as authorised to that 556 subscriber. If applying the filter results in no content to be 557 delivered, the NOTIFY MUST be sent with empty contents. If the 558 filter contains elements, the notifier ignores the trigger 559 values when generating the first NOTIFY request. 561 The input to the content filter is a package specific XML document, 562 e.g. [7] and [9] derived according to the package specific 563 specifications, ([8] and [10]). 565 The content is filtered according to the expressions in the 566 element of the filter. The expression indicates the delivered XML 567 elements and/or attributes. Prefixes of the namespaces of the items 568 of the XML document to be filtered must be expanded before applying 569 the filter to the items. 571 The expression directly states the XML elements and attributes to be 572 delivered in the NOTIFY, along with their values. In addition to the 573 selected contents also the namespaces of all the selected items are 574 included in the NOTIFY. The XML elements and/or attributes indicated 575 by the expression in the element must be items that the 576 subscriber is authorised to see. If not, the notifier policy 577 dictates the behaviour of the notifier (notifier can either ignore 578 the filter, parts of the filter, or reject the filter completely). 579 Implementers need to carefully consider such an implementation 580 decision; the subscriber may not be aware of the authorised contents 581 and therefore most likely will include a filter requesting 582 unauthorised contents. It is therefore RECOMMENDED that notifiers 583 just ignore the parts of the filter where it is requesting 584 unauthorised info. I.e. The filter in the element where 585 the unauthorised contents are requested is ignored. If polite 586 blocking is used by the notifier, the notifier may choose to ignore 587 the filter, by choosing to deliver notifications containing bogus 588 information in the unauthorised elements or attributes. 590 The resultant XML document MUST be well formed and valid according to 591 the XML schema. This means that all mandatory elements and 592 attributes along with their values MUST be included in the XML 593 document regardless of the expression. In other words, if the 594 results of applying a filter on an XML document is a non-valid XML 595 document, the notifier MUST add elements and attributes, along with 596 their values, from the original XML document into the newly 597 formulated one in order for it to be a valid one. 599 5.3.2 Handling of Notification Triggering Rules 601 There can be several elements inside one element. 602 If the criteria for any of the elements are satisfied, a 603 NOTIFY SHOULD be generated. 605 The items (XML elements and/or attributes) indicated by the 606 expression in the element, element or 607 element must be items that the subscriber is authorised to access. 608 If not, the notifier policy dictates the behaviour of the notifier 609 (notifier can either ignore the filter, parts of the filter, or 610 reject the filter completely). 612 5.4 Handling Abnormal Cases 614 In case of an invalid filter definition where the XML document of the 615 filter is not aligned with the XML schema of the filter format[5], 616 the notifier rejects the SUBSCRIBE request with a "488" response. A 617 Warning header field in the response may give better indication why 618 the filters were not accepted. If the subscription was accepted with 619 a "202" response but the invalid filter was discovered after that, a 620 NOTIFY with a subscription-state of value 'terminated' is sent. An 621 event-reason-value "badfilter", introduced here, of subexp-params [3] 622 MAY be included. 624 In case of an erroneous expression in the filter definition the 625 notifier either ignores the filter definition or terminates the 626 subscription. 628 If a or element is empty, the notifier proceeds as 629 if the element did not exist. 631 6. XML Document Validation 633 The creator of the filter MUST ensure that the XML document inserted 634 as the SUBSCRIBE request body is well-formed and valid. The creator 635 MUST NOT insert any extension elements or attributes into the XML 636 document unless it has access to the extension schema and can 637 validate the XML document. The XML document consumer MAY validate 638 the XML document according the schemas, including extension schemas, 639 it has access to that are applicable to this XML document. 641 7. Examples 643 The following chapters include filtering examples for Presence and 644 Watcher Information. The format of filter is according to [5]. 646 7.1 Presence Specific Examples 648 This chapter describes three use cases where the presence information 649 filtering solution is utilised [8]. In the first use case the 650 watcher is interested in getting messaging specific information of a 651 certain presentity. In the second use case the watcher is interested 652 in getting information about the communication means and contact 653 addresses the presentity is currently available for communication on. 654 The third case shows how a presentity can request triggers to receive 655 notifications 657 Below is the Presentity's presence information in PIDF [7]. It 658 includes two tuples: one for the instant messaging and another for 659 the voice related information. 660 661 664 665 666 closed 667 668 im 669 im:presentity@example.com 670 671 672 673 open 674 675 voice 676 tel:2224055555@example.com 677 678 680 7.1.1 Subscriber Requests Messaging Related Information 682 The subscriber initiates a subscription to the presentity's messaging 683 (MMS, IM and SMS) related presence information. The subscription 684 includes the content limiting filter. 686 The filtered content is indicated with an expression. This 687 expression selects the element and all the parent elements 688 (this means the status, tuple and its root element), the 689 element and the element. The filter is: elements 690 that have values "MMS", "SMS" or "IM". 692 In this case, the notification includes the contents of the tuple 693 that has the value "IM" in its element. 695 SUBSCRIBE request from the subscriber including filter: 697 SUBSCRIBE sip:presentity@example.com 698 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk 699 To: 700 From: ;tag:12341111 701 Call-ID: 32432udfidfjmk342 702 Cseq: 1 SUBSCRIBE 703 Expires: 3600 704 Event: Presence 705 Contact: 706 Content-Type: application/simple-filter+xml 707 Content-Length: ... 709 710 711 712 713 715 716 717 718 719 //pidf:tuple[rpid:class="IM" or rpid:class="SMS" 720 or rpid:class="MMS"]/pidf:status/pidf:basic 721 722 723 //pidf:tuple[rpid:class="IM" or rpid:class="SMS" 724 or rpid:class="MMS"]/rpid:class 725 726 727 //pidf:tuple[rpid:class="IM" or rpid:class="SMS" 728 or rpid:class="MMS"]/pidf:contact 729 730 731 732 734 Notification to the subscriber: 736 NOTIFY sip:watcher@client.example.com SIP/2.0 737 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder 738 To: ;tag:12341111 739 From: ;tag:232321 740 Call-ID: 32432udfidfjmk342 741 Cseq: 1 NOTIFY 742 Event: Presence 743 Subscription-State: active; expires=3599 744 Contact: sip:presentity@server.example.com 745 Content-Type: application/pidf+xml 746 Content-Length: ... 748 749 752 753 754 closed 755 756 im 757 im:presentity@example.com 758 759 761 7.1.2 Subscriber Fetches Information about "Open" Communication Means 763 The subscriber makes a subscription to the presentity's available 764 communication means. The subscription includes the content limiting 765 filter. 767 The filtered content is indicated with an expression. This 768 expression selects the element and all the parent elements 769 (this means the status, tuple and its root element), the 770 element and the element. The filter is: the 771 element's value is "Open". 773 In this case the notification returns the contents of the tuple that 774 has both the value "open" inside the element. 776 SUBSCRIBE request from the subscriber including filter: 778 SUBSCRIBE sip:presentity@example.com SIP/2.0 779 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk 780 To: 781 From: ;tag:12341111 782 Call-ID: 32432udfidfjmk342 783 Cseq: 1 SUBSCRIBE 784 Expires: 3600 785 Event: Presence 786 Contact: 787 Content-Type: application/simple-filter+xml 788 Content-Length: ... 790 791 792 793 794 796 797 798 799 800 //pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic 801 802 803 //pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class 804 805 806 //pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact 807 808 809 810 812 Notification to the subscriber: 814 NOTIFY sip:watcher@client.example.com SIP/2.0 815 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder 816 To: ;tag:12341111 817 From: ;tag:232321 818 Call-ID: 32432udfidfjmk342 819 Cseq: 1 NOTIFY 820 Event: Presence 821 Subscription-State: active; expires=3599 822 Contact: sip:presentity@server.example.com 823 Content-Type: application/pidf+xml 824 Content-Length: ... 826 827 830 831 832 open 833 834 voice 835 tel:2224055555@example.com 836 837 839 7.1.3 Subscriber Requests Notifications when Presentity's Status 840 Changes 842 The subscriber subscribes to the presentity, specifying in the filter 843 that it wants notifications only when the element has changed 844 to value 'open' 846 SUBSCRIBE request from the subscriber including filter: 848 SUBSCRIBE sip:presentity@example.com 849 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk 850 To: 851 From: ;tag:12341111 852 Call-ID: 32432udfidfjmk342 853 Cseq: 1 SUBSCRIBE 854 Expires: 3600 855 Event: Presence 856 Contact: 857 Content-Type: application/simple-filter+xml 858 Content-Length: ... 860 861 862 863 864 865 866 867 868 /pidf:presence/pidf:tuple/pidf:status/pidf:basic 869 870 871 872 874 At some point during the subscription, a 2nd PIDF document is created 875 with both tuples having status of closed: 877 878 881 882 883 closed 884 885 im 886 im:presentity@example.com 887 888 889 890 closed 891 892 voice 893 tel:2224055555@example.com 894 895 897 A NOTIFY is not sent to the subscriber in this case. 899 Now, a 3rd PIDF document is created when IM status changes to OPEN: 901 902 905 906 907 open 908 909 im 910 im:presentity@example.com 911 912 913 914 closed 915 916 voice 917 tel:2224055555@example.com 918 919 921 Notification containing both tuples is sent to the subscriber in this 922 case: 924 NOTIFY sip:watcher@client.example.com SIP/2.0 925 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder 926 To: ;tag:12341111 927 From: ;tag:232321 928 Call-ID: 32432udfidfjmk342 929 Cseq: 1 NOTIFY 930 Event: Presence 931 Subscription-State: active; expires=3599 932 Contact: sip:presentity@server.example.com 933 Content-Type: application/pidf+xml 934 Content-Length: ... 936 937 940 941 942 closed 943 944 im 945 im:presentity@example.com 946 947 948 949 open 950 951 voice 952 tel:2224055555@example.com 953 954 956 7.2 Watcher Information Specific Examples 958 The examples in this section use the winfo template-package with the 959 presence event package [10]. 961 Watcher information to a Presentity: 963 964 966 968 sip:watcherA@example.com" 973 sip:watcherB@example.com" 978 sip:watcherC@example.com" 983 sip:watcherD@example.com" 988 989 991 7.2.1 Watcher Subscriber Makes Subscription to Get All the Information 992 about Active Watchers 994 SUBSCRIBE request from the presentity including the filter: 996 SUBSCRIBE sip:presentity@example.com 997 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk 998 To: 999 From: ;tag:12341111 1000 Call-ID: 32432udfidfjmk342 1001 Cseq: 1 SUBSCRIBE 1002 Expires: 3600 1003 Event: Presence.winfo 1004 Contact: sip:presentity@client.example.com 1005 Content-Type: application/simple-filter+xml 1006 Content-Length: ... 1008 1009 1010 1011 1013 1014 1015 1016 1017 /wi:watcherinfo/wi:watcher-list[@package="presence"]/ 1018 wi:watcher[@status="active"] 1019 1020 1021 1022 1024 Notification to the subscriber: 1026 NOTIFY sip:presentity@client.example.com SIP/2.0 1027 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder 1028 To: sip:presentity@example.com;tag:12341111 1029 From: sip:presentity@example.com;tag:232321 1030 Call-ID: 32432udfidfjmk342 1031 Cseq: 1 NOTIFY 1032 Contact: sip:presentity@server.example.com 1033 Event: Presence.winfo 1035 Content-Type: application/watcherinfo+xml 1036 Content-Length: ... 1038 1039 1041 1043 sip:watcherA@example.com" 1048 sip:watcherD@example.com" 1053 1054 1056 7.2.2 Watcher Subscriber Requests Information of Watchers with Specific 1057 Subscription Duration Conditions 1059 SUBSCRIBE request from the presentity including the filter: 1061 SUBSCRIBE sip:presentity@example.com 1062 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk 1063 To: ;tag:12341111 1064 From: 1065 Call-ID: 32432udfidfjmk342 1066 Cseq: 1 SUBSCRIBE 1067 Expires: 0 1068 Event: Presence.winfo 1069 Contact: 1070 Content-Type: application/simple-filter+xml 1071 Content-Length: ... 1073 1074 1075 1076 1078 1079 1080 1081 1082 /wi:watcherinfo/wi:watcher-list[@package="presence"]/ 1083 wi:watcher[@duration-subscribed>500] 1084 1085 1086 1087 1089 Notification to the subscriber: 1091 NOTIFY sip:presentity@client.example.com SIP/2.0 1092 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder 1093 To: sip:presentity@example.com;tag:12341111 1094 From: sip:presentity@example.com;tag:232321 1095 Call-ID: 32432udfidfjmk342 1096 Cseq: 1 NOTIFY 1097 Contact: sip:presentity@server.example.com 1098 Event: Presence.winfo 1100 Content-Type: application/watcherinfo+xml 1101 Content-Length: ... 1103 1104 1106 1108 sip:watcherA@example.com" 1113 sip:watcherB@example.com" 1118 1119 1121 7.2.3 Watcher Subscriber Requests Specific Watcher Info On Specific 1122 Triggers 1124 This filter selects watcher information notifications [9] to be sent 1125 when the pending subscription status has changed from 'pending' to 1126 'terminated'. In the notification, only the watchers that have a 1127 status of 'terminated' and an event of 'rejected' are included. 1129 SUBSCRIBE request from the Watcher Subscriber including the filter: 1131 SUBSCRIBE sip:presentity@example.com 1132 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk 1133 To: ;tag:12341111 1134 From: 1135 Call-ID: 32432udfidfjmk342 1136 Cseq: 1 SUBSCRIBE 1137 Expires: 0 1138 Event: Presence.winfo 1139 Contact: 1140 Content-Type: application/simple-filter+xml 1141 Content-Length: ... 1143 1144 1145 1146 1148 1149 1150 1151 1152 /wi:watcherinfo/wi:watcher-list[@package="presence"]/ 1153 wi:watcher[@status="terminated" and @event="rejected"] 1154 1155 1156 1157 1159 //@status 1160 1161 1162 1163 1165 At some point during the subscription, a 2nd Winfo document is 1166 created due to some change: 1168 1169 1171 1173 sip:watcherA@example.com" 1178 sip:watcherB@example.com" 1183 sip:watcherC@example.com" 1188 sip:watcherD@example.com" 1193 1194 1196 Notification to the subscriber is created, taking into account the 1197 and elements: 1199 NOTIFY sip:presentity@client.example.com SIP/2.0 1200 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder 1201 To: sip:presentity@example.com;tag:12341111 1202 From: sip:presentity@example.com;tag:232321 1203 Call-ID: 32432udfidfjmk342 1204 Cseq: 1 NOTIFY 1205 Contact: sip:presentity@server.example.com 1206 Event: Presence.winfo 1208 Content-Type: application/watcherinfo+xml 1209 Content-Length: ... 1211 1212 1214 1216 sip:watcherB@example.com" 1221 sip:watcherC@example.com" 1226 1227 1229 8. Security Considerations 1231 The presence of filters in the body of a SIP message has a 1232 significant effect on the ways in which the request is handled at a 1233 server. As a result, it is especially important that messages 1234 containing this extension be authenticated and authorized. 1235 Authentication can be achieved using the Digest Authentication 1236 mechanism described in [2]. The authorisation decision is made based 1237 on the permissions that the resource (notifier) has given to the 1238 watcher. An example of such auhorisation policy can be found in 1239 [11]. 1241 Processing of requests and looking up filters requires set operations 1242 and searches, which can require some amount of computation. This 1243 enables a DoS attack whereby a user can send requests with 1244 substantial numbers messages with large contents, in the hopes of 1245 overloading the server. To counter this, the server can establish a 1246 limit on the number of occurrences of the , , 1247 and elements allowed in the filters. A default limit of 40 1248 is RECOMMENDED, however, servers may raise or lower the limit 1249 depending upon their specific engineered capacity. 1251 Requests can reveal sensitive information about a UA's capabilities. 1252 If this information is sensitive, it SHOULD be encrypted using SIP 1253 S/MIME capabilities [6]. All package specific security measures MUST 1254 be followed. 1256 Propagating filters in SUBSCRIBE requests to foreign domains reveals 1257 sensitive information about a user's resource lists. It is therefore 1258 required that an RLS does not forward a filter if that filter is 1259 addressed to a resource that is under the administrative domain of 1260 the RLS, but is not on the resource list. Section 4.1 shows an 1261 example where such a scenario can occur. 1263 It is important to note that a filtered document located at a 1264 subscriber may project false reality. For example, if a subscriber 1265 asked to be notified when a resource has changed his presence state 1266 from closed to open but not from open to closed, then the subscriber 1267 may afterwards be under the false impression that the resource's 1268 presence state is open even long after the resource has changed it to 1269 closed. Therefore, subscribers need to be sure what they put in a 1270 filter, understand what they asked for and be prepared to be out of 1271 sync with the real state of a resource. 1273 9. IANA Considerations 1275 A new event-reason-value "badfilter" is defined to represent the 1276 event where the filter is not well formed and/or not accepted. No 1277 IANA registration is required for this value. 1279 10. Acknowledgements 1281 The authors would like to thank George Foti, Tim Moran, Sreenivas 1282 Addagatla, Juha Kalliokulju, Jari Urpalainen and Mary Barnes for 1283 their valuable input. 1285 11. References 1287 11.1 Normative References 1289 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1290 Levels", BCP 14, RFC 2119, March 1997. 1292 [2] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, 1293 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1294 Session Initiation Protocol", RFC 3261, June 2002. 1296 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1297 Notification", RFC 3265, June 2002. 1299 [4] Roach, A., "A Session Initiation Protocol (SIP) Event 1300 Notification Extension for Resource Lists", 1301 draft-ietf-simple-event-list-07.txt, December 2004. 1303 [5] Khartabil, H., "An Extensible Markup Language (XML) Based Format 1304 for Event Notification Filtering", 1305 draft-ietf-simple-filter-format-05.txt, February 2005. 1307 [6] Ramsdell, B., "S/MIME Version 3 Message Specification", 1308 RFC 2633, June 1999. 1310 11.2 Informative References 1312 [7] Sugano, H., "Presence Information Data Format", RFC 3863, 1313 Auguest 2004. 1315 [8] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions 1316 for Presence", RFC 3856, July 2004. 1318 [9] Rosenberg, J., "An Extensible Markup Language (XML) Based 1319 Format for Watcher Information", RFC 3858, July 2004. 1321 [10] Rosenberg, J., "A Watcher Information Event Template-Package 1322 for SIP", RFC 3857, July 2004. 1324 [11] Rosenberg, J., "Presence Authorization Rules", 1325 draft-ietf-simple-presence-rules-01, April 2005. 1327 Authors' Addresses 1329 Hisham Khartabil 1330 Telio 1331 P.O. Box 1203 Vika 1332 Oslo 1333 Norway 1335 Phone: +47 2167 3544 1336 Email: hisham.khartabil@telio.no 1337 Eva Leppanen 1338 Nokia 1339 P.O BOX 785 1340 Tampere 1341 Finland 1343 Phone: +358 7180 77066 1344 Email: eva-maria.leppanen@nokia.com 1346 Mikko Lonnfors 1347 Nokia 1348 Itamerenkatu 00180 1349 Helsinki 1350 Finland 1352 Phone: + 358 50 4836402 1353 Email: mikko.lonnfors@nokia.com 1355 Jose Costa-Requena 1356 Nokia 1357 P.O. Box 321 1358 FIN-00045 NOKIA GROUP 1359 FINLAND 1361 Phone: +358 71800 8000 1362 Email: jose.costa-requena@nokia.com 1364 Intellectual Property Statement 1366 The IETF takes no position regarding the validity or scope of any 1367 Intellectual Property Rights or other rights that might be claimed to 1368 pertain to the implementation or use of the technology described in 1369 this document or the extent to which any license under such rights 1370 might or might not be available; nor does it represent that it has 1371 made any independent effort to identify any such rights. Information 1372 on the procedures with respect to rights in RFC documents can be 1373 found in BCP 78 and BCP 79. 1375 Copies of IPR disclosures made to the IETF Secretariat and any 1376 assurances of licenses to be made available, or the result of an 1377 attempt made to obtain a general license or permission for the use of 1378 such proprietary rights by implementers or users of this 1379 specification can be obtained from the IETF on-line IPR repository at 1380 http://www.ietf.org/ipr. 1382 The IETF invites any interested party to bring to its attention any 1383 copyrights, patents or patent applications, or other proprietary 1384 rights that may cover technology that may be required to implement 1385 this standard. Please address the information to the IETF at 1386 ietf-ipr@ietf.org. 1388 Disclaimer of Validity 1390 This document and the information contained herein are provided on an 1391 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1392 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1393 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1394 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1395 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1398 Copyright Statement 1400 Copyright (C) The Internet Society (2005). This document is subject 1401 to the rights, licenses and restrictions contained in BCP 78, and 1402 except as set forth therein, the authors retain all their rights. 1404 Acknowledgment 1406 Funding for the RFC Editor function is currently provided by the 1407 Internet Society.