idnits 2.17.1 draft-ietf-impp-cpim-pidf-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (May 2003) is 7649 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) == Missing Reference: 'RFC2426' is mentioned on line 220, but not defined ** Obsolete undefined reference: RFC 2426 (Obsoleted by RFC 6350) == Missing Reference: 'RFC 2048' is mentioned on line 846, but not defined ** Obsolete undefined reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) == Missing Reference: 'RFC 3023' is mentioned on line 908, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Missing Reference: 'RFCXXXX' is mentioned on line 954, but not defined == Unused Reference: 'MIME' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'CPIM-MSG' is defined on line 1078, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NS' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2141 (ref. 'URN') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. 'URN-NS-IETF') == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSchema1' == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-02 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-02 -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Sugano 3 INTERNET-DRAFT S. Fujimoto 4 Fujitsu 5 G. Klyne 6 Nine by Nine 7 A. Bateman 8 VisionTech 9 W. Carr 10 Intel 11 J. Peterson 12 NeuStar 14 Expires: November 2003 May 2003 16 Presence Information Data Format (PIDF) 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Please send comments to the authors or to the impp@iastate.edu 41 discussion list. 43 Copyright Notice 45 Copyright (C) The Internet Society (2003). All Rights Reserved. 47 Abstract 49 This memo specifies the Common Profile for Presence (CPP) Presence 50 Information Data Format (PIDF) as a common presence data format for 51 CPP-compliant Presence protocols, and also defines a new media type 52 "application/pidf+xml" to represent the XML MIME entity for PIDF. 54 Table of Content 56 1. Introduction ......................................... 4 57 1.1. Terminology and Conventions .......................... 4 58 2. Design Decisions ..................................... 4 59 2.1. Minimal Model ........................................ 5 60 2.2. Added Features ....................................... 5 61 2.3. XML Encoding Decision ................................ 6 62 3. Overview of Presence Information Data Format ......... 6 63 3.1. The 'application/pidf+xml' Content Type .............. 6 64 3.2. Presence Information Contents ........................ 7 65 4. XML-encoded Presence Data Format ..................... 7 66 4.1. XML Format Definitions ............................... 7 67 4.1.1. The element ............................... 7 68 4.1.2. The element .................................. 8 69 4.1.3. The element ................................. 9 70 4.1.4. The element .................................. 9 71 4.1.5. The element ................................ 10 72 4.1.6. The element ................................... 10 73 4.1.7. The element .............................. 11 74 4.2. Presence Information Extensibility ................... 11 75 4.2.1. XML Namespaces Background ............................ 11 76 4.2.2. XML Namespaces In Presence Information ............... 12 77 4.2.3. Handling Of Unrecognized Element Names ............... 13 78 4.2.4. Status Value Extensibility ........................... 14 79 4.2.5. Standardizing Status Extensions ...................... 14 80 4.3. Examples ............................................. 16 81 4.3.1. Default Namespace with Status Extensions ............. 16 82 4.3.2. Presence with Other Extension Elements ............... 16 83 4.3.3. Example Mandatory To Understand Elements ............. 17 84 4.4. XML Schema Definitions ............................... 17 85 5. IANA Considerations .................................. 19 86 5.1. Content-type registration for 87 'application/pidf+xml' .................... 20 88 5.2. URN sub-namespace registration for 89 'urn:ietf:params:xml:ns:pidf' ............. 21 90 5.3. URN sub-namespace registration for 91 'urn:ietf:params:xml:ns:pidf:status' ...... 22 92 6. Security Considerations .............................. 22 93 7. Internationalization Considerations .................. 23 94 8. Normative References ................................. 23 95 9. Informative References ............................... 24 96 10. Authors' Addresses .................................. 25 97 11. Appendix A. Document Type Definitions ............... 26 98 12. Full Copyright Statement ............................ 27 100 1. Introduction 102 The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence 103 (CPP) [CPP] specifications define a set of operations and parameters 104 to achieve interoperability between different Instant Messaging and 105 Presence protocols which meet RFC 2779 [RFC2779]. 107 This memo further defines the Presence Information Data Format (PIDF) 108 as a common presence data format for CPP-compliant presence 109 protocols, allowing presence information to be transferred across 110 CPP-compliant protocol boundaries without modification, with 111 attendant benefits for security and performance. 113 The format specified in this memo defines the base presence format 114 and extensibility required by RFC 2779. It defines a minimal set of 115 presence status values defined by the IMPP Model document [RFC2778]. 116 However, a presence application is able to define its own status 117 values using the extensibility framework provided by this memo. 118 Defining such extended status values is beyond the scope of this 119 memo. 121 Note also that this memo defines only the format for a presence data 122 payload and the extensibility framework for it. How the presence data 123 is transferred within a specific protocol frame would be defined 124 separately in a protocol specification. 126 1.1. Terminology and Conventions 128 This memo makes use of the vocabulary defined in the IMPP Model 129 document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, 130 PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the 131 memo are used in the same meaning as defined therein. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 134 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 135 interpreted as described in RFC 2119 [RFC2119]. 137 2. Design Decisions 139 We have adopted the IMPP Model and Requirements documents [RFC2778, 140 RFC2779] as the starting point of our discussion. The two RFCs 141 contain a number of statements about presence information, which can 142 be regarded as a basic set of constraints for the format design. 143 Also, we took the minimalist approach to the design based on them. 144 Starting from the minimal model, only the features that are necessary 145 to solve particular problems have been included. 147 2.1. Minimal Model 149 This specification is based on the minimal model extracted from the 150 IMPP Model and Requirements documents. The model consists of the 151 following items. Each of them is accompanied with the corresponding 152 RFCs and their section numbers as its grounds, e.g. (RFC2778:Sec.2.4) 153 refers to Section 2.4 of RFC 2778. 155 (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, 156 where a PRESENCE TUPLE consists of a STATUS, an optional 157 COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. 158 Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is 159 understood in this document to refer only to a URI. 160 (RFC2778:Sec.3) 162 (b) STATUS has at least the mutually-exclusive values OPEN and 163 CLOSED, which have meaning for the acceptance of INSTANT 164 MESSAGES, and may have meaning for other COMMUNICATION MEANS. 165 There may be other values of STATUS that do not imply anything 166 about INSTANT MESSAGE acceptance. These other values of STATUS 167 may be combined with OPEN and CLOSED or they may be mutually- 168 exclusive with those values. (RFC2778:Sec.3, RFC2779:Sec.4.4.1- 169 4.4.3) 171 (c) STATUS may consist of single or multiple values.(RFC2778:Sec.2.4) 173 (d) There must be a means of extending the common presence format 174 to represent additional information not included in the common 175 format. The extension and registration mechanisms must be 176 defined for presence information schema, including new STATUS 177 conditions and new forms for OTHER PRESENCE MARKUP. (RFC2779: 178 Sec.3.1.4-3.1.5) 180 (e) The common presence format must include a means to uniquely 181 identify the PRESENTITY whose PRESENCE INFORMATION is reported. 182 (RFC2779:Sec.3.1.2) 184 (f) The common presence format must allow the PRESENTITY to secure 185 presence information sent to a WATCHER. The format must allow 186 integrity, confidentiality and authentication properties to be 187 applied to presence information. (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 188 5.3.3) 190 2.2. Added Features 192 In addition to the minimal model described above, the format 193 specified in this specification has the following features. 195 (a) Relative priorities of contact addresses are specifiable in 196 order to allow the source of PRESENCE INFORMATION to tell the 197 receiver (WATCHER USER AGENTS) its preference over multiple 198 contact means. 200 (b) The presence format is able to contain the timestamp of the 201 creation of the PRESENCE INFORMATION. The timestamp in the 202 presence document lets the receiver know the time of the creation 203 of the data even if the message containing it is delayed. 204 It can also be used to detect a replay attack, independent of 205 the underlying signature mechanism. Note that this mechanism 206 does not assume any global time synchronization system for 207 watchers and presentities (see Appendix A of RFC2779, 8.1.4 A7), 208 but rather assumes that the minimum length of time that might 209 pass before presence information is considered stale is long 210 enough that minor variations among system clocks will not lead 211 to misjudgments of the freshness of presence information. 213 2.3. XML Encoding Decision 215 The Presence Information Data Format encodes presence information in 216 XML (eXtensible Markup Language [XML]). Regarding the features of 217 PRESENCE INFORMATION discussed above, such that it has a hierarchical 218 structure and it should be fully extensible, XML is considered as the 219 most desirable framework over other candidates such as vCard 220 [RFC2426]. 222 3. Overview of Presence Information Data Format 224 This section describes an overview of the presence data format 225 defined in this memo. 227 3.1. The 'application/pidf+xml' Content Type 229 This memo defines a new content type "application/pidf+xml" for an 230 XML MIME entity that contains presence information. This 231 specification follows the recommendations and conventions described 232 in [RFC3023], including the naming convention of the type ('+xml' 233 suffix) and the usage of the 'charset' parameter. 235 Although it is defined as optional, use of the 'charset' parameter is 236 RECOMMENDED. If the 'charset' parameter is not specified, conforming 237 XML processors MUST follow the requirements in section 4.3.3 of 238 [XML]. 240 3.2. Presence Information Contents 242 This subsection outlines the information in an "application/pidf+xml" 243 document. A full definition of the PIDF content is in Section 4. 245 o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY. 246 o List of PRESENCE TUPLES 247 - Identifier: token to identify this tuple within the presence 248 information. 249 - STATUS: OPEN/CLOSED and/or extension status values. 250 - COMMUNICATION ADDRESS: COMMUNICATION MEANS and CONTACT 251 ADDRESS of this tuple. (optional) 252 - Relative priority: numerical value specifying the priority 253 of this COMMUNICATION ADDRESS. (optional) 254 - Timestamp: timestamp of the change of this tuple.(optional) 255 - Human readable comment: free text memo about this tuple 256 (optional) 257 o PRESENTITY human readable comment: free text memo about the 258 PRESENTITY (optional). 260 4. XML-encoded Presence Data Format 262 This section defines an XML-encoded presence information data format 263 (PIDF) for use with CPP compliant systems. A presence payload in 264 this format is expected to be produced by the PRESENTITY (the source 265 of the PRESENCE INFORMATION) and transported to the WATCHERS by the 266 presence servers or gateways without any interpretation or 267 modification. 269 4.1. XML Format Definitions 271 A PIDF object is a well formed XML document. 273 It MUST have the XML declaration and it SHOULD contain an encoding 274 declaration in the XML declaration, e.g. "". If the charset parameter of the MIME content 276 type declaration is present and it is different from the encoding 277 declaration, the charset parameter takes precedence. 279 Every application conformant to this specification MUST accept the 280 UTF-8 character encoding to ensure the minimal interoperability. 282 4.1.1. The element 284 PIDF elements are associated with the XML namespace name 285 'urn:ietf:params:xml:ns:pidf', declared using an xmlns attribute, per 287 [XML-NS]. The namespace may be a default namespace, or may be 288 associated with some namespace prefix (see section 4.2.2 for 289 examples). 291 The root of an "application/pidf+xml" object is a element 292 associated with the presence information namespace. This contains 293 any number (including 0) of elements, followed by any number 294 (including 0) of elements, followed by any number of OPTIONAL 295 extension elements from other namespaces. 297 The element MUST have an 'entity' attribute. The value of 298 the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing 299 this presence document. 301 The element MUST contain a namespace declaration ('xmlns') 302 to indicate the namespace on which the presence document is based. 303 The presence document compliant to this specification MUST have the 304 namespace 'urn:ietf:params:xml:ns:pidf:'. 306 It MAY contain other namespace declarations for the extensions used 307 in the presence XML document. 309 4.1.2. The element 311 The element carries a PRESENCE TUPLE, consisting of a 312 mandatory element, followed by any number of OPTIONAL 313 extension elements (possibly from other namespaces), followed by an 314 OPTIONAL element, followed by any number of OPTIONAL 315 elements, followed by an OPTIONAL element. 317 Tuples provide a way of segmenting presence information. Protocols or 318 applications may choose to segment the presence information 319 associated with a presentity for any number of reasons - for example, 320 because components of the full presence information for a presentity 321 have come from distinct devices or different applications on the same 322 device, or have been generated at different times. Tuples should be 323 preferred over other manners of segmenting presence information such 324 as creating multiple PIDF instances. 326 The element MUST contain an 'id' attribute which is used to 327 distinguish this tuple from other tuples in the same PRESENTITY. The 328 value of an 'id' attribute MUST be unique within 'id' attribute 329 values of other tuples for the same PRESENTITY. An 'id' value is 330 used by applications processing the presence document to identify the 331 corresponding tuple in the previously acquired PRESENCE INFORMATION 332 of the same PRESENTITY. The value of the 'id' attribute is an 333 arbitrary string, and has no significance beyond providing a means to 334 distinguish values, as noted above. 336 The element is OPTIONAL because a PRESENTITY might need to 337 hide its COMMUNICATION ADDRESS or there might be tuples not related 338 to any COMMUNICATION MEANS. Tuples that contain a status 339 element SHOULD contain a address. Tuples MAY contain 340 conflicting presence status - one might provide a 341 of OPEN, and another in the same PIDF could contain 342 a of CLOSED, even if they both contain the same 343 address. 345 The manner in which segmented presence information is understood by 346 the WATCHER USER AGENT is highly dependent on the capabilities of the 347 WATCHER USER AGENT and the presence application in question. In the 348 absence of any application-specific or protocol-specific 349 understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey 350 the following guidelines. WATCHER USER AGENTS should note which 351 tuples in the PIDF have changed their state since the last 352 notification by correlating the 'id' of each with those 353 received in previous notifications and comparing both values 354 and elements in the tuples, if any are present. 356 4.1.3. The element 358 The element contains one OPTIONAL element, followed 359 by any number of OPTIONAL extension elements (possibly from other 360 namespaces), under the restriction that at least one child element 361 appears in the element. These children elements of 362 contain status values of this tuple. By allowing multiple status 363 values in a single element, different types of status values, 364 e.g. reachability and location, can be represented by a . See 365 Section 4.3 for an example with multiple status values. 367 This memo only defines the status value element. Other status 368 values may be included using the standard extensibility framework 369 (see Section 4.2.4). Applications encountering unrecognized elements 370 within may ignore them, unless they carry a 371 mustUnderstand="true" or mustUnderstand="1" attribute (see section 372 4.2.3). 374 Note that, while the element MUST have at least one status 375 value element, this status value might not be the element. 377 4.1.4. The element 379 The element contains one of the following strings: "open" or 380 "closed". 382 The values "open" and "closed" indicate availability to receive 383 INSTANT MESSAGES if the is for an instant messaging address. 384 They also indicate general availability for other communication 385 means, but this memo does not specify these in detail. 387 open: In the context of INSTANT MESSAGES, this value means that the 388 associated element, if any, corresponds to an 389 INSTANT INBOX that is ready to accept an INSTANT MESSAGE. 391 closed: In the context of INSTANT MESSAGES, this value means that 392 the associated element, if any, corresponds to an 393 INSTANT INBOX that is unable to accept an INSTANT MESSAGE. 395 4.1.5. The element 397 The element contains a URL of the contact address. It 398 optionally has a 'priority' attribute, whose value means a relative 399 priority of this contact address over the others. The value of the 400 attribute MUST be a decimal number between 0 and 1 inclusive with at 401 most 3 digits after the decimal point. Higher values indicate higher 402 priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the 403 'priority' attribute is omitted, applications MUST assign the contact 404 address the lowest priority. If the 'priority' value is out of the 405 range, applications just SHOULD ignore the value and process it as if 406 the attribute was not present. 408 Applications SHOULD handle contacts with a higher priority as they 409 have precedence over those with lower priorities. How they are 410 actually treated is beyond this specification. Also, how to handle 411 contacts with the same priority is up to implementations. 413 4.1.6. The element 415 The element contains a string value, which is usually used for 416 a human readable comment. A element MAY appear as a child 417 element of or as a child element of the element. 418 In the former case the comment is about the PRESENTITY and in the 419 latter case the comment is regarding the particular tuple. 421 Note that, wherever it appears, a element SHOULD NOT be used, 422 and interpreted, as a non-interoperable substitute for status of its 423 parent element. 425 The element SHOULD have a special attribute 'xml:lang' to 426 specify the language used in the contents of this element as defined 427 in Section 2.12 of [XML]. The value of this attribute is the 428 language identifier as defined by [RFC3066]. It MAY be omitted when 429 the language used is implied by the larger context such as the 430 encoding information of the contents, such as an xml:lang attribute 431 on an enclosing XML element, or a Content-language header [RFC3282] 432 on an enclosing MIME wrapper. 434 4.1.7. The element 436 The element contains a string indicating the date and 437 time of the status change of this tuple. The value of this element 438 MUST follow the IMPP datetime format [RFC3339]. Timestamps that 439 contain 'T' or 'Z' MUST use the capitalized forms. 441 As a security measure, the element SHOULD be included in 442 all tuples unless the exact time of the status change cannot be 443 determined. For security guidelines for watchers receiving presence 444 information with timestamps, see the Security Considerations. 446 A PRESENTITY MUST NOT generate successive elements 447 containing the same timestamp. 449 4.2. Presence Information Extensibility 451 The presence information extensibility framework is based on XML 452 namespaces [XML-NS]. 454 RFC2779 requires that PIDF have a means of extending values 455 beyond . These extensions MUST NOT modify how is to be 456 understood, nor change the structure or semantics of PIDF bodies 457 themselves. These extensions merely allow protocols and applications 458 to define richer presence data. 460 4.2.1. XML Namespaces Background 462 All elements and some attributes are associated with a "namespace", 463 which is in turn associated with a globally unique URI. Any 464 developer can introduce their own element names, avoiding conflict by 465 choosing an appropriate namespace URI. 467 Within the presence data, element or attribute names are associated 468 with a particular namespace by a namespace prefix, which is a leading 469 part of the name, followed by a colon (":"); e.g. 471 ... 473 Where, 'prefix' is the header name prefix, 'element-name' is a name 474 which is scoped by the namespace associated with 'prefix'. Note that 475 the choice of 'prefix' is quite arbitrary; it is the corresponding 476 URI that defines the naming scope. Two different prefixes associated 477 with the same namespace URI refer to the same namespace. 479 A default namespace can be declared for XML elements without a 480 namespace prefix. The default namespace does NOT apply to attribute 481 names, but interpretation of an unprefixed attribute can be 482 determined by the containing element. 484 A namespace is identified by a URI. In this usage, the URI is used 485 simply as a globally unique identifier, and there is no requirement 486 that it can be used to retrieve a web resource, or for any other 487 purpose. Any legal globally unique URI MAY be used to identify a 488 namespace. (By "globally unique", we mean constructed according to 489 some set of rules so that it is reasonable to expect that nobody else 490 will use the same URI for a different purpose.) 492 For further details, see the XML namespace specification [XML-NS]. 494 4.2.2. XML Namespaces In Presence Information 496 A URI used as a namespace identifier in PRESENCE INFORMATION data 497 MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and 498 URI-references containing fragment identifiers MUST NOT be used for 499 this purpose.) 501 The namespace URI for elements defined by this specification is a URN 502 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 503 and extended by [XML-Registry]: 505 urn:ietf:params:xml:ns:pidf 507 Thus, simple presence data might be thus: 509 510 512 513 514 open 515 516 tel:+09012345678 517 519 521 or, using a default XML namespace: 523 524 526 527 528 open 529 530 tel:+09012345678 531 532 534 As is generally the case in XML with namespaces, the xmlns attribute 535 can be used on any element in the presence information to define 536 either the default namespace or a namespace associated with a 537 namespace prefix. 539 4.2.3. Handling Of Unrecognized Element Names 541 Except as noted below, a processor of PRESENCE INFORMATION MUST 542 ignore any XML element with an unrecognized name (i.e. having an 543 unrecognized namespace URI, or an unrecognized local name within that 544 namespace). This includes all of the element content, even if it 545 appears to contain elements with recognized names. 547 Extensions to PIDF are informational in nature - they provide 548 additional information beyond status. However, in order to 549 understand a complex extension, nested elements within an extension 550 element might need to be marked as mandatory. In such cases, the 551 element name is qualified with a mustUnderstand='true' or 552 mustUnderstand='1' attribute. See section 4.3.3 for an example. 554 NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute 555 within an element that is being ignored is itself ignored. The 556 writer of nested mandatory-to-understand information is responsible 557 for ensuring that any enclosing element is also labelled with a 558 mustUnderstand='true' or mustUnderstand='1' attribute, if 559 necessary. 561 This specification defines (section 4.1) elements within the 562 'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in 563 CPP presence data. Processors MUST handle these as described, even 564 if they do not carry a mustUnderstand attribute. The XML Schema 565 Definition (section 4.4) indicates those elements that MUST be 566 present in a valid presence information document. 568 If an agent receives PRESENCE INFORMATION with a block 569 containing an unrecognized element with a mustUnderstand='true' (or 570 '1') attribute, it should treat that entire element and any content 571 as unrecognized and not attempt to process it. 573 In order to ensure that minimal implementations can correctly process 574 basic PIDF information the mustUnderstand attribute MUST be used only 575 within optional elements nested in a element. This will 576 ensure that problems processing an extension are restricted to that 577 extension and do not affect the processing of the basic PIDF 578 information defined in this specification. 580 4.2.4. Status Value Extensibility 582 This memo defines only the status value with values of "open" 583 and "closed". Other status values are possible using the standard 584 namespace-based extensibility rules defined above. 586 For example, a location status value might be included thus: 588 589 592 593 594 open 595 home 596 597 im:someone@example.com 598 599 601 Some new status values will 'extend' the value of the 602 element. For example, a status value defined for use with instant 603 messaging may include values such as 'away', 'busy' and 'offline'. In 604 order that some level of interoperability be maintained with user 605 agents that don't recognize the new extension, the status 606 value must also be included. This means that extensions are not 607 obligated to define a mapping from each of their values to OPEN or 608 CLOSED. 610 4.2.5. Standardizing Status Extensions 611 Although the existing PIDF definition allows arbitrary elements to 612 appear in the element, it may be sometimes desirable to 613 standardize extension status elements and their semantics (the 614 meanings of particular statuses, how they should be interpreted). The 615 URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a 616 namespace URI for extensions standardized by the IETF, and new values 617 in this namespace must be defined by a standards-track RFC. 619 The following example XML Schema defines an extension for 620 presence information, which can have the values of 'home', 'office', 621 or 'car'. If the element were standardized, this document 622 would be made available in an RFC along with information about the 623 use of the extension. These extensions should use the namespace 624 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an 625 extension should register an extension name within that namespace 626 with IANA. 628 629 635 636 637 638 639 640 641 643 645 In addition to the XML Schema to validate the extension, registration 646 of the extension name with IANA, RFCs defining extensions MUST 647 discuss: 649 - The domain of applicability of the extension. Is this extension 650 exclusively valuable to IM clients, telephones, geolocators, etc? 651 What sorts of presence applications would use this extension and 652 under what circumstances? 654 - Semantics for the presence states defined in the extension. What 655 disposition provokes an automated presentity to declare that it is 656 in state X, or does a human select X from a drag-down menu? Is 657 there any general guidance for watchers of presence information 658 with state Y (for example, how they should best attempt to 659 communicate with the presentity, if at all, when the principal is 660 in state Y). 662 Extensions SHOULD also discuss: 664 - How, if at all, any presence states defined in the extension 665 related to , or to any relevant extension previously 666 published in an RFC. For example, "state Z implies OPEN, so it MUST 667 NOT be used if a basic state of CLOSED is expressed", or "you 668 should use the extension in this document, not the extension in RFC 669 QQQQ, if your circumstances are as follows...." 671 4.3. Examples 673 4.3.1. Default Namespace with Status Extensions 675 676 680 681 682 open 683 busy 684 home 685 686 im:someone@mobilecarrier.net 687 Don't Disturb Please! 688 Ne derangez pas, s'il vous plait 689 2001-10-27T16:49:29Z 690 691 692 693 open 694 695 mailto:someone@example.com 696 697 I'll be in Tokyo next week 698 700 4.3.2. Presence with Other Extension Elements 702 703 706 707 708 open 709 710 Extended value in tuple 711 tel:+09012345678 712 713 714 715 open 716 717 718 im:someone@mobilecarrier.net 719 720 My extended presentity information 721 723 4.3.3. Example Mandatory To Understand Elements 725 726 729 730 731 open 732 733 734 val1 735 val2 736 737 tel:+09012345678 738 739 My extended presentity information 740 742 Here, must be understood and, if it is not recognized, 743 MUST be ignored. and 744 MAY be ignored if they are not recognized. 746 4.4. XML Schema Definitions 748 This section gives the XML Schema Definition [XMLSchema1] of the 749 "application/pidf+xml" format. This is presented as a formal 750 definition of the "application/pidf+xml" format. Note that the XML 751 Schema definition is not intended to be used with on-the-fly 752 validation of the presence XML document. 754 755 761 762 765 767 768 769 771 773 775 776 777 779 780 781 782 784 785 787 788 789 790 792 793 794 795 797 798 799 800 801 802 803 804 806 807 808 809 810 811 812 814 815 816 817 818 819 820 822 823 824 825 826 827 829 830 831 832 833 This attribute may be used on any element within an optional 834 PIDF extension to indicate that the corresponding element must 835 be understood by the PIDF processor if the enclosing optional 836 element is to be handled. 837 838 839 840 842 5. IANA Considerations 844 This memo calls for IANA to: 845 - register a new MIME content-type application/pidf+xml, 846 per [RFC 2048], 847 - register a new XML namespace URN per [XML-Registry]. 848 - register a new XML namespace URN for status extensions per 849 [XML-Registry]. 851 The registration templates for these are below. For more information 852 on status extensions, see section 4.2.5. 854 5.1. Content-type registration for 'application/pidf+xml' 856 To: ietf-types@iana.org 857 Subject: Registration of MIME media type application/pidf+xml 859 MIME media type name: application 861 MIME subtype name: pidf+xml 863 Required parameters: (none) 865 Optional parameters: charset 866 Indicates the character encoding of enclosed XML. Default is 867 UTF-8. 869 Encoding considerations: 870 Uses XML, which can employ 8-bit characters, depending on the 871 character encoding used. 872 See RFC 3023 [RFC 3023], section 3.2. 874 Security considerations: 875 This content type is designed to carry presence data, which may 876 be considered private information. Appropriate precautions should 877 be adopted to limit disclosure of this information. 879 Interoperability considerations: 880 This content type provides a common format for exchange of 881 presence information across different CPP compliant protocols. 883 Published specification: 884 RFCXXXX (this document) 886 Applications which use this media type: 887 Presence and instant messaging systems. 889 Additional information: 891 Magic number(s): 892 File extension(s): 894 Macintosh File Type Code(s): 896 Person & email address to contact for further information: 897 Hiroyasu Sugano 898 E-mail: sugano.h@jp.fujitsu.com 900 Intended usage: 901 LIMITED USE 903 Author/Change controller: 904 This specification is a work item of the IETF IMPP working group, 905 with mailing list address . 907 Other information: 908 This media type is a specialization of application/xml [RFC 3023], 909 and many of the considerations described there also apply to 910 application/pidf+xml. 912 5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf' 914 URI 915 urn:ietf:params:xml:ns:pidf 917 Description: 918 This is the XML namespace URI for XML elements defined by 919 [RFCXXXX] to describe CPP presence information in 920 application/pidf+xml content type. 922 Registrant Contact 923 IETF, IMPP working group, 924 Hiroyasu Sugano, 926 XML 927 BEGIN 928 929 931 932 933 935 Namespace for CPP presence information 936 937 938

