idnits 2.17.00 (12 Aug 2021) /tmp/idnits27764/draft-ietf-simple-rpid-02.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.5 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 799. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 815), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 148 characters in excess of 72. ** There are 70 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 (March 13, 2004) is 6643 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: '9' is defined on line 714, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 721, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 724, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 728, 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. '3') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '5') == Outdated reference: draft-ietf-impp-cpim-pidf has been published as RFC 3863 == Outdated reference: draft-ietf-simple-presence has been published as RFC 3856 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '9') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '10') (Obsoleted by RFC 5545) == Outdated reference: draft-ietf-iptel-cpl has been published as RFC 3880 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 7 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: September 11, 2004 V. Gurbani 5 Lucent 6 P. Kyzivat 7 Cisco 8 J. Rosenberg 9 dynamicsoft 10 March 13, 2004 12 RPID: Rich Presence: Extensions to the Presence Information Data 13 Format (PIDF) 14 draft-ietf-simple-rpid-02 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3667. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as 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 http:// 33 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 11, 2004. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 The Rich Presence Information Data Format (RPID) adds elements to the 47 Presence Information Data Format (PIDF) that provide additional 48 information about the presentity and its contacts. The information 49 is designed so that much of it can be derived automatically, e.g., 50 from calendar files or user activity. 52 This extension includes information about what the presentity is 53 doing (the activity element), a grouping identifier for a tuple (the 54 class element), the type of tuple (the contact-type element), whether 55 a contact is idle (the idle element), the typle of place a presentity 56 is in (the placetype element), whether the presentity is in a public 57 or private space (the privacy element), the relationship of a tuple 58 to another presentity (the relationship element), and the overall 59 role of the presentity (the sphere element). 61 Table of Contents 63 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 65 3. The Meaning of "open" and "closed" . . . . . . . . . . . . . . 3 66 4. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4.2 Activities Element . . . . . . . . . . . . . . . . . . . . . . 4 69 4.3 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.4 Contact-Type Element . . . . . . . . . . . . . . . . . . . . . 6 71 4.5 Idle Element . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.6 Type of Place Element . . . . . . . . . . . . . . . . . . . . 7 73 4.7 Privacy Element . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.8 Relationship Element . . . . . . . . . . . . . . . . . . . . . 8 75 4.9 Sphere Element . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1 Presentity with Activity . . . . . . . . . . . . . . . . . . . 9 78 6. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 10 79 6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple . . . . . . . . . . . . 11 80 6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7.1 URN Sub-Namespace Registration for 83 'urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . . . 13 84 7.2 URN Sub-Namespace Registration for 85 'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 14 86 7.3 Schema Registration for Schema 87 urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 15 88 7.4 Schema Registration for Schema 89 urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . . . 15 90 7.5 Token Registrations . . . . . . . . . . . . . . . . . . . . . 15 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 Normative References . . . . . . . . . . . . . . . . . . . . . 16 93 Informative References . . . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 95 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 96 Intellectual Property and Copyright Statements . . . . . . . . 19 98 1. Scope 100 The Presence Information Data Format (PIDF) defines a basic format 101 for representing presence information for a presentity. That format 102 defines a textual note, an indication of availability (open or 103 closed) and a URI for communication. However, it is frequently 104 useful to convey additional information about a user that needs to be 105 interpreted by an automata, and is therefore not appropriate for 106 placement in the note element of the PIDF document. This document 107 defines extensions to the PIDF document format for conveying richer 108 presence information. Generally, the extensions have been chosen to 109 provide features common in existing presence systems at the time of 110 writing, in addition to elements that could readily be derived 111 automatically from existing sources of presence, such as calendaring 112 systems, or sources describing the user's current physical 113 environment. 115 2. Terminology and Conventions 117 This memo makes use of the vocabulary defined in the IMPP Model 118 document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE 119 SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are 120 used in the same meaning as defined therein. The key words MUST, 121 MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and 122 OPTIONAL in this document are to be interpreted as described in BCP 123 14, RFC 2119 [1]. 125 3. The Meaning of "open" and "closed" 127 PIDF describes the basic status values of "open" or "closed" only as 128 "have meanings of general availability for other communications 129 means". We define "closed" in our context as meaning that 130 communication to the contact address will in all likelihood not 131 succeed, is undesired or will not reach the intended party. (For 132 example, a presentity may include a hotel phone number as a contact. 133 After check-out, the phone number will still ring, but reach the 134 chambermaid or the next guest. Thus, it would be declared "closed".) 135 For "pres" contacts, "closed" means that no presence status 136 information is available. 138 4. RPID Elements 140 4.1 Introduction 142 Below, we describe the RPID elements in detail. , 143 , and extend the PIDF element, 144 while , and extend the PIDF 145 element. 147 In general, it is highly unlikely that a presentity will publish or 148 announce all of these elements at the same time. Rather, these 149 elements were chosen to give the presentity maximum flexibility in 150 deriving this information from existing sources, such as calendaring 151 tools, device activity sensors or location trackers, as well as to 152 manually configure this information. 154 The namespace URIs for these elements defined by this specification 155 are URNs [2], using the namespace identifier 'ietf' defined by [4] 156 and extended by [6]: 158 urn:ietf:params:xml:ns:pidf:status:rpid-status 159 urn:ietf:params:xml:ns:pidf:status:rpid-tuple 161 This document uses a separate namespace for extending the PIDF 162 'status' namespace, in accordance with Section 4.2.5 of [7]. 164 All elements described in this document are optional. 166 The elements , , and MAY be 167 qualified with the 'since' and 'until' attributes to describe the 168 absolute time when the element assumed this value and the absolute 169 time until which is element is expected to be valid. The 'since' 170 time MUST be in the past, the 'until' time in the future relative to 171 the time of publication of the presence information and, if 172 available, the PIDF 'timestamp' element. 174 4.2 Activities Element 176 The element describes what the presentity is currently 177 doing. This can be quite helpful to the watcher in judging how 178 appropriate a communication attempt is and which means of 179 communications is most likely to succeed and not annoy the 180 presentity. The activity indications correspond roughly to the 181 category field in calendar entries, such as Section 4.8.1.2 of RFC 182 2445 [10]. 184 An activity enumeration consists of one or more values drawn from the 185 list below, any other token string or IANA-registered values (Section 186 Section 7). 188 Depending on the presentity intent, all but the "permanent-absence" 189 indication can be used with either status OPEN or CLOSED. 191 on-the-phone: The presentity is talking on the telephone. This 192 activity is included since it can often be derived automatically. 193 away: The presentity is physically away from the device location. 194 This activity was included since it can often be derived 195 automatically from security systems, energy management systems or 196 entry badge systems. 197 appointment: The presentity has a calendar appointment, without 198 specifying exactly of what type. This activity is indicated if 199 more detailed information is not available or the presentity 200 choses not to reveal more information. 201 holiday: This is a scheduled national or local holiday. This 202 information can typically be derived automatically from calendars. 203 meal: The presentity is scheduled for a meal. This activity category 204 can often be generated automatically from a calendar. 205 meeting: A meeting is a sub-class of an appointment. This activity 206 category can often be generated automatically from a calendar. 207 steering: The presentity is controlling a vehicle, ship or plane. 208 in-transit: The presentity is riding in a vehicle, such as a car, but 209 not steering. The 'placetype' element provides more specific 210 information about the type of conveyance the presentity is using. 211 travel: The presentity is on a business or personal trip, but not 212 necessarily in-transit. This category can often be generated 213 automatically from a calendar. 214 vacation: Leisure travel. This activity category can often be 215 generated automatically from a calendar. 216 sleeping: This activity category can often be generated automatically 217 from a calendar, local time information or biometric data. 218 busy: User is busy, without further details. While this activity 219 would typically be associated with a status of CLOSED, a 220 presentity may declare itself busy to discourage communication, 221 but indicate that it still can be reached if needed. 222 permanent-absence: Presentity will not return for the foreseeable 223 future, e.g., because it is no longer working for the company. 224 This activity is associated with a status of CLOSED. 226 The element MAY be qualified with the 'since' and 'until' 227 attributes as described in Section 4. 229 The element can be used with tuples of all values of 230 . For tuples consisting of multiple physical devices, 231 i.e., of 'service' or 'presentity', these components 232 can engage in multiple types of activities, particularly if qualified 233 by a element. In those cases, the 234 element enumerates all unique values as child elements. 236 The element can be extended by adding elements from 237 other namespaces, e.g., to reflect activities appropriate for a 238 particular occupation. 240 4.3 Class 242 The 'class' attribute describes the class of the tuple. Multiple 243 tuples can have the same class name within a presence document. The 244 naming of classes is left to the presentity. The presentity can use 245 this information to group similar tuples or to convey information 246 that the presence agent can use for filtering. 248 4.4 Contact-Type Element 250 The element describes the type of the tuple. A tuple 251 can represent a communication facility ("device"), a face-to-face 252 communication tuple ("in-person"), a set of devices offering a common 253 service ("service"), or a whole presentity ("presentity"). 254 Additional types can be registered with IANA. 256 4.5 Idle Element 258 For tuples representing a single device, i.e., having a 259 of 'device', the element records the absolute 260 time and date the communication device was last used. This provides 261 an indication as to how likely a user is to answer when contacting 262 that device. A device that has not been used in a while may still be 263 OPEN, but a watcher may choose to first contact a device that is both 264 OPEN and has been used more recently. Note that the idle time refers 265 to the whole device, not just the particular service. For example, a 266 tuple describing an instant messaging device expresses the last time 267 that the PC or PDA was used, not the last time an instant message has 268 been sent. 270 For tuples representing a 'presentity' or 'service' with multiple 271 devices, the device with the most recent usage, i.e., the shortest 272 idle time, determines the idle time for the whole tuple. 274 The use of 'idle' for tuples with contact-type 'in-person' is not 275 defined. 277 The element can be empty if the presentity wants to indicate 278 that the device has not been used for a while, but does not want to 279 reveal the precise duration, as in: 281 283 The element SHOULD be included in the presence document if the 284 idle time exceeds a user-setable threshold, with a RECOMMENDED 285 default value of 10 minutes. Configuration MUST include the option 286 to omit the timestamp. 288 4.6 Type of Place Element 290 The element describes the type of place the presentity is 291 currently at. This offers the watcher an indication what kind of 292 communication is likely to be appropriate. We define an initial set 293 of values below: 295 home: The presentity is in a private or residential setting, not 296 necessarily the personal residence of the presentity, e.g., 297 including hotel or a friend's home. 298 office: The presentity is in a business setting, such as an office. 299 quiet: The presentity is in a place such as a library, restaurant, 300 place-of-worship, or theater that discourages noise, conversation 301 and other distractions. 302 public: The presentity is in a public area such as a shopping mall, 303 street, park, public building, train station, airport or in public 304 conveyance such as a bus, train, plane or ship. This general 305 description encompasses the more precise descriptors 'street', 306 'public-transport', 'aircraft', 'ship', 'bus', 'train', 'airport', 307 'mall' and 'outdoors' below. 308 street: Walking in a street. 309 public-transport: Any form of public transport, including aircraft, 310 bus, train or ship. 311 aircraft: The presentity is in a plane, helicopter or balloon. 312 ship: Water vessel, boat. 313 bus: Public or charter bus. 314 train: The presentity is traveling in a train, monorail, maglev, 315 cable car or similar conveyance. 316 airport: Airport, heliport or similar location. 317 station: Bus or train station. 318 mall: Shopping mall or shopping area. 319 outdoors: General outdoors area, such as a park or city streets. 321 This list can be augmented by free-text values or additional 322 IANA-registered values (Section Section 7). 324 The element can be used with tuples of all values of 325 . For tuples consisting of multiple physical devices, 326 i.e., of 'service' or 'presentity', these devices can 327 be in multiple types of places. In those cases, the 328 element enumerates all unique values as a token list. 330 The element MAY be qualified with the 'since' and 'until' 331 attributes as described in Section 4. 333 4.7 Privacy Element 335 The 'privacy' element indicates whether third parties may be able to 336 hear or view parts of the communication. 338 public: Others may be able to see or hear the communications. 339 private: Inappropriate individuals are not likely to see or hear the 340 communications. 342 This indication is not limited to voice communications. For example, 343 a presentity might label her privacy as "quiet" when giving a talk, 344 since it would be inappropriate if an instant message popped up on 345 the laptop screen that is being projected for the audience. 347 The 'placetype' element MAY be qualified with the 'since' and 'until' 348 attributes as described in Section 4. 350 4.8 Relationship Element 352 The element extends and designates the type of 353 relationship an alternate contact has with the presentity. This 354 element is provided only if the tuple refers to somebody other than 355 the presentity. Relationship values include "family", "associate" 356 (e.g., for a colleague), "assistant", "supervisor". Other free-text 357 values and additional IANA-registered values (Section 7) can be used 358 as well. 360 If a relationship is indicated, the RPID values describe the 361 , not the presentity. 363 The element for tuples labeled with a relationship can 364 contain either a communication URI such as "im", "sip"/"sips", 365 "h323", "tel" or "mailto", or a presence URI, such as "pres" or 366 "sip". 368 4.9 Sphere Element 370 The element designates the current state and role that the 371 presentity plays. For example, it might describe whether the 372 presentity is in a work mode or at home or participating in 373 activities related to some other organization such as the IETF or a 374 church. This document does not define names for these spheres except 375 for two common ones, "work" and "home". 377 Spheres are likely to be used for two purposes: they allow the 378 presentity to easily turn on or off certain rules that depend on what 379 groups of people should be made aware of the presentity's status. 380 For example, if the presentity is a Boy Scout leader, he might set 381 the sphere to 'scouting' and then have a rule set that allows other 382 scout masters in his troup to see his presence status. As soon as he 383 switches his status to 'work' or 'home' or some other sphere, the 384 fellow scouts would lose access. 386 The element can be used with tuples of all values of 387 . For tuples representing multiple physical devices, 388 'service' or 'presentity', these devices can be 389 controlled by people in multiple different spheres. In those cases, 390 the element enumerates all unique values as a token list. 392 The element MAY be qualified with the 'since' and 'until' 393 attributes as described in Section 4. 395 5. Examples 397 5.1 Presentity with Activity 399 400 405 406 407 open 408 assistant 409 410 assistant 411 presentity 412 sip:secretary@example.com 413 My secretary 414 415 416 417 open 418 419 meeting 420 office 421 quiet 422 2003-01-27T10:43:00Z 423 424 sip 425 service 426 sip:someone@example.com 427 2001-10-27T16:49:29Z 429 430 431 432 open 433 quiet 434 435 im:someone@mobilecarrier.net 436 2001-10-27T16:49:29Z 437 438 439 440 open 441 442 mail 443 blah 444 device 445 mailto:someone@example.com 446 I'm in a boring meeting 447 448 450 6. XML Schema Definitions 451 6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple 453 454 460 461 464 465 466 Describes RPID tuple extensions for PIDF. 467 468 470 471 472 473 474 475 476 477 478 479 481 483 484 486 6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status 488 489 490 491 492 493 494 495 Describes RPID status extensions for PIDF. 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 565 7. IANA Considerations 567 This document calls for IANA to: 569 o register two new XML namespace URNs per [6]; 570 o establish registry for activity categories (Section 4.2), place 571 types (Section 4.6), and relationships (Section 4.8). 573 Note that this document does not need a new content type. It 574 inherits the content type from [7], namely application/pidf+xml. 576 7.1 URN Sub-Namespace Registration for 577 'urn:ietf:params:xml:ns:pidf:status:rpid-status' 579 URI: urn:ietf:params:xml:ns:pidf:status:rpid-status 580 Description: This is the XML namespace for XML elements defined by 581 RFC&rfc.number [RFC editor: replace with RFC number]; to describe 582 rich presence information extensions for the status element in the 583 PIDF presence document format in the application/pidf+xml content 584 type. 586 Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 587 Henning Schulzrinne, hgs@cs.columbia.edu 588 XML: 590 BEGIN 591 592 594 598 RPID: Rich Presence: Extensions to the Presence 599 Information Data Format (PIDF) 600 601 602

