idnits 2.17.1 draft-ietf-simple-rpid-10.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1748. ** 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. 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 (December 20, 2005) is 6696 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 1630, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '11') (Obsoleted by RFC 5545) == Outdated reference: A later version (-07) exists of draft-ietf-simple-presence-data-model-06 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: June 23, 2006 V. Gurbani 5 Lucent 6 P. Kyzivat 7 J. Rosenberg 8 Cisco 9 December 20, 2005 11 RPID: Rich Presence Extensions to the Presence Information Data Format 12 (PIDF) 13 draft-ietf-simple-rpid-10 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 25 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 June 23, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The Presence Information Data Format (PIDF) defines a basic format 47 for representing presence information for a presentity. That format 48 defines a textual note, an indication of availability (open or 49 closed) and a Universal Resource Identifier (URI) for communication. 50 The Rich Presence Information Data format (RPID) described here is an 51 extension that adds optional elements to the Presence Information 52 Data Format (PIDF). These extensions provide additional information 53 about the presentity and its contacts. The information is designed 54 so that much of it can be derived automatically, e.g., from calendar 55 files or user activity. 57 This extension includes information about what the person is doing, a 58 grouping identifier for a tuple, when a service or device was last 59 used, the type of place a person is in, what media communications 60 might remain private, the relationship of a service tuple to another 61 presentity, the person's mood, the time zone it is located in, the 62 type of service it offers, an icon reflecting the presentity's status 63 and the overall role of the presentity. 65 These extensions include presence information for persons, services 66 (tuples) and devices. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology and Conventions . . . . . . . . . . . . . . . . 5 72 3. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2 Activities Element . . . . . . . . . . . . . . . . . . . . 8 75 3.3 Class Element . . . . . . . . . . . . . . . . . . . . . . 10 76 3.4 Device Identifier . . . . . . . . . . . . . . . . . . . . 10 77 3.5 Mood Element . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.6 Place-is Element . . . . . . . . . . . . . . . . . . . . . 13 79 3.7 Place-type Element . . . . . . . . . . . . . . . . . . . . 14 80 3.8 Privacy Element . . . . . . . . . . . . . . . . . . . . . 16 81 3.9 Relationship Element . . . . . . . . . . . . . . . . . . . 17 82 3.10 Service Class . . . . . . . . . . . . . . . . . . . . . 18 83 3.11 Sphere Element . . . . . . . . . . . . . . . . . . . . . 18 84 3.12 Status-Icon Element . . . . . . . . . . . . . . . . . . 19 85 3.13 Time Offset . . . . . . . . . . . . . . . . . . . . . . 19 86 3.14 User-Input Element . . . . . . . . . . . . . . . . . . . 20 87 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 5. XML Schema Definitions . . . . . . . . . . . . . . . . . . . 23 89 5.1 urn:ietf:params:xml:ns:pidf:rpid . . . . . . . . . . . . . 23 90 6. Extending RPID . . . . . . . . . . . . . . . . . . . . . . . 34 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 92 7.1 URN Sub-Namespace Registration for 93 'urn:ietf:params:xml:ns:pidf:rpid' . . . . . . . . . . . . 34 94 7.2 Schema Registration for Schema 95 urn:ietf:params:xml:ns:pidf:status:rpid' . . . . . . . . . 35 96 8. Internationalization Considerations . . . . . . . . . . . . 35 97 9. Security Considerations . . . . . . . . . . . . . . . . . . 36 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 10.1 Normative References . . . . . . . . . . . . . . . . . . 36 100 10.2 Informative References . . . . . . . . . . . . . . . . . 37 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 102 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 103 Intellectual Property and Copyright Statements . . . . . . . 40 105 1. Introduction 107 The Presence Information Data Format (PIDF) definition [9] describes 108 a basic presence information data format, encoded as an Extensible 109 Markup Language (XML) document, for exchanging presence information 110 in systems compliant with the common model for presence and instant 111 messaging [6]. It consists of a root element, zero or 112 more elements carrying presence information including a 113 Universal Resource Identifier (URI) for communication. zero or more 114 elements and zero or more extension elements from other name 115 spaces. Each tuple defines a basic status of either "open" or 116 "closed". 118 However, it is frequently useful to convey additional information 119 about a user that needs to be interpreted by an automata, and is 120 therefore not appropriate to be placed in the element of the 121 PIDF document. Therefore, this specification defines extensions to 122 the PIDF document format for conveying richer presence information. 123 Generally, the extensions have been chosen to provide features common 124 in existing presence systems at the time of writing, in addition to 125 elements that could readily be derived automatically from existing 126 sources of presence, such as calendaring systems or communication 127 devices, or sources describing the user's current physical 128 environment. 130 The presence data model [14] defines the concepts of service, device, 131 and person as the data elements that are used to model the state of a 132 presentity. (The term "presentity" is defined in RFC 2778 [6] and 133 abbreviates presence entity. A presentity provides presence 134 information to a presence service. It is typically a uniquely- 135 identified person.) Services are encoded using the element, 136 defined in PIDF; devices and persons are represented by the 137 and XML elements, respectively, defined in the the data 138 model [14]. However, neither PIDF nor the data model define presence 139 attributes beyond the status element. 141 This specification defines additional presence attributes to describe 142 person, service and device data elements, summarized as "Rich 143 Presence Information Data format for presence" (RPID). These 144 attributes are specified by XML elements which extend the PIDF 145 element and the and elements defined in the 146 data model. 148 This extension has two main goals: 150 1. Provide rich presence information that is at least as powerful as 151 common commercial presence systems. Such feature-parity 152 simplifies transition to systems complying with the Common 153 Profile for Instant Messaging (CPIM) [12], both in terms of user 154 acceptance and protocol conversion. 155 2. Maintain backwards-compatibility with PIDF, so that PIDF-only 156 watchers and gateways can continue to function properly, 157 naturally without access to the functionality described here. 159 We make no assumptions how the information in the RPID elements is 160 generated. Experience has shown that users are not always diligent 161 about updating their presence status. Thus, we want to make it as 162 easy as possible to derive RPID information from other information 163 sources, such as personal calendars, the status of communication 164 devices such as telephones, typing activity and physical presence 165 detectors as commonly found in energy-management systems. 167 Many of the elements correspond to data commonly found in personal 168 calendars. Thus, we attempted to align some of the extensions with 169 the usage found in calendar formats such as iCal [11]. 171 The information in a presence document can be generated by a single 172 entity or can be composed from information published by multiple 173 entities. 175 Note that PIDF documents and this extension can be used in two 176 different contexts, namely by the presentity to publish its presence 177 status and by the presence server to notify some set of watchers. 178 The presence server MAY compose, translate or filter the published 179 presence state before delivering customized presence information to 180 the watcher. For example, it may merge presence information from 181 multiple presence user agents, remove whole elements, translate 182 values in elements or remove information from elements. Mechanisms 183 that filter calls and other communications to the presentity can 184 subscribe to this presence information just like a regular watcher 185 and in turn generate automated rules, such as scripts [13], that 186 govern the actual communications behavior of the presentity. Details 187 are described in the data model document. 189 Since RPID is a PIDF XML document, it also uses the content type 190 application/pidf+xml. 192 2. Terminology and Conventions 194 This memo makes use of the vocabulary defined in the IMPP Model 195 document [6]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE 196 SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are 197 used in the same meaning as defined therein. 199 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 200 RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 201 as described in BCP 14, RFC 2119 [1]. 203 3. RPID Elements 205 3.1 Overview 207 Some of the RPID elements describe services, some devices, and some 208 the person. As such, they either extend , or 209 , respectively. Below, we summarize the RPID elements. The 210 next sections will then provide more detailed descriptions. 211 activities: The status element enumerates what the 212 person is doing. 213 class: An identifier that groups similar person elements, devices or 214 services. 215 device-id: A device identifier in a tuple references a 216 element, indicating that this device contributes to the service 217 described by the tuple. 218 mood: The status element indicates the mood of the person. 219 place-is: The status elements reports on the properties of 220 the place the presentity is currently at, such as the levels of 221 light and noise. 222 place-type: The status elements reports the type of 223 place the person is located in, such as 'classroom' or 'home'. 224 privacy: The element distinguishes whether the 225 communication service is likely to be observable by other parties. 226 relationship: When a service is likely to reach a user besides the 227 person associated with the presentity, the relationship indicates 228 how that user relates to the person. 229 service-class: The element describes whether the 230 service is delivered electronically, is a postal or delivery 231 service or describes in-person communications. 232 sphere: The element characterizes the overall current role 233 of the presentity. 234 status-icon: The element depicts the current status of 235 the person or service. 236 time-offset: The status element quantifies the time 237 zone the person is in, expressed as the number of minutes away 238 from UTC. 239 user-input: The element records the user-input or usage 240 state of the service or device, based on human user input. 242 The 'From/until?' column in Table 1 indicates by a 'x' that the 243 element can take 'from' and 'until' attributes. An 'x' in the 'Note' 244 column marks elements that can include a element. The usage 245 of these elements within the , and elements 246 is shown in columns 4 through 6. An 'x' in the respective column 247 indicates that the RPID element MAY appear as a child of that 248 element. 250 +------------+----------+----------+----------+----------+----------+ 251 | Element | From/unt | Note? | | | | 252 | | il? | | | | | 253 +------------+----------+----------+----------+----------+----------+ 254 | | | | | | | 256 | | | | x | x | x | 257 | | | | | | | 259 | | x | x | x | | | 260 | | x | x | x | | | 261 | | | | | | | 263 | | x | x | x | x | | 264 | | | | | | | 266 | | | | | | | 268 | | x | | x | | | 269 | | | | | | | 271 | | | | | | | 273 | | | | | | | 275 +------------+----------+----------+----------+----------+----------+ 277 Table 1 279 In general, it is unlikely that a presentity will publish or announce 280 all of these elements at the same time. Rather, these elements were 281 chosen to give the presentity maximum flexibility in deriving this 282 information from existing sources, such as calendaring tools, device 283 activity sensors or location trackers, as well as to manually 284 configure this information. In either case, there is no guarantee 285 that the information is accurate, as users forget to update calendars 286 or may not always adjust the presence information manually. 288 The namespace URIs for these elements defined by this specification 289 are URNs [2], using the namespace identifier 'ietf' defined by [5] 290 and extended by [7]: 292 urn:ietf:params:xml:ns:pidf:rpid 294 The elements marked with the value 'x' in column 2 of Table 1 MAY be 295 qualified with the 'from' and 'until' attributes to describe the 296 absolute time when the element assumed this value and the absolute 297 time until which is element is expected to be valid. Note that there 298 can be multiple elements of the same type, whose time ranges SHOULD 299 NOT overlap. 301 Elements MAY contain an 'id' attribute that allows to uniquely 302 reference the element. 304 Enumerations can be extended by elements from other namespaces, as 305 described in Section 6. The , and 306 elements can also take elements containing text, for custom 307 free-text values specific to an application. 309 All elements described in this document are optional within PIDF 310 documents. 312 3.2 Activities Element 314 The element describes what the person is currently 315 doing, expressed as an enumeration of activity-describing elements. 316 A person can be engaged in multiple activities at the same time, 317 e.g., traveling and having a meal. The element can be 318 quite helpful to the watcher in judging how appropriate a 319 communication attempt is and which means of communications is most 320 likely to succeed and not annoy the person. The activity indications 321 correspond roughly to the category field in calendar entries, such as 322 Section 4.8.1.2 of RFC 2445 [11]. 324 An activities enumeration consists of one or more elements using 325 elements drawn from the list below, a string enclosed in the 326 element or IANA-registered values from other namespaces (Section 7). 328 If a person publishes an activity of "permanent-absence", it is 329 likely that all services will report a status of CLOSED. In general, 330 services MAY advertise either service status for any activity value. 332 Activities such as , , , , 333 , , , , , or 334 can often be derived from calendar information. 336 appointment: The person has a calendar appointment, without 337 specifying exactly of what type. This activity is indicated if 338 more detailed information is not available or the person chooses 339 not to reveal more information. 340 away: The person is physically away from all interactive 341 communication devices. This activity element was included since 342 it can often be derived automatically from security systems, 343 energy management systems or entry badge systems. While this 344 activity would typically be associated with a status of CLOSED 345 across all services, a person may declare itself away to 346 discourage communication, but indicate that it still can be 347 reached if needed. However, communication attempts might reach an 348 answering service, for example. 349 breakfast: The person is eating the first meal of the day, usually 350 eaten in the morning. 351 busy: The person is busy, without further details. While this 352 activity would typically be associated with a status of CLOSED 353 across all services, a person may declare itself busy to 354 discourage communication, but indicate that it still can be 355 reached if needed. 356 dinner: The person is having his or her main meal of the day, eaten 357 in the evening or at midday. 358 holiday: This is a scheduled national or local holiday. 359 in-transit: The person is riding in a vehicle, such as a car, but not 360 steering. The element provides more specific 361 information about the type of conveyance the person is using. 362 looking-for-work: The presentity is looking for (paid) work. 363 lunch: The person is eating his or her midday meal. 364 meal: The person is scheduled for a meal, without specifying whether 365 it is breakfast, lunch or dinner, or some other meal. 366 meeting: The person is in an assembly or gathering of people, as for 367 a business, social, or religious purpose. A meeting is a sub- 368 class of an appointment. 369 on-the-phone: The person is talking on the telephone. This activity 370 is included since it can often be derived automatically. 371 other: The person is engaged in an activity with no defined 372 representation as an element. The enclosed string 373 describes the activity in plain text. 374 performance: A performance is a sub-class of an appointment and 375 includes musical, theatrical and cinematic performances as well as 376 lectures. It is distinguished from a meeting by the fact that the 377 person may either be lecturing or be in the audience, with a 378 potentially large number of other people, making interruptions 379 particularly noticeable. 380 permanent-absence: The person will not return for the foreseeable 381 future, e.g., because it is no longer working for the company. 382 This activity is associated with a status of CLOSED across all 383 services. 384 playing: The person is occupying himself or herself in amusement, 385 sport, or other recreation. 386 presentation: The person is giving a presentation, lecture, or 387 participating in a formal round-table discussion. 388 shopping: The person is visiting stores in search of goods or 389 services. 391 sleeping: This activity category can often be generated automatically 392 from a calendar, local time information or biometric data. 393 spectator: The person is observing an event, such as a sports event. 394 steering: The person is controlling a vehicle, ship or plane. 395 travel: The person is on a business or personal trip, but not 396 necessarily in-transit. 397 tv: The person is watching television. 398 unknown: The activity of the person is unknown. This element is 399 generally not used together with other activities. 400 vacation: A period of time devoted to pleasure, rest, or relaxation. 401 working: The presentity is engaged in, typically paid, labor, as part 402 of a profession or job. 403 worship: The presentity is participating in religious rites. 405 The element MAY be qualified with the 'from' and 'until' 406 attributes as described in Section 3.1. 408 Example: 410 411 Enjoying the morning paper 412 413 414 reading 415 417 3.3 Class Element 419 The element describes the class of the service, device or 420 person. Multiple elements can have the same class name within a 421 presence document, but each person, service or device can only have 422 one class label. The naming of classes is left to the presentity. 423 The presentity can use this information to group similar services, 424 devices or person elements or to convey information that the presence 425 agent can use for filtering or authorization. This information is 426 not generally presented to the watcher user interface. 428 The element MUST NOT be qualified with the 'from' and 'until' 429 attributes as described in Section 3.1. 431 3.4 Device Identifier 433 The element in the element references the device 434 that provides a particular service. The element is defined 435 syntactically in the data model [14] schema. One service can be 436 provided by multiple devices, so that each service tuple may contain 437 zero or more elements. There is no significance in the 438 order of these elements. 440 The element MUST NOT be qualified with the 'from' and 441 'until' attributes as described in Section 3.1. 443 3.5 Mood Element 445 The element describes the mood of the presentity. They are 446 enumerated chosen by the presentity. The mood itself is provided as 447 the element name of a defined child element of the element 448 (e.g., ); one such child element is REQUIRED. The user MAY 449 also specify a natural-language description of, or reason for, the 450 mood in the child of the element, which is OPTIONAL. 451 (This definition follows the Jabber Extension JEP-107.) It is 452 RECOMMENDED that an implementation support the mood values proposed 453 in Jabber Extension JEP-0107, which in turn are a superset of the 454 Wireless Village [16] mood values and the values enumerated in the 455 Affective Knowledge Representation that has been defined by Lisetti 456 [15]: 458 A mood enumeration consists of one or more elements using elements 459 drawn from the list below, a string enclosed in the element 460 or IANA-registered values from other namespaces (Section 7). 462 The element MAY be qualified with the 'from' and 'until' 463 attributes as described in Section 3.1. 464 afraid 465 amazed 466 angry 467 annoyed 468 anxious 469 ashamed 470 bored 471 brave 472 calm 473 cold 474 confused 475 contented 476 cranky 477 curious 478 depressed 479 disappointed 480 disgusted 481 distracted 482 embarrassed 483 excited 484 flirtatious 485 frustrated 486 grumpy 487 guilty 488 happy 489 hot 490 humbled 491 humiliated 492 hungry 493 hurt 494 impressed 495 in_awe 496 in_love 497 indignant 498 interested 499 invincible 500 jealous 501 lonely 502 mean 503 moody 504 nervous 505 neutral 506 offended 507 other 508 playful 509 proud 510 relieved 511 remorseful 512 restless 513 sad 514 sarcastic 515 serious 516 shocked 517 shy 518 sick 519 sleepy 520 stressed 521 surprised 522 thirsty 523 unknown 524 worried 526 Example: 528 529 I'm ready for the bar BOF! 530 531 532 534 3.6 Place-is Element 536 The element describes properties of the place the person 537 is currently at. This offers the watcher an indication what kind of 538 communication is likely to be successful. Each major media type has 539 its own set of attributes. Omitting the element indicates that the 540 property is unknown. 542 For audio, we define the following attributes: 544 noisy: The person is in a place with a level of background noise that 545 makes audio communications difficult. 546 ok: The environmental conditions are suitable for audio 547 communications. 548 quiet: The person is in a place such as a library, restaurant, place- 549 of-worship, or theater that discourages noise, conversation and 550 other distractions. 551 unknown: The place attributes for audio are unknown. 553 For video, we define the following attributes: 555 toobright: The person is in a bright place, sufficient for good 556 rendering on video. 557 ok: The environmental conditions are suitable for video. 558 dark: The person is in a dark place, and thus the camera may not be 559 be able to capture a good image. 560 unknown: The place attributes for video are unknown. 562 For text, we define the following attributes: 564 uncomfortable: Typing or other text entry is uncomfortable. 565 inappropriate: Typing or other text entry is inappropriate, e.g., 566 since the user is in a vehicle or house of worship. 567 ok: The environmental conditions are suitable for text-based 568 communications. 569 unknown: The place attributes for text are unknown. 571 This list can be augmented by free-text values in a note or 572 additional IANA-registered values (Section 7). 574 The element contains other elements, e.g., 576 577 580 583 585 The element MAY be qualified with the 'from' and 'until' 586 attributes as described in Section 3.1. 588 3.7 Place-type Element 590 The element describes the type of place the person is 591 currently at. This offers the watcher an indication what kind of 592 communication is likely to be appropriate. We define an initial set 593 of values below: 595 aircraft: The person is traveling in a plane, helicopter or balloon. 596 airport: The person is located in an airport, heliport or similar 597 location. 598 arena: The person is in an enclosed area used for sports events. 599 automobile: The person is in a self-propelled passenger vehicle. 600 bank: The person is in a business establishment in which money is 601 kept for saving or commercial purposes or is invested, supplied 602 for loans, or exchanged. 603 bar: The person is in a bar or saloon. 604 bus: The person is traveling in a public or charter bus. 605 bus-station: The person is in a terminal that serves bus passengers; 606 bus depot or bus terminal. 607 cafe: The person is in a cafe or coffeeshop. 608 classroom: The person is in an academic classroom or lecture hall. 609 club: The person is in a dance club or discotheque. 610 construction: The person is on a construction site. 611 convention-center: The person is in a convention center. 612 cycle: The person is riding a bicycle, motorcycle or similar vehicle. 613 government-building: The person is in a government building, such as 614 those used by the legislative, executive, or judicial branches of 615 governments, including court houses, police stations and military 616 installations. 618 hospital: The person is in a hospital, hospice, medical clinic, 619 mental institution, or doctor's office. 620 hotel: The person is in a hotel, motel, inn or other lodging 621 establishment. 622 industrial: The person is in an industrial setting, such as a 623 manufacturing floor or power plant. 624 library: The person is in a library or other public place which 625 literary and artistic materials, such as books, periodicals, 626 newspapers, pamphlets, prints, records, and tapes, are kept for 627 reading, reference, or lending. 628 office: The person is in a business setting, such as an office. 629 outdoors: The person is in a general outdoor area, such as a park or 630 city streets. 631 other: The person is in a place without a 632 representation. The enclosed string describes the type of place. 633 parking: The person is in a parking lot or parking garage. 634 place-of-worship: A building where congregations gather for religious 635 observances, such as a church, chapel, meetinghouse, mosque, 636 shrine, synagogue, or temple. 637 prison: The person is in a prison, penitentiary, jail, brig, or 638 criminal mental institution. 639 public: The person is in a public area such as a shopping mall, 640 street, park, public building, train station, airport or in public 641 conveyance such as a bus, train, plane or ship. This general 642 description encompasses the more precise descriptors "street", 643 "public-transport", "aircraft", "ship", "bus", "train", "airport", 644 "mall" and "outdoors". 645 public-transport: The person is using any form of public transport, 646 including aircraft, bus, train or ship. 647 residence: The person is in a private or residential setting, not 648 necessarily the personal residence of the person, e.g., a friend's 649 home. 650 restaurant: The person is in a restaurant or other public dining 651 establishment. 652 school: The person is in a school or university, but not necessarily 653 in a classroom or library. 654 shopping-area: The person is frequenting a shopping mall or shopping 655 area, i.e., a large, often enclosed shopping complex containing 656 various stores, businesses, and restaurants usually accessible by 657 common passageways. 658 stadium: The person is in a large, usually open structure for sports 659 events, including a racetrack. 660 store: The person is located in a place where merchandise is offered 661 for sale; a shop. 663 street: The person is walking in a street. 664 theater: The person is in a theater, lecture hall, auditorium, 665 circus, class room, movie theater or similar facility designed for 666 presentations, talks, plays, movies, music performances and other 667 events involving an audience. 668 train: The person is traveling in a train, monorail, maglev, cable 669 car or similar conveyance. 670 train-station: The person is in a terminal where trains load or 671 unload passengers or goods; railway station, railroad station, 672 railroad terminal, train depot. 673 truck: The person is in a truck, used primarily to carry goods rather 674 than people. 675 underway: The person is in a land, water, or air craft which is under 676 way (in motion). 677 unknown: The type of place is unknown. 678 warehouse: The person is in a place in which goods or merchandise are 679 stored; a storehouse or self-storage facility. 680 water: The person is on water, such as an ocean, lake, river, canal 681 or other waterway. 682 watercraft: The person is traveling in a boat or ship. 684 This list can be augmented by free-text values or additional IANA- 685 registered values (Section 7). 687 The element is a choice of elements, as in 689 690 691 693 The element MAY be qualified with the 'from' and 'until' 694 attributes as described in Section 3.1. 696 3.8 Privacy Element 698 The element indicates which types of communication third 699 parties in the vicinity of the presentity are unlikely to be able to 700 intercept accidentally or intentionally. This does not in any way 701 describe the privacy properties of the electronic communication 702 channel, e.g., properties of the encryption algorithm or the network 703 protocol used. 705 audio: Audio communication is likely only to be heard by the intended 706 recipient. 707 text: Inappropriate individuals are not likely to see text 708 communications. 709 unknown: This information is unknown. 710 video: Inappropriate individuals are not likely to see video 711 communications. 713 The element can be used by logic executing on the 714 watcher or by a composer to filter, sort and label tuples. For 715 example, a composer may have rules that limit the publication of 716 tuples labeled as "private" to a select subset of the watchers. 718 The element MAY be qualified with the 'from' and 'until' 719 attributes as described in Section 3.1. 721 Example: 723 724 725 728 3.9 Relationship Element 730 The element extends and designates the type of 731 relationship an alternate contact has with the presentity. This 732 element is provided only if the tuple refers to somebody other than 733 the presentity. Relationship values include "family", "friend", 734 "associate" (e.g., for a colleague), "assistant", "supervisor", 735 "self" and "unknown". The default is "self". 737 If a relationship is indicated, the URI in the element 738 refers to the entity, such as the assistant, that has a relationship 739 to the presentity, not the presentity itself. 741 Like tuples without a qualifier, the element 742 for tuples labeled with a relationship can contain either a 743 communication URI such as "im", "sip", "sips", "h323", "tel" or 744 "mailto", or a presence URI, such as "pres" or "sip". 746 Example: 748 749 750 752 3.10 Service Class 754 The element extends and designates the type 755 of service offered. 757 electronic: Delivery of information by electronic means, i.e., 758 without delivering physical objects. Examples include telephone, 759 fax, email, instant messaging, and SMS. 760 postal: Delivery by the postal service, e.g., as a letter, parcel or 761 postcard. Delivery could be to a post office box or central mail 762 room rather than the presentity's office location, for example. 763 courier: Delivery by messenger, overnight delivery or courier. 764 Courier-delivered messages are usually delivered to a receptionist 765 rather than, say, a mailroom or receiving department. 766 freight: Delivery by freight carrier, typically of larger objects 767 that are not sent by postal mail or courier. The recipient is 768 often the shipping department or a loading dock. 769 in-person: Describes the coordinates for visits in person, as by a 770 visitor, i.e., usually somebody's office or residence. 771 unknown: The type of service is unknown. 773 Electronic service is implied if omitted. The service types 774 'postal', 'courier', 'freight' and 'in-person' MUST NOT be used 775 unless the contact URI is empty. Additional data elements defined 776 elsewhere describe the physical service delivery address for the in- 777 person, postal or delivery services. Such addresses might be 778 specified in geospatial coordinates, civic addresses or some 779 specialized address format, e.g., for interstellar addresses or a 780 company-specific delivery system. 782 Example: 784 786 3.11 Sphere Element 788 The element designates the current state and role that the 789 person plays. For example, it might describe whether the person is 790 in a work mode or at home or participating in activities related to 791 some other organization such as the IETF or a church. This document 792 does not define names for these spheres except for two common ones, 793 "work" and "home", as well as "unknown". 795 Spheres allow the person to easily turn on or off certain rules that 796 depend on what groups of people should be made aware of the person's 797 status. For example, if the person is a Boy Scout leader, he might 798 set the sphere to "scouting" and then have a rule set that allows 799 other scout masters in his troop to see his presence status. As soon 800 as he switches his status to "work" or "home" or some other sphere, 801 the fellow scouts would lose access. 803 The element MAY be qualified with the 'from' and 'until' 804 attributes as described in Section 3.1. 806 Example: 808 809 810 812 3.12 Status-Icon Element 814 The element includes a URI pointing to an image (icon) 815 representing the current status of the person or service. The 816 watcher MAY use this information to represent the status in a 817 graphical user interface. Presentities SHOULD provide images of 818 sizes and aspect ratios that are appropriate for rendering as an 819 icon. Support for JPEG, PNG and GIF formats is RECOMMENDED. 821 Watchers resolving the URI MUST validate whether the local copy of 822 the icon is current when receiving a notification, using the standard 823 cache control mechanism in the URI-identified retrieval protocol. 825 Example: 827 http://www.example.com/playing.gif 829 3.13 Time Offset 831 The element describes the number of minutes of offset 832 from UTC at the person's current location. A positive number 833 indicates that the local time-of-day is ahead (i.e., east of) 834 Universal Time, while a negative number indicates that the local 835 time-of-day is behind (i.e., west of) Universal Time. Transitions 836 into and out of daylight savings time may temporarily cause a 837 difference between the true offset from UTC and the time offset 838 element. 840 An optional attribute, description, can be used to describe the 841 offset, e.g., by labeling the time zone. This description is meant 842 for human consumption. 844 Publishers on mobile devices SHOULD NOT publish this information 845 unless they know the time offset information to reflect the current 846 location. (For example, many laptop users do not update their time 847 zone when traveling.) Publishers SHOULD update the information 848 whenever they discover that their UTC offset has changed. 850 Example: 852 -300 853 855 3.14 User-Input Element 857 The element records the user-input or usage state of the 858 service or device, based on human user input, e.g., keyboard, 859 pointing device or voice. If contained in a element, it 860 summarize any user input activity across all services and devices 861 operated by the presentity. The mechanism for such aggregation is 862 beyond the scope of this document, but generally reflects the most 863 recent user input across all devices and services. The element can 864 assume one of two values, namely 'active' or 'idle', with an optional 865 'last-input' attribute that records when the last user input has been 866 received. An optional 'idle-threshold' element records how long the 867 presentity will wait before reporting the service or device to be 868 idle, measured in seconds. 870 (A two-state model was chosen since it would otherwise be necessary 871 to send repeated last-input updates during continuous activity.) 873 A service that wants to indicate user input activity sends a 'active' indication when the user has provided user input 875 within a configurable interval of time, the idle-threshold. If the 876 user ceases to provide input and the idle threshold has elapsed, the 877 tuple is marked with a 'idle' indication instead, 878 optionally including the time of last activity in the 'last-input' 879 attribute. An example is below: 881 idle 884 Depending on device or service capabilities, user input may be 885 detected only for a particular application, i.e., when the 886 application has user focus or when a user has sent a message or 887 placed a call, or can be based on user input across all applications 888 running on one end system. 890 The element may be used by a watcher, typically in 891 combination with other data, to estimate how likely a user is to 892 answer when contacting the service. A tuple that has not been used 893 in a while may still be OPEN, but a watcher may choose to first 894 contact a URI in a tuple that is both OPEN and has been used more 895 recently. 897 The attribute can be omitted if the presentity wants to 898 indicate that the device has not been used for a while, but does not 899 want to reveal the precise duration, as in: 901 idle 903 Configuration MUST include the option to omit the 'last-input' 904 attribute. 906 4. Example 908 The example below describes the presentity 909 'pres:someone@example.com', which has a SIP contact, 910 'sip:someone@example.com', representing a service. It also has a 911 device contact, as an email box. The presentity is in a meeting, in 912 a public office setting. The 'until' information indicates that he 913 will be there until 5.30 pm local time. The presentity also has an 914 assistant, sip:secretary@example.com, who happens to be available for 915 communications. 917 918 927 928 929 open 930 931 urn:device:0003ba4811e3 932 933 934 im:someone@mobile.example.net 935 Don't Disturb Please! 936 Ne derangez pas, s'il vous plait 937 2005-10-27T16:49:29Z 938 940 941 942 open 943 944 945 mailto:secretary@example.com 946 948 949 950 open 951 952 urn:x-mac:0003ba4811e3 953 email 954 955 http://example.com/mail.png 956 mailto:someone@example.com 957 959 I'll be in Tokyo next week 961 962 idle 964 urn:device:0003ba4811e3 965 PC 966 968 969 971 Far away 972 974 975 calendar 976 977 978 brooding 979 980 981 982 983 984 985 986 987 bowling league 988 http://example.com/play.gif 989 -240 990 Scoring 120 991 2005-05-30T16:09:44+05:00 992 993 995 5. XML Schema Definitions 997 The RPID schema is shown below. Due to limitations in composing 998 schemas, not all XML documents that validate against the schema below 999 are semantically valid RPID documents. In particular, the schema 1000 allows each element to appear anyhere in PIDF or data-model elements; 1001 Table 1 restricts where these elements can appear for semantically 1002 valid RPID documents. Elements that do not have from/until 1003 parameters MUST NOT appear more than once in each , 1004 or . 1006 5.1 urn:ietf:params:xml:ns:pidf:rpid 1008 1009 1016 1018 1019 1020 1021 1022 1023 1025 1026 1027 1028 Describes what the person is currently doing, expressed as 1029 an enumeration of activity-describing elements. A person 1030 can be engaged in multiple activities at the same time, 1031 e.g., traveling and having a meal. 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1043 1045 1047 1049 1051 1053 1055 1057 1059 1061 1063 1065 1067 1069 1071 1073 1075 1077 1079 1081 1083 1085 1087 1089 1091 1093 1094 1095 1096 1097 1098 1099 1100 1101 1103 1104 1105 1106 Describes the class of the service, device or person. 1107 1108 1109 1111 1112 1113 1114 Describes the mood of the presentity. 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1126 1128 1130 1132 1134 1136 1138 1140 1142 1144 1146 1148 1150 1152 1154 1156 1158 1161 1163 1165 1167 1169 1171 1173 1175 1177 1179 1181 1183 1185 1187 1189 1191 1193 1195 1197 1199 1201 1203 1205 1207 1210 1212 1214 1216 1218 1220 1222 1224 1226 1228 1230 1232 1234 1236 1238 1240 1242 1244 1246 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1298 1299 1300 1301 Describes the type of place the person is currently at. 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1354 1355 1356 1357 1358 1359 1360 1362 1363 1364 1365 Indicates which type of communication third parties in the 1366 vicinity of the presentity are unlikely to be able to 1367 intercept accidentally or intentionally. 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1381 1382 1383 1384 1385 1386 1387 1388 1390 1391 1392 1393 Designates the type of relationship an alternate contact 1394 has with the presentity. 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1411 1412 1413 1414 1416 1417 1418 1419 Designates the type of service offered. 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1434 1435 1436 1437 1439 1440 1441 1442 Designates the current state and role that the person plays. 1443 1444 1445 1446 1447 1448 1449 1450 1452 1453 1454 1455 1456 1457 1459 1460 1461 1462 A URI pointing to an image (icon) representing the current 1463 status of the person or service. 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1477 1478 1479 1480 Describes the number of minutes of offset from UTC at the 1481 user's current location. 1482 1483 1484 1485 1486 1487 1488 1490 1491 1492 1493 1494 1495 1497 1498 1499 1500 Records the user-input or usage state of the service or 1501 device. 1502 1503 1504 1505 1506 1507 1509 1510 1511 1513 1514 1515 1516 1517 1519 6. Extending RPID 1521 Any developer can introduce their own element names, avoiding 1522 conflict by choosing an appropriate namespace URI. To add new 1523 standardized elements to the enumerations , , 1524 , , and , the 1525 extension process described in PIDF [9] is followed, i.e., such 1526 extensions would use namespace designators such as 1527 urn:ietf:params:xml:ns:pidf:ext, where 'ext' is the name of the 1528 extension. 1530 7. IANA Considerations 1532 7.1 URN Sub-Namespace Registration for 1533 'urn:ietf:params:xml:ns:pidf:rpid' 1535 URI: urn:ietf:params:xml:ns:pidf:rpid 1536 Description: This is the XML namespace for XML elements defined by 1537 RFCXXXX [RFC editor: replace with RFC number] to describe rich 1538 presence information extensions for the status element in the PIDF 1539 presence document format in the application/pidf+xml content type. 1541 Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 1542 Henning Schulzrinne, hgs@cs.columbia.edu 1543 XML: 1545 BEGIN 1546 1547 1549 1553 RPID: Rich Presence: Extensions to the Presence 1554 Information Data Format (PIDF) 1555 1556 1557

