idnits 2.17.1 draft-ietf-simple-data-req-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 18 instances of lines with control characters in the document. 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 (June 27, 2003) is 7602 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) == Unused Reference: '4' is defined on line 565, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-03 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-03 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG J. Rosenberg 3 Internet-Draft Dynamicsoft 4 Expires: December 26, 2003 M. Isomaki 5 Nokia Research Center 6 June 27, 2003 8 Requirements for Manipulation of Data Elements in Session Initiation 9 Protocol (SIP) for Instant Messaging and Presence Leveraging 10 Extensions (SIMPLE) Systems 11 draft-ietf-simple-data-req-03 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 26, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 In any presence application, it is frequently necessary for the user 42 to configure a number of pieces of information. Users will need to 43 manipulate their presentity list, adding and removing presentities, 44 and manipulate their authorization lists, which specify the set of 45 users that can subscribe to their presence. In this document, we 46 provide a framework and requirements for such data manipulations. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Resource List Manipulation Requirements . . . . . . . . . . . 6 55 6. Authorization Policy Manipulation . . . . . . . . . . . . . . 8 56 6.1 Acceptance Policy Requirements . . . . . . . . . . . . . . . . 8 57 6.2 Notification Requirements . . . . . . . . . . . . . . . . . . 9 58 6.3 Content Requirements . . . . . . . . . . . . . . . . . . . . . 10 59 6.4 General Requirements . . . . . . . . . . . . . . . . . . . . . 11 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 62 9. Changes from version 02 . . . . . . . . . . . . . . . . . . . 13 63 Informative References . . . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 65 Intellectual Property and Copyright Statements . . . . . . . . 15 67 1. Introduction 69 Consumer-based instant messaging and presence applications typically 70 provide a rich set of features. In addition to being able to 71 subscribe to, and get notified of, changes in presence, users can 72 also configure the operation of the application. 74 Most systems allow the user to add or remove users from their 'buddy 75 list', which we refer to here as a resource list. The resource list 76 is the set of presentities [2] that a user is subscribed to. This 77 list is frequently stored on the server, allowing the user to 78 generate a single subscription to the entire list. The server then 79 'fans out' that subscription to all the presentities on the list. 80 Subscription to resource lists is supported through the SIP event 81 notification extension for resource lists [6]. However, no automated 82 means is currently defined to create these lists, add users to them, 83 remove users from them, or query for the set of users on the list. 85 Similarly, most systems support user-defined authorization policies. 86 A user can specify which watchers are (or are not) allowed to 87 subscribe to their presence, and furthermore, what aspects of their 88 presence a watcher is able to see. While SIMPLE [3] systems can 89 support such authorization policies, besides human-driven techniques, 90 such as web or voice response, there is no automated way to specify 91 these policies. 93 In this document, we propose a framework and a set of requirements 94 for manipulation of resource lists and authorization policies. 95 Further data manipulation requirements may be defined in the future, 96 but they are out of the scope of this document. 98 2. Conventions 100 In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 101 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 102 and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] 103 and indicate requirement levels for compliant implementations. 105 3. Terminology 107 This document uses the following terminology: 109 Resource list: A resource list is a set of presentities, each of 110 which is identified by a URI. The list itself is identified by a 111 URI (for example, sip:myfriends@example.com). Using the SIP event 112 extension for resource lists [6], a watcher can subscribe to the 113 resource list and learn about the presence state of all the 114 presentities in the set. 116 Presence Authorization Policy: Presence authorization policy refers 117 to the set of directives given to a presence agent on what 118 subscriptions to accept, when to generate notifications for a 119 subscription, and what information should be placed in those 120 notifications. 122 Acceptance Policy: The component of presence authorization policy 123 that determines whether or not to accept a subscription from a 124 watcher. 126 Notification Policy: The component of presence authorization policy 127 that determines when a notification should be sent to a watcher. 129 Content Policy: The component of presence authorization that 130 determines the content of the information provided to a watcher in 131 a notification. 133 SIMPLE Data Elements: SIMPLE data elements are user specified data 134 that determine the behavior of a presence agent. This includes 135 resource lists and presence authorization policy. 137 Data Manipulation Client: A data manipulation client is a protocol 138 agent that reads, writes, and receives notifications of changes in 139 SIMPLE data elements. 141 Data Manipulation Server: A data manipulation server is a protocol 142 agent that receives reads, writes, and sends notifications of 143 changes in SIMPLE data elements. The server is responsible for the 144 storage of the SIMPLE data elements. 146 4. Framework 148 The framework for the usage and manipulation of SIMPLE data elements 149 are shown in Figure 1. 151 SUBSCRIBE |--------| 152 ------------->| |<---| //-----\\ 153 <-------------| PA | | || || 154 NOTIFY |--------| |---|\\-----//| 155 | | 156 | Storage | 157 | | 158 |->|---------| 159 |--------| | 160 | |<----| 161 | Server | Read/Write 162 |--------| 163 ^ | 164 | | RL/Auth manipulations 165 | v 166 |--------| 167 | | 168 | Client | 169 |--------| 171 Figure 1: Framework for Data Manipulation 173 The data manipulation client (just referred to as the client) uses 174 some protocol, whose requirements are specified here, to interact 175 with the data manipulation server. Those interactions include 176 requests to read a SIMPLE data element, write one, or receive 177 notifications in changes to one. The data manipulation server (just 178 referred to as the server) manages a persistent store of the SIMPLE 179 data elements, and interacts with the client. 181 When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it 182 may require access to SIMPLE data elements in order to process the 183 request. For example, if the subscription is for a resource list, the 184 PA will need to determine that this is the case, and secondly, 185 'expand' the resource list, obtaining the list of URIs for that 186 resource list. 188 If the SUBSCRIBE request is for a presentity, the PA will need to 189 obtain the presence authorization policy of that presentity in order 190 to process the SUBSCRIBE request. 192 In both cases, the PA requires only read access to the data. As a 193 result, it obtains it directly from the data store, rather than 194 interacting with the server. This, of course, is just a model of the 195 system; a real implementation might involve interaction with the 196 server before reading the data. 198 Between the resource list and presence authorization policy, the 199 presence authorization policy is a far more complicated piece of 200 data. The authorization policy can be reasonably split into three 201 separate pieces. The first, which we call the acceptance policy, 202 determines whether or not to grant a subscription to the subscriber. 203 This policy results in a binary decision. The second piece, which we 204 call the notification policy, determines when that particular 205 subscriber should receive notifications. For example, a subscriber 206 might only be permitted to see when I log in or log out of IM, but 207 not receive notifications when my phone goes on hook. This is closely 208 related to the third piece, which we call the content policy. This 209 policy specifies the content of the information present in a 210 notification that is sent to a subscriber. 212 All of these policies are data that is manipulated by the data 213 manipulation protocol. 215 5. Resource List Manipulation Requirements 217 The following are the set of requirements for the protocol between 218 the client and the server for the purposes of manipulation resource 219 lists. It is obvious that similar requirements would apply to lists 220 used by other applications than presence as well, but those are 221 outside the scope of this document. 223 REQ PC-1: It MUST be possible for the client to create resource 224 lists and associate each of them with a distinct URI. 226 REQ PC-2: It MUST be possible for the user to specify the URI for 227 the resource list when one is created. If the name cannot be 228 allocated (because it already exists, for example), it MUST be 229 possible to inform the client of the failure, and the reason for 230 it. 232 REQ PC-3: It MUST be possible for the server to provide the client a 233 URI for the list when one is created, in the case where the client 234 does not provide it. 236 REQ PC-4: It MUST be possible to associate a display name with a 237 resource list. 239 REQ PC-5: It MUST be possible to add an entry to the resource list. 240 Each entry MUST be able to include at least a URI, and a display 241 name. It MUST be possible for the entry to be any URI that is 242 meaningful in the context of a resource list. Examples would 243 include a SIP URI or pres URI [7]. 245 REQ PC-6: It MUST be possible to extend the set of information 246 associated with the entries in the resource list and with the list 247 itself. An example would be a filtering document associated with 248 the list. 250 REQ PC-7: It MUST be possible for a resource list to contain entries 251 which are themselves resource lists. 253 REQ PC-8: It MUST be possible to remove an entry from the resource 254 list. If the entry does not exist, it MUST be possible for the 255 server to inform the client of this fact. 257 REQ PC-9: It MUST be possible to modify an entry in the resource 258 list. 260 REQ PC-10: It MUST be possible to clear all entries from a resource 261 list. 263 REQ PC-11: It MUST be possible to query for the set of URIs and 264 other possible information related to a particular resource list 265 by providing the URI for the resource list. 267 REQ PC-12: It MUST be possible to delete a resource list. In this 268 context, deleted means that the name of the resource list is no 269 longer defined, so that subscriptions to the list would fail. 271 REQ PC-13: It MUST be possible for a user to retrieve the list of 272 resource lists that they have created. 274 REQ PC-14: It MUST be possible for the resource list to be 275 associated with a list of authorized users who are able to query 276 for the set of URIs and other possible information related to the 277 list. 279 REQ PC-15: It MUST be possible for the resource list to be 280 associated with a list of authorized users who are the only ones 281 permitted to manipulate the resource list. 283 REQ PC-16: It MUST be possible for the resource list to be 284 associated with a list of authorized users who are authorized to 285 subscribe to the list. 287 REQ PC-17: It MUST be possible for a client to store a cached copy 288 of the list. It MUST be possible for the client to manipulate the 289 local cached copy even when there is no connectivity to the 290 server. It MUST be possible to synchronize the cached copy with 291 the master copy on the server, when connectivity is 292 re-established. 294 This particular requirement is crucial for wireless systems, where 295 a copy of the list resides on the handset. Without this 296 requirement, a user would not be able to view the list, or add a 297 user to it, when they go out of coverage. 299 REQ PC-18: It MUST be possible multiple clients to manipulate a 300 resource list without knowing of each other's actions. This 301 implies that it MUST be possible for the server to notify each 302 client of the changes if the client has indicated the need for the 303 change notifications. 305 REQ PC-19: Manipulations of the resource list MUST exhibit the ACID 306 property; that is, they MUST be atomic, be consistent, durable, 307 and operate independently. 309 REQ PC-20: It SHOULD be possible for the client to batch multiple 310 operations (add a presentity, remove a presentity) into a single 311 request that is processed atomically. 313 REQ PC-21: It MUST be possible for the server to authenticate the 314 client. 316 REQ PC-22: It SHOULD be possible to use the same database of client 317 credentials used with SIP and SIMPLE, with the data manipulation 318 protocol. 320 REQ PC-23: It MUST be possible for the client to authenticate the 321 server. 323 REQ PC-24: It MUST be possible for message integrity to be insured 324 between the client and the server. 326 REQ PC-25: It MUST be possible for confidentiality to be ensured 327 between the client and server. As a motivating example, an 328 eavesdropper on the protocol could ascertain the set of people in 329 my resource list, resulting in divulging private information. 331 REQ PC-26: It MUST be possible for the protocol to operate through 332 an intermediary, such as a proxy, to allow easier firewall 333 traversal. 335 6. Authorization Policy Manipulation 337 The following are the set of requirements for the protocol between 338 the client and the server for the purposes of manipulating presence 339 authorization policy. The requirements are divided between acceptance 340 policy, notification policy, and content policy. It is obvious that 341 these requirements would apply to other SIP event packages than 342 presence as well, but those are outside the scope of this document. 344 6.1 Acceptance Policy Requirements 345 REQ AP-1: It MUST be possible for the acceptance policy to support 346 rejection of the subscription if the watcher is present on a 347 specified list of 'blocked watchers'. When a list is checked in 348 this fashion, it is referred to as a blocked list. 350 REQ AP-2: It MUST be possible for the acceptance policy to support 351 rejection of the subscription if the watcher is not present on a 352 specified list of 'allowed watchers'. 354 REQ AP-3: It MUST be possible for the acceptance policy to support 355 making a subscription pending if the watcher is present on neither 356 an explicit allowed or blocked list. In that case, the watcher 357 info package [5] can be used for reactive authorization. 359 REQ AP-4: It MUST be possible for the acceptance policy to check 360 multiple blocked and allowed lists. 362 REQ AP-5: It SHOULD be possible for the policy to be based on the 363 means by which the authenticated identity of the watcher was 364 determined (digest vs. S/MIME, for example). 366 REQ AP-6: It SHOULD be possible for the policy to be based on 367 whether notifications can be sent encrypted to the subscriber. 369 REQ AP-7: It MUST be possible for authorized users to create, read, 370 modify and delete lists that are checked by the authorization 371 policy (e.g., the allowed and blocked lists). 373 REQ AP-8: It MUST be possible for authorized users to read, add, 374 remove and modify entries of the lists. 376 REQ AP-9: It MUST be possible for the lists to contain entries with 377 wildcards, e.g., allow everyone in a certain domain. 379 6.2 Notification Requirements 381 REQ N-1: It SHOULD be possible for the user to specify that 382 notifications are to be sent only when the value of a particular 383 status type changes. 385 REQ N-2: It SHOULD be possible for the user to specify that the 386 notifications are to be sent only when a particular status type 387 changes to a specified value or set of values. 389 REQ N-3: It SHOULD be possible for the user to specify that the 390 notifications are to be sent only when a particular status type 391 changes from a specified value to a specified value (e.g., from 392 open to closed). 394 REQ N-4: It SHOULD be possible for the user to specify that the 395 notifications are to be sent only when the value of the contact 396 address changes. 398 REQ N-5: It SHOULD be possible for the user to specify that the 399 notifications are not, or should be sent on changes in the state 400 of the subscription (as opposed to the state of the presentity). 402 6.3 Content Requirements 404 REQ C-1: The user MUST be able to specify that the notification 405 should only contain information for particular tuples. It SHOULD 406 be possible to use any presence attribute within a tuple as 407 criteria for this selection. 409 REQ C-2: It MUST be possible for the user to specify that the 410 notification should or should not contain a contact address. 412 REQ C-3: It MUST be possible for the user to specify that the 413 notification should contain only specific status types (such as 414 basic). 416 REQ C-4: The user MUST be able to specify the specific values of a 417 specific status type that the notification should or should not 418 contain. Values not permitted must result in the omission of that 419 status type. If all status is omitted, the tuple must be omitted 420 as well. As an example, a user can specify that the notification 421 should include tuples with OPEN status, but suppress those with 422 only CLOSED status. 424 REQ C-5: It MUST be possible for the user to specify different 425 values of the semantically identical presence information, such as 426 status attribute, to different watchers. It MUST be possible for 427 the user to give different level of detail of information to 428 different watchers. 430 The assumption is that the presentity also publishes the different 431 values separately (e.g. in separate tuples), so that the 432 authorization rules can simply select which (level of) information 433 to give to each watcher. 435 REQ C-6: It SHOULD be possible for the user to specify the specific 436 presence document to send to a watcher. 438 REQ C-7: It SHOULD be possible for the user to specify that the 439 notifications should be encrypted using S/MIME. 441 REQ C-8: It SHOULD be possible for the user to specify that a 442 particular tuple be added, removed or modified based on the value 443 of another tuple. As an example, a user might want to include 444 their IM tuple when their phone is busy, but not include it when 445 the phone is not busy. 447 6.4 General Requirements 449 These requirements apply to all of the three components of the 450 authorization policy. 452 REQ G-1: It MUST be possible for a client to store a cached copy of 453 the policies. It MUST be possible for the client to manipulate the 454 local cached copy even when there is no connectivity to the 455 server. It MUST be possible to synchronize the cached copy with 456 the master copy on the server, when connectivity is 457 re-established. 459 REQ G-2: It MUST be possible for multiple clients to manipulate the 460 same policies without knowing of each others' actions. This 461 implies that it MUST be possible for the server to notify each 462 client of the changes if the client has indicated the need for the 463 change notifications. 465 REQ G-3: Manipulations of the data MUST exhibit the ACID property; 466 that is, they MUST be atomic, be consistent, durable, and operate 467 independently. 469 REQ G-4: It MUST be possible to ensure that the authorization 470 policies are always consistent as a whole when transitioning from 471 one policy state to another. To enable this, it MUST be possible 472 for the client to batch multiple operations (remove a user from 473 one list, add the same user to another list) into a single request 474 that is processed atomically, or to otherwise ensure that the 475 policies are never left in an inconsistent state. 477 REQ G-5: It MUST be possible for the server to authenticate the 478 client. 480 REQ G-6: It SHOULD be possible to use the same database of client 481 credentials used with SIP and SIMPLE, with the data manipulation 482 protocol. 484 REQ G-7: It MUST be possible for the client to authenticate the 485 server. 487 REQ G-8: It MUST be possible for message integrity to be ensured 488 between the client and the server. 490 REQ G-9: It MUST be possible for confidentiality to be ensured 491 between the client and server. As a motivating example, an 492 eavesdropper on the protocol could ascertain the set of people in 493 my allowed list, resulting in divulging private information. 495 REQ G-10: It MUST be possible to extend the authorization policies 496 with new types of rules. 498 REQ G-11: It MUST be possible for a client to discover the types of 499 authorization policies the server can handle. 501 7. Security Considerations 503 There are many security considerations associated with the protocol 504 whose requirements are defined here. 506 The protocol is used to manipulate data that has a significant impact 507 on the operation of a service provided to a user. In particular, if 508 an attacker manipulates the data, the attacker can: 510 o convey information to subscribers that the presentity wishes to 511 keep private; 513 o launch denial of service attacks by flooding a subscriber with 514 more presence information than they expected; 516 o deny service to subscribers or to presentities. 518 To prevent these attacks, the protocol has to ensure than only 519 authorized users can manipulate the data. Requirements for 520 authentication and authorization are defined above. 522 Information conveyed in the protocol represents sensitive data. It 523 can include the content of resource lists and lists of blocked users, 524 both of which reveal personal preferences of a user that they do not 525 wish to convey. As a result, it is necessary that the client 526 authenticate the server, to be sure it is passing this information to 527 a trusted entity. It is also necessary for the protocol to provide 528 encryption services, so that eavesdroppers cannot inspect the data as 529 it passes by. 531 8. Acknowledgements 533 The authors would like to thank Paul Kyzivat, Ben Campbell, Krisztian 534 Kiss and Eva Leppanen for their input. 536 9. Changes from version 02 538 o Conventions chapter added. 540 o To-Do list removed. 542 o Presentity collection renamed resource list. 544 o Ordering of requirements 'rationalized'. 546 o References updated. 548 o Defined the scope to be explicitly limited to only resource list 549 and presence authorization policy requirements. 551 o Several requirements modified based on SIMPLE WG last call 552 comments by Ben Campbell and Krisztian Kiss. 554 Informative References 556 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 557 Levels", BCP 14, RFC 2119, March 1997. 559 [2] Day, M., "A model for presence and instant messaging", RFC 2778, 560 February 2000. 562 [3] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for 563 Presence", draft-ietf-simple-presence-10.txt, January 2003. 565 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 566 Notification", RFC 3265, June 2002. 568 [5] Rosenberg, J., "A Watcher Information Event Template-Package for 569 the Session Initiation Protocol (SIP)", 570 draft-ietf-simple-winfo-package-05.txt, January 2003. 572 [6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 573 Notification Extension for Resource Lists", 574 draft-ietf-simple-event-list-03.txt, May 2003. 576 [7] Peterson, J., "Common profile for presence (CPP)", 577 draft-ietf-impp-pres-03.txt, May 2003. 579 Authors' Addresses 581 Jonathan Rosenberg 582 Dynamicsoft 583 72 Eagle Rock Avenue 584 First Floor 585 East Hanover, NJ 07936 586 USA 588 Phone: 589 EMail: jdrosen@dynamicsoft.com 591 Markus Isomaki 592 Nokia Research Center 593 Itamerenkatu 11-13 594 00180 Helsinki 595 Finland 597 Phone: 598 EMail: markus.isomaki@nokia.com 600 Intellectual Property Statement 602 The IETF takes no position regarding the validity or scope of any 603 intellectual property or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; neither does it represent that it 607 has made any effort to identify any such rights. Information on the 608 IETF's procedures with respect to rights in standards-track and 609 standards-related documentation can be found in BCP-11. Copies of 610 claims of rights made available for publication and any assurances of 611 licenses to be made available, or the result of an attempt made to 612 obtain a general license or permission for the use of such 613 proprietary rights by implementors or users of this specification can 614 be obtained from the IETF Secretariat. 616 The IETF invites any interested party to bring to its attention any 617 copyrights, patents or patent applications, or other proprietary 618 rights which may cover technology that may be required to practice 619 this standard. Please address the information to the IETF Executive 620 Director. 622 Full Copyright Statement 624 Copyright (C) The Internet Society (2003). All Rights Reserved. 626 This document and translations of it may be copied and furnished to 627 others, and derivative works that comment on or otherwise explain it 628 or assist in its implementation may be prepared, copied, published 629 and distributed, in whole or in part, without restriction of any 630 kind, provided that the above copyright notice and this paragraph are 631 included on all such copies and derivative works. However, this 632 document itself may not be modified in any way, such as by removing 633 the copyright notice or references to the Internet Society or other 634 Internet organizations, except as needed for the purpose of 635 developing Internet standards in which case the procedures for 636 copyrights defined in the Internet Standards process must be 637 followed, or as required to translate it into languages other than 638 English. 640 The limited permissions granted above are perpetual and will not be 641 revoked by the Internet Society or its successors or assignees. 643 This document and the information contained herein is provided on an 644 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 645 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 646 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 647 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 648 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 650 Acknowledgment 652 Funding for the RFC Editor function is currently provided by the 653 Internet Society.