Namespace for rich presence extension (status)

603

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

604

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

606 607 608 END 610 7.2 URN Sub-Namespace Registration for 611 'urn:ietf:params:xml:ns:pidf:rpid-tuple' 613 URI: urn:ietf:params:xml:ns:pidf:rpid-tuple 614 Description: This is the XML namespace for XML elements defined by 615 RFCXXXX [RFC editor: replace with RFC number] to describe rich 616 presence information extensions for the tuple element in the PIDF 617 presence document format in the application/pidf+xml content type. 618 Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 619 Henning Schulzrinne, hgs@cs.columbia.edu. 620 XML: 622 BEGIN 623 624 626 630 RPID: Rich Presence: Extensions to the Presence 631 Information Data Format (PIDF) 632 633 634

Namespace for rich presence extension (tuple)

635

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

636

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

638 639 640 END 642 7.3 Schema Registration for Schema 643 urn:ietf:params:xml:ns:pidf:rpid-tuple' 645 URI: please assign 646 Registrant Contact: IESG 647 XML: See Section 6.1 649 7.4 Schema Registration for Schema 650 urn:ietf:params:xml:ns:pidf:status:rpid-status' 652 URI: please assign 653 Registrant Contact: IESG 654 XML: See Section 6.2 656 7.5 Token Registrations 658 This document creates new IANA registries for RPID tokens: 660 contact-type: See Section 4.4 661 placetype: See Section 4.6 662 privacy: See Section 4.7 663 relationship: See Section 4.8 665 All are XML tokens. Registered tokens must be documented at the time 666 of registration, as most descriptions are expected to be brief. 668 Following the policies outline in RFC 2434 [3], these tokens are 669 assigned after Expert Review by the SIMPLE working group or its 670 designated successor. Each registration must include the name of the 671 token and a brief description similar to the ones offered in for the 672 initial registrations contained this document. 674 8. Security Considerations 676 The security considerations in [7] apply, as well as [8]. Compared to 677 PIDF, this presence document format reveals additional information 678 that can be highly sensitive. Beyond traditional security measures to 679 protect confidentiality and integrity, systems should offer a means 680 to selectively reveal information to particular watchers and to 681 inspect the information that is being published, particularly if it 682 is generated automatically from other sources, such as calendars or 683 sensors. 685 Normative References 687 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 688 Levels", BCP 14, RFC 2119, March 1997. 690 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 692 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 693 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 695 [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 696 August 1999. 698 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 699 Instant Messaging", RFC 2778, February 2000. 701 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 702 2004. 704 [7] Sugano, H. and S. Fujimoto, "Presence Information Data Format 705 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 706 2003. 708 [8] Rosenberg, J., "A Presence Event Package for the Session 709 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 710 in progress), January 2003. 712 Informative References 714 [9] Handley, M. and V. Jacobson, "SDP: Session Description 715 Protocol", RFC 2327, April 1998. 717 [10] Dawson, F. and Stenerson, D., "Internet Calendaring and 718 Scheduling Core Object Specification (iCalendar)", RFC 2445, 719 November 1998. 721 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 722 Session Description Protocol (SDP)", RFC 3264, June 2002. 724 [12] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for 725 User Control of Internet Telephony Services", 726 draft-ietf-iptel-cpl-08 (work in progress), August 2003. 728 [13] Dawson, F., Reddy, S., Royer, D. and E. Plamondon, "iCalendar 729 DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 (work in 730 progress), July 2002. 732 Authors' Addresses 734 Henning Schulzrinne 735 Columbia University 736 Department of Computer Science 737 450 Computer Science Building 738 New York, NY 10027 739 US 741 Phone: +1 212 939 7042 742 EMail: hgs+simple@cs.columbia.edu 743 URI: http://www.cs.columbia.edu 745 Vijay Gurbani 746 Lucent 747 2000 Naperville Rd. 748 Room 6G-440 749 Naperville, IL 60566-7033 750 US 752 EMail: vkg@lucent.com 754 Paul Kyzivat 755 Cisco Systems 756 BXB500 C2-2 757 1414 Massachusetts Avenue 758 Boxborough, MA 01719 759 US 761 EMail: pkzivat@cisco.com 762 Jonathan Rosenberg 763 dynamicsoft 764 600 Lanidex Plaza 765 Parsippany, NJ 07054-2711 766 US 768 EMail: jdrosen@dynamicsoft.com 770 Appendix A. Acknowledgements 772 The document reflects the discussion on the SIMPLE mailing list, with 773 contributions from many individuals. Markus Isomaki, Hisham 774 Khartabil, Jon Peterson and Brian Rosen provided detailed comments 775 and suggestions. Xiaotao Wu assisted with schema testing. 777 Intellectual Property Statement 779 The IETF takes no position regarding the validity or scope of any 780 Intellectual Property Rights or other rights that might be claimed to 781 pertain to the implementation or use of the technology described in 782 this document or the extent to which any license under such rights 783 might or might not be available; nor does it represent that it has 784 made any independent effort to identify any such rights. Information 785 on the IETF's procedures with respect to rights in IETF Documents can 786 be found in BCP 78 and BCP 79. 788 Copies of IPR disclosures made to the IETF Secretariat and any 789 assurances of licenses to be made available, or the result of an 790 attempt made to obtain a general license or permission for the use of 791 such proprietary rights by implementers or users of this 792 specification can be obtained from the IETF on-line IPR repository at 793 http://www.ietf.org/ipr. 795 The IETF invites any interested party to bring to its attention any 796 copyrights, patents or patent applications, or other proprietary 797 rights that may cover technology that may be required to implement 798 this standard. Please address the information to the IETF at 799 ietf-ipr@ietf.org. 801 Disclaimer of Validity 803 This document and the information contained herein are provided on an 804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 806 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 807 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 808 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 811 Copyright Statement 813 Copyright (C) The Internet Society (2004). This document is subject 814 to the rights, licenses and restrictions contained in BCP 78, and 815 except as set forth therein, the authors retain all their rights. 817 Acknowledgment 819 Funding for the RFC Editor function is currently provided by the 820 Internet Society.