Namespace for rich presence extension

1558

urn:ietf:params:xml:ns:pidf:rpid

1559

See RFC&rfc.number; [RFC 1560 editor: replace with RFC number].

1561 1562 1563 END 1565 7.2 Schema Registration for Schema 1566 urn:ietf:params:xml:ns:pidf:status:rpid' 1568 URI: please assign 1569 Registrant Contact: IESG 1570 XML: See Section 5 1572 Note that this document does not need a new content type. It 1573 inherits the content type from [9], namely application/pidf+xml. 1575 8. Internationalization Considerations 1577 RPID contains mostly tokens that are meant for consumption by 1578 programs, not directly by humans. Programs are expected to translate 1579 those tokens into language-appropriate text strings according to the 1580 preferences of the watcher. 1582 Some elements may contain and elements that can 1583 contain free text. These elements SHOULD be labeled with the 'xml: 1584 lang' attribute to indicate their language and script. The 1585 specification allows multiple occurrences of these elements so that 1586 the presentity can convey and elements in multiple 1587 scripts and languages. If no 'xml:lang' attribute is provided, the 1588 default value is "i-default" [3]. 1590 Since RPID is represented in XML, it provides native support for 1591 encoding information using the Unicode character set and its more 1592 compact representations including UTF-8. Conformant XML processors 1593 recognize both UTF-8 and UTF-16. Though XML includes provisions to 1594 identify and use other character encodings through use of an 1595 "encoding" attribute in an declaration, use of UTF-8 is 1596 RECOMMENDED in environments where parser encoding support 1597 incompatibility exists. 1599 A description of time-zone considerations can be found in 1600 Section 3.13. 1602 9. Security Considerations 1604 The security considerations in [9] apply, as well as [8]. Compared 1605 to PIDF, this presence document format reveals additional information 1606 about presentities that can be highly sensitive. Beyond traditional 1607 security measures to protect confidentiality and integrity, systems 1608 should offer a means to selectively reveal information to particular 1609 watchers and to inspect the information that is being published, 1610 particularly if it is generated automatically from other sources, 1611 such as calendars or sensors. 1613 Like any reference to an external object, the may allow 1614 the presentity to induce the watcher to retrieve data from a third 1615 party (content indirection attack), thus either retrieving harmful 1616 content or adding to the server load of the referenced resource. 1618 10. References 1620 10.1 Normative References 1622 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1623 Levels", BCP 14, RFC 2119, March 1997. 1625 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 1627 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 1628 BCP 18, RFC 2277, January 1998. 1630 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1631 Considerations Section in RFCs", BCP 26, RFC 2434, 1632 October 1998. 1634 [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1635 August 1999. 1637 [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1638 and Instant Messaging", RFC 2778, February 2000. 1640 [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1641 January 2004. 1643 [8] Rosenberg, J., "A Presence Event Package for the Session 1644 Initiation Protocol (SIP)", RFC 3856, August 2004. 1646 [9] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 1647 J. Peterson, "Presence Information Data Format (PIDF)", 1648 RFC 3863, August 2004. 1650 [10] W3C, "Extensible Markup Language (XML) 1.0", W3C 1651 Recommendation XML 1.0, February 1998. 1653 10.2 Informative References 1655 [11] Dawson, F. and Stenerson, D., "Internet Calendaring and 1656 Scheduling Core Object Specification (iCalendar)", RFC 2445, 1657 November 1998. 1659 [12] Peterson, J., "Common Profile for Instant Messaging (CPIM)", 1660 RFC 3860, August 2004. 1662 [13] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 1663 Language (CPL): A Language for User Control of Internet 1664 Telephony Services", RFC 3880, October 2004. 1666 [14] Rosenberg, J., "A Data Model for Presence", 1667 draft-ietf-simple-presence-data-model-06 (work in progress), 1668 October 2005. 1670 [15] Lisetti, C., "Personality, Affect, and Emotion Taxonomy for 1671 Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002. 1673 [16] Open Mobile Alliance, "The Wireless Village Initiative: 1674 Presence Attributes 1.1", Recommendation WV-29, 2004. 1676 Authors' Addresses 1678 Henning Schulzrinne 1679 Columbia University 1680 Department of Computer Science 1681 450 Computer Science Building 1682 New York, NY 10027 1683 US 1685 Phone: +1 212 939 7042 1686 Email: hgs+simple@cs.columbia.edu 1687 URI: http://www.cs.columbia.edu 1689 Vijay Gurbani 1690 Lucent 1691 2000 Naperville Rd. 1692 Room 6G-440 1693 Naperville, IL 60566-7033 1694 US 1696 Email: vkg@lucent.com 1698 Paul Kyzivat 1699 Cisco Systems 1700 BXB500 C2-2 1701 1414 Massachusetts Avenue 1702 Boxborough, MA 01719 1703 US 1705 Email: pkyzivat@cisco.com 1707 Jonathan Rosenberg 1708 Cisco Systems 1709 600 Lanidex Plaza 1710 Parsippany, NJ 07054-2711 1711 US 1713 Email: jdrosen@cisco.com 1715 Appendix A. Acknowledgements 1717 The document reflects the discussion on the SIMPLE mailing list, with 1718 contributions from many individuals. David L. Black, Aki Niemi, 1719 Miguel Garcia, Avshalom Houri, Markus Isomaki, Rick Jones, Hisham 1720 Khartabil, Paul Kyzivat, Jonathan Lennox, Eva-Maria Leppanen, Mikko 1721 Lonnfors, Rohan Mahy, Miguel Marcia, Andrew Newton, Jon Peterson and 1722 Brian Rosen provided detailed comments and suggestions. Xiaotao Wu 1723 assisted with schema testing. Jari Urpalainen provided valuable 1724 advice on XML schema issues. 1726 Intellectual Property Statement 1728 The IETF takes no position regarding the validity or scope of any 1729 Intellectual Property Rights or other rights that might be claimed to 1730 pertain to the implementation or use of the technology described in 1731 this document or the extent to which any license under such rights 1732 might or might not be available; nor does it represent that it has 1733 made any independent effort to identify any such rights. Information 1734 on the procedures with respect to rights in RFC documents can be 1735 found in BCP 78 and BCP 79. 1737 Copies of IPR disclosures made to the IETF Secretariat and any 1738 assurances of licenses to be made available, or the result of an 1739 attempt made to obtain a general license or permission for the use of 1740 such proprietary rights by implementers or users of this 1741 specification can be obtained from the IETF on-line IPR repository at 1742 http://www.ietf.org/ipr. 1744 The IETF invites any interested party to bring to its attention any 1745 copyrights, patents or patent applications, or other proprietary 1746 rights that may cover technology that may be required to implement 1747 this standard. Please address the information to the IETF at 1748 ietf-ipr@ietf.org. 1750 Disclaimer of Validity 1752 This document and the information contained herein are provided on an 1753 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1754 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1755 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1756 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1757 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1760 Copyright Statement 1762 Copyright (C) The Internet Society (2005). This document is subject 1763 to the rights, licenses and restrictions contained in BCP 78, and 1764 except as set forth therein, the authors retain all their rights. 1766 Acknowledgment 1768 Funding for the RFC Editor function is currently provided by the 1769 Internet Society.