idnits 2.17.00 (12 Aug 2021) /tmp/idnits52270/draft-ietf-simple-rpid-03.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 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 805. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 821), 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 20, 2004) is 6635 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 720, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 727, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 730, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 734, 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 18, 2004 V. Gurbani 5 Lucent 6 P. Kyzivat 7 Cisco 8 J. Rosenberg 9 dynamicsoft 10 March 20, 2004 12 RPID: Rich Presence Extensions to the Presence Information Data 13 Format (PIDF) 14 draft-ietf-simple-rpid-03 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 18, 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 . . . . . . . . . . . . . . . . . . . . 17 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 industrial: The presentity is in an industrial setting, such as a 300 manufacturing floor or powerplant. 301 quiet: The presentity is in a place such as a library, restaurant, 302 place-of-worship, or theater that discourages noise, conversation 303 and other distractions. 304 noisy: The presentity is in a place with lots of background noise. 305 public: The presentity is in a public area such as a shopping mall, 306 street, park, public building, train station, airport or in public 307 conveyance such as a bus, train, plane or ship. This general 308 description encompasses the more precise descriptors 'street', 309 'public-transport', 'aircraft', 'ship', 'bus', 'train', 'airport', 310 'mall' and 'outdoors' below. 311 street: Walking in a street. 312 public-transport: Any form of public transport, including aircraft, 313 bus, train or ship. 314 aircraft: The presentity is in a plane, helicopter or balloon. 315 ship: Water vessel, boat. 316 bus: Public or charter bus. 317 train: The presentity is traveling in a train, monorail, maglev, 318 cable car or similar conveyance. 319 airport: Airport, heliport or similar location. 320 station: Bus or train station. 321 mall: Shopping mall or shopping area. 322 outdoors: General outdoors area, such as a park or city streets. 324 This list can be augmented by free-text values or additional 325 IANA-registered values (Section Section 7). 327 The element can be used with tuples of all values of 328 . For tuples consisting of multiple physical devices, 329 i.e., of 'service' or 'presentity', these devices can 330 be in multiple types of places. In those cases, the 331 element enumerates all unique values as a token list. 333 The element MAY be qualified with the 'since' and 'until' 334 attributes as described in Section 4. 336 4.7 Privacy Element 338 The 'privacy' element indicates whether third parties may be able to 339 hear or view parts of the communication. 341 public: Others may be able to see or hear the communications. 342 private: Inappropriate individuals are not likely to see or hear the 343 communications. 345 This indication is not limited to voice communications. For example, 346 a presentity might label her privacy as "quiet" when giving a talk, 347 since it would be inappropriate if an instant message popped up on 348 the laptop screen that is being projected for the audience. 350 The 'placetype' element MAY be qualified with the 'since' and 'until' 351 attributes as described in Section 4. 353 4.8 Relationship Element 355 The element extends and designates the type of 356 relationship an alternate contact has with the presentity. This 357 element is provided only if the tuple refers to somebody other than 358 the presentity. Relationship values include "family", "associate" 359 (e.g., for a colleague), "assistant", "supervisor". Other free-text 360 values and additional IANA-registered values (Section 7) can be used 361 as well. 363 If a relationship is indicated, the RPID values describe the 364 , not the presentity. 366 The element for tuples labeled with a relationship can 367 contain either a communication URI such as "im", "sip"/"sips", 368 "h323", "tel" or "mailto", or a presence URI, such as "pres" or 369 "sip". 371 4.9 Sphere Element 373 The element designates the current state and role that the 374 presentity plays. For example, it might describe whether the 375 presentity is in a work mode or at home or participating in 376 activities related to some other organization such as the IETF or a 377 church. This document does not define names for these spheres except 378 for two common ones, "work" and "home". 380 Spheres are likely to be used for two purposes: they allow the 381 presentity to easily turn on or off certain rules that depend on what 382 groups of people should be made aware of the presentity's status. 383 For example, if the presentity is a Boy Scout leader, he might set 384 the sphere to 'scouting' and then have a rule set that allows other 385 scout masters in his troup to see his presence status. As soon as he 386 switches his status to 'work' or 'home' or some other sphere, the 387 fellow scouts would lose access. 389 The element can be used with tuples of all values of 390 . For tuples representing multiple physical devices, 391 'service' or 'presentity', these devices can be 392 controlled by people in multiple different spheres. In those cases, 393 the element enumerates all unique values as a token list. 395 The element MAY be qualified with the 'since' and 'until' 396 attributes as described in Section 4. 398 5. Examples 400 5.1 Presentity with Activity 402 403 408 409 410 open 411 assistant 412 413 assistant 414 presentity 415 sip:secretary@example.com 416 My secretary 417 418 419 420 open 421 422 meeting 423 office 424 quiet 425 2003-01-27T10:43:00Z 426 427 sip 428 service 429 sip:someone@example.com 430 2001-10-27T16:49:29Z 431 432 433 434 open 435 quiet 436 437 im:someone@mobilecarrier.net 438 2001-10-27T16:49:29Z 439 440 441 442 open 443 444 mail 445 blah 446 device 447 mailto:someone@example.com 448 I'm in a boring meeting 449 450 452 6. XML Schema Definitions 453 6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple 455 456 462 463 466 467 468 Describes RPID tuple extensions for PIDF. 469 470 472 473 474 475 476 477 478 479 480 481 483 485 486 488 6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status 490 491 492 493 494 495 496 497 Describes RPID status extensions for PIDF. 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 564 565 567 7. IANA Considerations 569 This document calls for IANA to: 571 o register two new XML namespace URNs per [6]; 572 o establish registry for activity categories (Section 4.2), place 573 types (Section 4.6), and relationships (Section 4.8). 575 Note that this document does not need a new content type. It 576 inherits the content type from [7], namely application/pidf+xml. 578 7.1 URN Sub-Namespace Registration for 579 'urn:ietf:params:xml:ns:pidf:status:rpid-status' 581 URI: urn:ietf:params:xml:ns:pidf:status:rpid-status 582 Description: This is the XML namespace for XML elements defined by 583 RFC&rfc.number [RFC editor: replace with RFC number]; to describe 584 rich presence information extensions for the status element in the 585 PIDF presence document format in the application/pidf+xml content 586 type. 588 Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 589 Henning Schulzrinne, hgs@cs.columbia.edu 590 XML: 592 BEGIN 593 594 596 600 RPID: Rich Presence: Extensions to the Presence 601 Information Data Format (PIDF) 602 603 604

Namespace for rich presence extension (status)

605

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

606

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

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

Namespace for rich presence extension (tuple)

637

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

638

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

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