idnits 2.17.1 draft-ietf-impp-cpim-pidf-07.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (December 2002) is 7802 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 239, but not defined ** Obsolete undefined reference: RFC 2426 (Obsoleted by RFC 6350) == Missing Reference: 'RFC 2048' is mentioned on line 850, but not defined ** Obsolete undefined reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) == Missing Reference: 'RFC 3023' is mentioned on line 911, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Missing Reference: 'RFCXXXX' is mentioned on line 956, but not defined == Unused Reference: 'MIME' is defined on line 1043, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2778 ** Downref: Normative reference to an Informational RFC: RFC 2779 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) -- 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-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSchema1' == Outdated reference: A later version (-03) exists of draft-ietf-impp-cpim-02 == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-06 -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) Summary: 13 errors (**), 0 flaws (~~), 11 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 Baltimore Technologies 7 A. Bateman 8 VisionTech 9 W. Carr 10 Intel 11 J. Peterson 12 NeuStar 14 Expires: June 2003 December 2002 16 Common Presence and Instant Messaging (CPIM) 17 Presence Information Data Format 18 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet- Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Please send comments to the authors or to the impp@iastate.edu 42 discussion list. 44 Copyright Notice 46 Copyright (C) The Internet Society (2002). All Rights Reserved. 48 Abstract 50 This memo specifies the Common Presence and Instant Messaging (CPIM) 51 Presence Information Data Format (PIDF) as a common presence data 52 format for CPIM-compliant Instant Messaging and Presence protocols, 53 and also defines a new media type "application/cpim-pidf+xml" to 54 represent the XML MIME entity for PIDF. 56 Table of Content 58 1. Introduction ......................................... 4 59 1.1. Terminology and Conventions .......................... 4 60 2. Design Decisions ..................................... 5 61 2.1. Minimal Model ........................................ 5 62 2.2. Added Features ....................................... 6 63 2.3. XML Encoding Decision ................................ 6 64 3. Overview of Presence Information Data Format ......... 7 65 3.1. The 'application/cpim-pidf+xml' Content Type ......... 7 66 3.2. Presence Information Contents ........................ 7 67 4. XML-encoded Presence Data Format ..................... 7 68 4.1. XML Format Definitions ............................... 8 69 4.1.1. The element ............................... 8 70 4.1.2. The element .................................. 8 71 4.1.3. The element ................................. 9 72 4.1.4. The element .................................. 10 73 4.1.5. The element ................................ 10 74 4.1.6. The element ................................... 10 75 4.1.7. The element .............................. 11 76 4.2. Presence Information Extensibility ................... 11 77 4.2.1. XML Namespaces Background ............................ 11 78 4.2.2. XML Namespaces In Presence Information ............... 12 79 4.2.3. Handling Of Unrecognized Element Names ............... 13 80 4.2.4. Status Value Extensibility ........................... 14 81 4.2.5. Standardizing Status Extensions ...................... 15 82 4.3. Examples ............................................. 16 83 4.3.1. Default Namespace with Status Extensions ............. 16 84 4.3.2. Presence with Other Extension Elements ............... 16 85 4.3.3. Example Mandatory To Understand Elements ............. 17 86 4.4. XML Schema Definitions ............................... 17 87 5. IANA Considerations .................................. 19 88 5.1. Content-type registration for 89 'application/cpim-pidf+xml' .................. 20 90 5.2. URN sub-namespace registration for 91 'urn:ietf:params:xml:ns:cpim-pidf' ........... 21 92 5.3. URN sub-namespace registration for 93 'urn:ietf:params:xml:ns:cpim-pidf:status' .... 22 94 6. Security Considerations .............................. 22 95 7. Internationalization Considerations .................. 23 96 8. Normative References ................................. 23 97 9. Informative References ............................... 24 98 10. Authors' Addresses .................................. 25 99 11. Appendix A. Document Type Definitions ............... 26 100 12. Full Copyright Statement ............................ 27 102 1. Introduction 104 The Common Profile for Instant Messaging (CPIM) specifications define 105 a set of common operations and various formats to achieve 106 interoperability between different Instant Messaging and Presence 107 protocols which meet RFC 2779 [RFC2779]. The CPIM core specification 108 [CPIM] defines a set of common operations and their parameters to be 109 supported by interworking Presence and IM protocols in order to allow 110 straightforward gatewaying between them. The CPIM Message Format 111 [CPIM-MSG] defines a common format for instant messages, which 112 enables secure end-to-end IM exchange through the gateways. 114 This memo further defines the CPIM Presence Information Data Format 115 (PIDF) as a common presence data format for CPIM-compliant presence 116 protocols. The significance of the common presence format primarily 117 resides in the fact that it alleviates the load of gatewaying of 118 messages with presence data payloads. Without such a common presence 119 data format, a gateway must process and transform the presence data 120 payload from one format to another every time it gateways the 121 protocol messages. Such payload processing also disables the 122 validity of digitally signed presence data. Utilizing the common 123 presence data format allows secure transfer of the presence payloads 124 across the boundary of different protocol domains. 126 The format specified in this memo is intended to define the base 127 presence format and extensibility required by RFC 2779. It only 128 defines a minimal set of presence status values defined by the IMPP 129 Model document [RFC2778]. However, a presence application is able to 130 define its own status values using the extensibility framework 131 provided by this memo. Defining such extended status values is 132 beyond the scope of this memo. 134 Note also that this memo defines only the format for a presence data 135 payload and the extensibility framework for it. How the presence data 136 is transferred within a specific protocol frame would be defined 137 separately in a protocol specification. 139 1.1. Terminology and Conventions 141 This memo makes use of the vocabulary defined in the IMPP Model 142 document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, 143 PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the 144 memo are used in the same meaning as defined therein. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 147 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 148 interpreted as described in RFC 2119 [RFC2119]. 150 [[[Editorial comments and questions about outstanding issues are 151 provided in triple brackets like this. These working comments should 152 be resolved and removed prior to final publication.]]] 154 2. Design Decisions 156 We have adopted the IMPP Model and Requirements documents [RFC2778, 157 RFC2779] as the starting point of our discussion. The two RFCs 158 contains a number of statements about presence information, which can 159 be regarded as a basic set of constraints for the format design. 160 Also, we took the minimalist approach to the design based on them. 161 Starting from the minimal model, only the features that are necessary 162 to solve particular problems have been combined. 164 2.1. Minimal Model 166 This specification is based on the minimal model extracted from the 167 IMPP Model and Requirements documents. The model consists of the 168 following items. Each of them is accompanied with the corresponding 169 RFCs and their section numbers as its grounds, e.g. (RFC2778:Sec.2.4) 170 refers to Section 2.4 of RFC 2778. 172 (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, 173 where a PRESENCE TUPLE consists of a STATUS, an optional 174 COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. 175 Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is 176 understood more narrowly in this document to refer only to a 177 URI. (RFC2778:Sec.3) 179 (b) STATUS has at least the mutually-exclusive values OPEN and 180 CLOSED, which have meaning for the acceptance of INSTANT 181 MESSAGES, and may have meaning for other COMMUNICATION MEANS. 182 There may be other values of STATUS that do not imply anything 183 about INSTANT MESSAGE acceptance. These other values of STATUS 184 may be combined with OPEN and CLOSED or they may be mutually- 185 exclusive with those values. (RFC2778:Sec.3, RFC2779:Sec.4.4.1- 186 4.4.3) 188 (c) STATUS may consist of single or multiple values. (RFC2778:Sec.2.4) 190 (d) There must be a means of extending the common presence format 191 to represent additional information not included in the common 192 format. The extension and registration mechanisms must be 193 defined for presence information schema, including new STATUS 194 conditions and new forms for OTHER PRESENCE MARKUP. (RFC2779: 195 Sec.3.1.4-3.1.5) 197 (e) The common presence format must include a means to uniquely 198 identify the PRESENTITY whose PRESENCE INFORMATION is reported. 199 (RFC2779:Sec.3.1.2) 201 (f) The common presence format must allow the PRESENTITY to secure 202 presence information sent to a WATCHER. The format must allow 203 integrity, confidentiality and authentication properties to be 204 applied to presence information. (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 205 5.3.3) 207 2.2. Added Features 209 In addition to the minimal model described above, the format 210 specified in this specification has the following features. 212 (a) Relative priorities of contact addresses should be specifiable 213 in order to allow the source of PRESENCE INFORMATION to tell the 214 receiver (WATCHER USER AGENTS) its preference over multiple contact 215 means. 217 (b) The presence format should be able to contain the timestamp of 218 the creation of the PRESENCE INFORMATION. The timestamp in the 219 presence document lets the receiver know the time of the creation 220 of the data even if the message containing it arrives late for 221 some reason. It can also be used to detect a replay attack, 222 independent of the underlying signature mechanism. Note that 223 this mechanism does not assume any global time synchronization 224 system for watchers and presentities (see Appendix A of RFC2779, 225 8.1.4 A7), but rather assumes that the minimum length of time 226 that might pass before presence information is considered stale 227 is long enough that minor variations among system clocks will not 228 lead to misjudgments of the freshness of presence information." 230 2.3. XML Encoding Decision 232 The CPIM Presence Information Data Format encodes presence 233 information in XML (eXtensible Markup Language [XML]), which is 234 rapidly gaining broad acceptance as a syntactic framework to encode 235 structured data transferred over the Internet. Regarding the 236 features of PRESENCE INFORMATION discussed above, such that it has a 237 hierarchical structure and it should be fully extensible, XML is 238 considered as the most desirable framework over other candidates such 239 as vCard [RFC2426]. 241 3. Overview of Presence Information Data Format 243 This section describes an overview of the presence data format 244 defined in this memo. 246 3.1. The 'application/cpim-pidf+xml' Content Type 248 This memo defines a new content type "application/cpim-pidf+xml" for 249 an XML MIME entity that encodes presence information conformant to 250 this specification. This specification follows the recommendations 251 and conventions described in [RFC3023], including the naming 252 convention of the type ('+xml' suffix) and the usage of the 'charset' 253 parameter. 255 Although it is defined as optional, use of the 'charset' parameter is 256 STRONGLY RECOMMENDED. If the 'charset' parameter is not specified, 257 conforming XML processors to [XML] MUST follow the requirements in 258 section 4.3.3 of [XML]. 260 3.2. Presence Information Contents 262 This subsection outlines the information in an "application/cpim- 263 pidf+xml" document. A full definition of the PIDF content is in 264 Section 4. 266 o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY. 267 o List of presence tuples 268 - Status: OPEN/CLOSED for Instant Messaging or status for 269 other communication means. 270 - Communication address: communication means and contact 271 address of this tuple. (optional) 272 - Relative priority: numerical value specifying the priority 273 of this communication address. (optional) 274 - Timestamp: timestamp of the change of this tuple.(optional) 275 - Human readable comment: free text memo about this tuple 276 (optional) 277 o PRESENTITY human readable comment: free text memo about the 278 PRESENTITY (optional). 280 4. XML-encoded Presence Data Format 282 This section defines an XML-encoded presence information data format 283 (PIDF) for use with CPIM compliant systems. A presence payload in 284 this format is expected to be produced by the PRESENTITY (the source 285 of the PRESENCE INFORMATION) and transported to the WATCHERS by the 286 presence servers or gateways without any interpretation or 287 modification. 289 4.1. XML Format Definitions 291 A PIDF object is a well formed XML document. 293 It MUST have the XML declaration and it SHOULD contain an encoding 294 declaration in the XML declaration, e.g. "". If the charset parameter of the MIME content 296 type declaration is present and it is different from the encoding 297 declaration, the charset parameter takes precedence. 299 Every application conformant to this specification MUST accept the 300 UTF-8 character encoding to ensure the minimal interoperability. 302 4.1.1. The element 304 The root element of the "application/cpim-pidf+xml" object is defined 305 as . This element contains any number (including 0) of 306 elements, followed by any number (including 0) of 307 elements, followed by any number of OPTIONAL extension elements from 308 other namespaces. 310 The element MUST have an 'entity' attribute. The value of 311 the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing 312 this presence document. 314 The element MUST contain a namespace declaration ('xmlns') 315 to indicate the namespace on which the presence document is based. 316 The presence document compliant to this specification MUST have the 317 namespace 'urn:ietf:params:xml:ns:cpim-pidf:'. 319 It MAY contain other namespace declarations for the extensions used 320 in the presence XML document. 322 4.1.2. The element 324 The element is used to carry a piece of PRESENCE INFORMATION 325 defined as PRESENCE TUPLE in RFC2778. Thus, it contains one 326 mandatory element, followed by any number of OPTIONAL 327 extension elements from other namespaces, followed by one OPTIONAL 328 elements, followed by any number of OPTIONAL 329 elements, followed by one OPTIONAL elements. 331 Tuples provide a way of segmenting presence information. Protocols or 332 applications may choose to segment the presence information 333 associated with a presentity for any number of reasons - for example, 334 because components of the full presence information for a presentity 335 have come from distinct devices or different applications on the same 336 device, or have been generated at different times. Tuples should be 337 preferred over other manners of segmenting presence information such 338 as creating multiple PIDF instances. 340 The element MUST contain an 'id' attribute which is used to 341 distinguish this tuple from other tuples in the same XML document. 342 The value of an 'id' attribute MUST be unique within 'id' attribute 343 values of other tuples in the same document. An 'id' value is used 344 by applications processing the presence document to identify the 345 corresponding tuple in the previously acquired PRESENCE INFORMATION 346 of the same PRESENTITY. The value of the 'id' attribute SHOULD be 347 treated as just a CDATA value (no semantics). 349 The element is OPTIONAL because a PRESENTITY might need to 350 hide its COMMUNICATION ADDRESS or there might be tuples not related 351 to any COMMUNICATION MEANS. Tuples that contain a status 352 element SHOULD contain a address. Tuples MAY contain 353 conflicting presence status - one might provide a 354 of OPEN, and another in the same PIDF could contain 355 a of CLOSED, even if they both contain the same 356 address. 358 The manner in which segmented presence information is understood by 359 the WATCHER USER AGENT is highly dependent on the capabilities of the 360 WATCHER USER AGENT and the presence application in question. In the 361 absence of any application-specific or protocol-specific 362 understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey 363 the following guidelines. WATCHER USER AGENTS should note which 364 tuples in the PIDF have changed their state since the last 365 notification by correlating the 'id' of each with those 366 received in previous notifications and comparing both values 367 and elements in the tuples, if any are present. 369 4.1.3. The element 371 The element contains one OPTIONAL elements, followed 372 by any number of OPTIONAL extension elements from other namespaces, 373 under the restriction that at least one child element appears in the 374 element. These children elements of contain status 375 values of this tuple. By allowing multiple status values in a single 376 element, different types of status values, e.g. reachability 377 and location, can be represented by a . See Section 4.3 for an 378 example with multiple status values. 380 This memo only defines the status value element. Other status 381 values may be included using the standard extensibility framework 382 (see Section 4.2.4). Applications encountering unrecognized elements 383 within may ignore them, unless they carry a 384 mustUnderstand="true" or mustUnderstand="1" attribute (see section 385 4.2.3). 387 Note that, while the element MUST have at least one status 388 value element, this status value may not be the element. 390 4.1.4. The element 392 The element contains one of the following strings: "open" or 393 "closed". The values "open" and "closed" has the same meaning as 394 OPEN and CLOSED defined in RFC 2778 respectively, and stand for 395 availability of receiving instant messages if the is for an 396 instant messaging address. They also have meanings of general 397 availability for other communication means. But, this memo does not 398 specify them in detail. 400 4.1.5. The element 402 The element contains a URL of the contact address. It 403 optionally has a 'priority' attribute, whose value means a relative 404 priority of this contact address over the others. The value of the 405 attribute MUST be a decimal number between 0 and 1 inclusive with at 406 most 3 digits after the decimal point. Higher values indicate higher 407 priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the 408 'priority' attribute is omitted, applications MUST understand that 409 the contact address has the lowest priority. If the 'priority' value 410 is out of the range, applications just SHOULD ignore the value and 411 process it as if the attribute was not present. 413 It is RECOMMENDED that applications handles a contact with higher 414 priority than another one so that the priority is recognizable by 415 users. How to handle contacts with the same priority is up to 416 implementations. 418 4.1.6. The element 420 The element contains a string value, which is usually used for 421 a human readable comment. A element MAY appear as a child 422 element of or as a child element of the element. 423 In the former case, the comment is about the PRESENTITY and, in the 424 latter case, the comment is regarding the particular tuple. 426 Note that, wherever it appears, a element SHOULD NOT be used, 427 and interpreted, as a non-interoperable substitute for status of its 428 parent element. 430 The element SHOULD have a special attribute 'xml:lang' to 431 specify the language used in the contents of this element as defined 432 in Section 2.12 of [XML]. The value of this attribute is the 433 language indentifier as defined by [RFC1766]. It MAY be omitted when 434 the language used is implied by the larger context such as the 435 encoding information of the contents, such as an xml:lang attribute 436 on an enclosing XML element, or a Content-language header [RFC3282] 437 on an enclosing MIME wrapper. 439 4.1.7. The element 441 The element contains a string indicating the date and 442 time of the status change of this tuple. The value of this element 443 MUST follow the IMPP datetime format [RFC3339]. Timestamps that 444 contain 'T' or 'Z' MUST use the capitalized forms. 446 As a security measure, the element SHOULD be included in 447 all tuples unless the exact time of the status change cannot be 448 determined. For security guidelines for watchers receiving presence 449 information with timestamps, see the Security Considerations. 451 4.2. Presence Information Extensibility 453 The presence information extensibility framework is based on XML 454 namespaces [XML-NS]. 456 RFC2779 requires that PIDF have a means of extending values 457 beyond . These extensions MUST NOT modify how is to be 458 understood, nor change the the structure or semantics of PIDF bodies 459 themselves. These extensions merely allow protocols and applications 460 to define richer presence data. 462 4.2.1. XML Namespaces Background 464 All elements and some attributes are associated with a "namespace", 465 which is in turn associated with a globally unique URI. Any 466 developer can introduce their own element names, avoiding conflict by 467 choosing an appropriate namespace URI. 469 Within the presence data, element or attribute names are associated 470 with a particular namespace by a namespace prefix, which is a leading 471 part of the name, followed by a colon (":"); e.g. 473 ... 475 Where, 'prefix' is the header name prefix, 'element-name' is a name 476 which is scoped by the namespace associated with 'prefix'. Note that 477 the choice of 'prefix' is quite arbitrary; it is the corresponding 478 URI that defines the naming scope. Two different prefixes associated 479 with the same namespace URI refer to the same namespace. 481 A default namespace can be declared for XML elements without a 482 namespace prefix. The default namespace does NOT apply to attribute 483 names, but interpretation of an unprefixed attribute can be 484 determined by the containing element. 486 A namespace is identified by a URI. In this usage, the URI is used 487 simply as a globally unique identifier, and there is no requirement 488 that it can be used to retrieve a web resource, or for any other 489 purpose. Any legal globally unique URI MAY be used to identify a 490 namespace. (By "globally unique", we mean constructed according to 491 some set of rules so that it is reasonable to expect that nobody else 492 will use the same URI for a different purpose.) 494 For further details, see the XML namespace specification [XML-NS]. 496 4.2.2. XML Namespaces In Presence Information 498 A URI used as a namespace identifier in PRESENCE INFORMATION data 499 MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and 500 URI- references containing fragment identifiers MUST NOT be used for 501 this purpose.) 503 The namespace URI for elements defined by this specification is a URN 504 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 505 and extended by [XML-Registry]: 507 urn:ietf:params:xml:ns:cpim-pidf 509 Thus, simple presence data might be thus: 511 512 514 515 516 open 517 518 tel:09012345678 519 520 522 or, using a default XML namespace: 524 525 527 528 529 open 530 531 tel:09012345678 532 533 535 As is generally the case in XML, the xmlns attribute can be used on 536 any element in the presence information to define either the default 537 namespace or a namespace associated with a 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 use 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, which attribute name is associated with 553 the CPIM presence namespace.See section 4.3.3 for an example. 555 NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute 556 within an element that is being ignored is itself ignored. The 557 writer of nested mandatory-to-understand information is responsible 558 for ensuring that any enclosing element is also labelled with a 559 mustUnderstand='true' or mustUnderstand='1' attribute, if 560 necessary. 562 This specification defines (section 4.1) elements within the 563 'urn:ietf:params:xml:ns:cpim-pidf' namespace that MUST be recognized 564 in CPIM presence data. Processors MUST handle these as described, 565 even if they do not carry a mustUnderstand attribute. The XML Schema 566 Definition (section 4.4) indicates those elements that MUST be 567 present in a valid presence information document. 569 If an agent receives PRESENCE INFORMATION with a block 570 containing an unrecognized element that has a mustUnderstand='true' 571 (or '1') attribute, it should treat the entire element as 572 unrecognized and not attempt to process it. 574 Note that the mustUnderstand attribute MUST NOT be used in a way that 575 might prevent a minimal implementation from understanding the basic 576 PIDF information defined in this specification. To ensure this, the 577 mustUnderstand attribute MUST NOT be used outside elements within 578 optional, so that non-recognition of a mandatory extension results in 579 no worse than ignoring the optional extension in which it is 580 contained. 582 4.2.4. Status Value Extensibility 584 This memo only defines the status value with values of "open" 585 and "closed". Other status values are possible using the standard 586 namespace-based extensibility rules defined above. 588 For example, a location status value might be included thus: 590 591 594 595 596 open 597 home 598 599 im:someone@example.com 600 601 603 Some new status values will 'extend' the value of the 604 element. For example, a status value defined for use with instant 605 messaging may include values such as 'away', 'busy' and 'offline'. In 606 order that some level of interoperability be maintained with user 607 agents that don't recognise the new extension, the status 608 value must also be included. This means that extensions are not 609 obligated to define a mapping from each of their values to OPEN or 610 CLOSED. 612 4.2.5. Standardizing Status Extensions 614 Although the existing PIDF definition allows arbitrary elements to 615 appear in the element, it may be sometimes desirable to 616 standardize extension status elements and their semantics (the 617 meanings of particular statuses, how their should be interpreted). 618 The URN 'urn:ietf:params:xml:ns:cpim-pidf:status' has been defined as 619 a namespace URI for extensions standardized by the IETF, and new 620 values in this namespace must be defined by a standards-track RFC. 622 The following example XML Schema defines an extension for 623 presence information, which can have the values of 'home', 'office', 624 or 'car'. If the element were standardized, this document 625 would be made available in an RFC along with information about the 626 use of the extension. These extensions should use the namespace 627 'urn:ietf:params:xml:ns:cpim-pidf:status', and each RFC defining an 628 extension should register an extension name within that namespace 629 with IANA. 631 632 638 639 640 641 642 643 644 646 648 In addition to the XML Schema to validate the extension, registration 649 of the extension name with IANA, RFCs defining extensions MUST 650 discuss: 652 - The domain of applicability of the extension. Is this extension 653 exclusively valuable to IM clients, telephones, geolocators, etc? 654 What sorts of presence applications would use this extension and 655 under what circumstances? 657 - Semantics for the presence states defined in the extension. What 658 disposition provokes an automated presentity to declare that it is 659 in state X, or does a human select X from a drag-down menu? Is 660 there any general guidance for watchers of presence information 661 with state Y (for example, how they should best attempt to 662 communicate with the presentity, if at all, when the principal is 663 in state Y). 665 Extensions SHOULD also discuss: 667 - How, if at all, any presence states defined in the extension 668 related to , or to any relevant extension previously 669 published in an RFC. For example, "state Z implies OPEN, so it MUST 670 NOT be used if a basic state of CLOSED is expressed", or "you 671 should use the extension in this document, not the extension in RFC 672 QQQQ, if your circumstances are as follows...." 674 4.3. Examples 676 4.3.1. Default Namespace with Status Extensions 678 679 683 684 685 open 686 busy 687 home 688 689 im:someone@mobilecarrier.net 690 Don't Disturb Please! 691 Ne derangez pas, s'il vous plait 692 2001-10-27T16:49:29Z 693 694 695 696 open 697 698 mailto:someone@example.com 699 700 I'll be in Tokyo next week 701 703 4.3.2. Presence with Other Extension Elements 705 706 709 710 711 open 712 713 Extended value in tuple 714 tel:09012345678 715 716 717 718 open 719 720 721 im:someone@mobilecarrier.net 722 723 My extended presentity information 724 726 4.3.3. Example Mandatory To Understand Elements 728 729 732 733 734 open 735 736 737 val1 738 val2 739 740 tel:09012345678 741 742 My extended presentity information 743 745 Here, must be understood and, if it is not recognized, 746 MUST be ignored. and 747 MAY be ignored if they are not recognized. 749 4.4. XML Schema Definitions 751 This section gives the XML Schema Definition [XMLSchema1] of the 752 "application/cpim-pidf+xml" format. This is presented as a formal 753 definition of the "application/cpim-pidf+xml" format. Note that the 754 XML Schema definition is not intended to be used with on-the-fly 755 validation of the presence XML document. 757 758 764 765 768 770 771 772 774 776 778 779 780 782 783 784 785 787 788 790 791 792 793 795 796 797 798 801 802 804 805 806 807 808 809 811 812 813 814 815 816 817 819 820 821 822 823 824 825 827 828 829 830 831 832 834 835 836 837 838 This attribute may be used on any element within an optional 839 PIDF extension to indicate that the corresponding element must 840 be understood by the PIDF processor if the enclosing optional 841 element is to be handled. 842 843 844 845 847 5. IANA Considerations 848 This memo calls for IANA to: 849 - register a new MIME content-type application/cpim-pidf+xml, 850 per [RFC 2048], 851 - register a new XML namespace URN per [XML-Registry]. 852 - register a new XML namespace URN for status extensions per 853 [XML-Registry]. 855 The registration templates for these are below. For more information 856 on status extensions, see section 4.2.5. 858 5.1. Content-type registration for 'application/cpim-pidf+xml' 860 To: ietf-types@iana.org 861 Subject: Registration of MIME media type application/cpim-pidf+xml 863 MIME media type name: application 865 MIME subtype name: cpim-pidf+xml 867 Required parameters: (none) 869 Optional parameters: charset 870 Indicates the character encoding of enclosed XML. Default is UTF-8. 872 Encoding considerations: 873 Uses XML, which can employ 8-bit characters, depending on the 874 character encoding used. 875 See RFC 3023 [RFC 3023], section 3.2. 877 Security considerations: 878 This content type is designed to carry presence data, which may 879 be considered private information. Appropriate precautions should 880 be adopted to limit disclosure of this information. 882 Interoperability considerations: 883 This content type provides a common format for exchange of presence 884 information across different CPIM compliant protocols. 886 Published specification: 887 RFCXXXX (this document) 889 Applications which use this media type: 890 Presence and instant messaging systems. 892 Additional information: 894 Magic number(s): 896 File extension(s): 897 Macintosh File Type Code(s): 899 Person & email address to contact for further information: 900 Hiroyasu Sugano 901 E-mail: sugano.h@jp.fujitsu.com 903 Intended usage: 904 LIMITED USE 906 Author/Change controller: 907 This specification is a work item of the IETF IMPP working group, 908 with mailing list address . 910 Other information: 911 This media type is a specialization of application/xml [RFC 3023], 912 and many of the considerations described there also apply to 913 application/cpim-pidf+xml. 915 5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim- 916 pidf' 918 URI 919 urn:ietf:params:xml:ns:cpim-pidf 921 Description: 922 This is the XML namespace URI for XML elements defined by [RFCXXXX] 923 to describe CPIM presence information in application/cpim-pidf+xml 924 content type. 926 Registrant Contact 927 IETF, IMPP working group, 928 Hiroyasu Sugano, 930 XML 931 BEGIN 932 933 935 936 937 939 Namespace for CPIM presence information 940 941 942

Namespace for CPIM presence information

943

application/cpim-pidf+xml

944

See RFCXXXX.

945 946 947 END 949 5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim- 950 pidf:status' 952 URI 953 urn:ietf:params:xml:ns:cpim-pidf:status 955 Description: 956 This is the XML namespace URI for XML elements defined by [RFCXXXX] 957 to describe extensions to the status of CPIM presence information 958 in application/cpim-pidf+xml content type. 960 Registrant Contact 961 IETF, IMPP working group, 962 Hiroyasu Sugano, 964 XML 965 BEGIN 966 967 969 970 971 973 Namespace for CPIM status extensions 974 975 976

Namespace for CPIM presence information extensions

977

application/cpim-pidf+xml

978

See RFCXXXX.

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