Namespace for CPP presence information

939

application/pidf+xml

940

See RFCXXXX.

942 943 944 END 946 5.3. URN sub-namespace registration for 947 'urn:ietf:params:xml:ns:pidf:status' 949 URI 950 urn:ietf:params:xml:ns:pidf:status 952 Description: 953 This is the XML namespace URI for XML elements defined by 954 [RFCXXXX] to describe extensions to the status of CPP presence 955 information in application/pidf+xml content type. 957 Registrant Contact 958 IETF, IMPP working group, 959 Hiroyasu Sugano, 961 XML 962 BEGIN 963 964 966 967 968 970 Namespace for CPP status extensions 971 972 973

Namespace for CPP presence information extensions

974

application/pidf+xml

975

See RFCXXXX.

976 977 978 END 980 6. Security Considerations 982 Because presence is very privacy-sensitive information, the protocol 983 for the presence information MUST have capabilities to protect PIDF 984 from possible threats, such as eavesdropping, corruption, tamper and 985 replay attacks. These security mechanisms must be able to be used 986 end-to-end between presentities and watchers, even if the watcher and 987 the presentity employ different presence protocols and communicate 988 through a CPP gateway. Since the 'application/pidf+xml' MIME type is 989 defined for this PIDF document, staging security for PIDF at the MIME 990 level (with S/MIME [RFC2633]) seems appropriate. Therefore, PIDF 991 should follow the normative recommendations for the use of S/MIME 992 (including minimum ciphersuites) given in the core CPP specification. 994 Note that the use of timestamps in PIDF (see section 4.1.7) can 995 provide some rudimentary protection against replay attacks. If a 996 watcher receives presence information that is outdated, it SHOULD be 997 ignored. A watcher can determine that presence information is 998 outdated in a number of fashions. Most significantly, if the newest 999 timestamp in presence information is older than the newest timestamp 1000 in the last received presence information, it should be considered 1001 outdated. Applications and protocols also are advised to adopt their 1002 own rules for determining how frequently presence information should 1003 be refreshed. For example, if presence information appears to be more 1004 than one hour old, it could be considered outdated (a notification 1005 generated for this presence information will not take such a long 1006 time to reach a watcher, and if a presentity has not refreshed its 1007 presence state in the last hour, it is probably offline). 1009 7. Internationalization Considerations 1011 All the processors conformant to this specification MUST be able to 1012 generate and accept UTF-8 encoding, this being one of the mandatory 1013 character encodings for XML conforming processors, and also required 1014 by the policies set out in RFC 2277 [RFC2277]. 1016 Other character encodings MAY be accepted (but CPP compliant 1017 processors are strongly discouraged from emitting anything other than 1018 UTF-8). 1020 8. Normative References 1022 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1023 Requirement Levels", RFC 2119, BCP 14, March 1997. 1025 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", 1026 RFC 3023, January 2001. 1028 [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, 1029 "Extensible Markup Language (XML) 1.0 (Second Edition)", 1030 W3C Recommendation, October 2000, 1031 1033 [MIME] Multipurpose Internet Mail Extensions. See RFC 2045, 1034 RFC 2046, RFC 2047, RFC 2048, and RFC 2049. 1036 [RFC3066] H. Alvestrand, "Tags for the Identification of Languages", 1037 RFC 3066, March 1995. 1039 [RFC3339] G. Klyne and C.Newman, "Date and Time on the Internet: 1040 Timestamps", RFC 3339, July 2002. 1042 [XML-NS] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in 1043 XML", W3C recommendation: xml-names, 14 January 1999, 1044 1046 [URI] T. Berners-Lee, R.T.Fielding and L. Masinter, "Uniform 1047 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1049 [URN] R. Moats, "URN Syntax", RFC 2141, May 1997. 1051 [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", RFC 1052 2648, August 1999. 1054 [XML-Registry] M. Mealling, "The IETF XML Registry", 1055 draft-mealling-iana-xmlns-registry-04, Work in Progress. 1057 [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and 1058 Languages", RFC 2277, BCP 18, January 1998. 1060 [XMLSchema1] H. Thompson, D. Beech, M. Maloney and N. Mendelsohn, 1061 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 1062 . 1064 9. Informative References 1066 [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and 1067 Instant Messaging", RFC 2778, February 2000. 1069 [RFC2779] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant 1070 Messaging / Presence Protocol Requirements", RFC 2779, February 2000. 1072 [CPIM] D. Crocker and J. Peterson, "Common Profile for Instant 1073 Messaging (CPIM)", draft-ietf-impp-im-02.txt, Work in Progress. 1075 [CPP] D. Crocker and J. Peterson, "Common Presence for Presence 1076 (CPP)", draft-ietf-impp-pres-02.txt, Work in Progress. 1078 [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant 1079 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08.txt, 1080 Work in Progress. 1082 [vCard] F. Dawson and T. Howes, "vCard MIME Directory Profile", 1083 RFC 2426, September 1998. 1085 [RFC2633] B. Ramsdell, "S/MIME Version 3 Message Specification", 1086 RFC 2633, June 1999. 1088 [RFC3282] H. Alvestrand, "Content Language Headers", RFC 3282, 1089 May 2002. 1091 10. Authors' Addresses 1093 Hiroyasu Sugano 1094 Fujitsu Laboratories Ltd. 1095 64, Nishiwaki 1096 Ohkubo-cho 1097 Akashi 674-8555 1098 Japan 1099 E-mail: sugano.h@jp.fujitsu.com 1101 Shingo Fujimoto 1102 Fujitsu Laboratories Ltd. 1103 64, Nishiwaki 1104 Ohkubo-cho 1105 Akashi 674-8555 1106 Japan 1107 E-mail: shingo_fujimoto@jp.fujitsu.com 1109 Graham Klyne 1110 Nine by Nine 1111 E-mail: GK@ninebynine.org 1113 Adrian Bateman 1114 VisionTech Limited 1115 Colton, Staffordshire, WS15 3LD 1116 United Kingdom 1117 E-mail: bateman@acm.org 1119 Wayne Carr 1120 Intel Corporation 1121 2111 NE 25th Avenue 1122 Hillsboro, OR 97124 1123 USA 1124 E-mail: wayne.carr@intel.com 1126 Jon Peterson 1127 NeuStar, Inc. 1128 1800 Sutter St 1129 Suite 570 1130 Concord, CA 94520 1131 USA 1132 Phone: +1 925/363-8720 1133 E-mail: jon.peterson@neustar.biz 1135 11. Appendix A. Document Type Definitions 1137 The Document Type Definition for the "application/pidf+xml" format is 1138 described. The DTD here is presented only for informational for 1139 those who may not familiar with the XML Schema definition. 1141 Note: the DTD does not show where extension elements can be added. 1142 See the XML Schema for that information. 1144 1145 1146 1147 1148 1149 1150 1152 1153 1158 1159 1163 1164 1166 1167 1171 1173 1175 12. Full Copyright Statement 1177 Copyright (C) The Internet Society (2003). All Rights Reserved. 1179 This document and translations of it may be copied and furnished to 1180 others, and derivative works that comment on or otherwise explain it 1181 or assist in its implementation may be prepared, copied, published 1182 and distributed, in whole or in part, without restriction of any 1183 kind, provided that the above copyright notice and this paragraph are 1184 included on all such copies and derivative works. However, this 1185 document itself may not be modified in any way, such as by removing 1186 the copyright notice or references to the Internet Society or other 1187 Internet organizations, except as needed for the purpose of 1188 developing Internet standards in which case the procedures for 1189 copyrights defined in the Internet Standards process must be 1190 followed, or as required to translate it into languages other than 1191 English. 1193 The limited permissions granted above are perpetual and will not be 1194 revoked by the Internet Society or its successors or assigns. 1196 This document and the information contained herein is provided on an 1197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.