idnits 2.17.1 draft-ietf-simple-cipid-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2005) is 6692 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) ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4') ** Obsolete normative reference: RFC 2818 (ref. '5') (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-10) exists of draft-ietf-simple-rpid-09 == Outdated reference: A later version (-05) exists of draft-ietf-simple-future-04 == Outdated reference: A later version (-07) exists of draft-ietf-simple-presence-data-model-06 -- Obsolete informational reference (is this intentional?): RFC 2426 (ref. '12') (Obsoleted by RFC 6350) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: June 23, 2006 December 20, 2005 6 CIPID: Contact Information in Presence Information Data Format 7 draft-ietf-simple-cipid-07 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The Presence Information Data Format (PIDF) defines a basic XML 41 format for presenting presence information for a presentity. The 42 Contact Information for Presence Information Data Format (CIPID) is 43 an extension that adds elements to PIDF that provide additional 44 contact information about a presentity and its contacts, including 45 references to address book entries and icons. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 51 3. CIPID Elements . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1 Card Element . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.2 Display-Name Element . . . . . . . . . . . . . . . . . . . 4 54 3.3 Homepage Element . . . . . . . . . . . . . . . . . . . . . 4 55 3.4 Icon Element . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.5 Map Element . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.6 Sound Element . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. The XML Schema Definition . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6.1 URN Sub-Namespace Registration for 62 'urn:ietf:params:xml:ns:pidf:cipid' . . . . . . . . . . . 7 63 6.2 Schema Registration for Schema 64 urn:ietf:params:xml:ns:pidf:cipid' . . . . . . . . . . . . 8 65 7. Internationalization Considerations . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 69 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 71 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 Intellectual Property and Copyright Statements . . . . . . . . 12 74 1. Introduction 76 In its function of facilitating communication, the usefulness of 77 presence information can be enhanced by providing basic information 78 about a presentity or contact. This specification describes a basic 79 set of information elements that allow a watcher to retrieve 80 additional information about a presentity or contact. 82 This specification defines extensions to the PIDF [7] (Presence 83 Information Data Format) XML (Extensible Markup Language) [8] 84 document format. 86 We describe elements for providing a "business card", references to 87 the homepage, map, representative sound, display name and an icon. 88 This additional presence information can be used in PIDF [7] 89 documents, together with RPID [9] (Rich Presence Information Data 90 format), future-status [10] and other PIDF extensions. 92 All elements extend the or, less commonly, element 93 in the presence data model [11]. The element is only 94 extended with CIPID elements if the information describes a service 95 referring to another person that is marked by an RPID 96 element with a value other than 'self'. All elements described in 97 this document are optional. 99 RPID and CIPID both provide "rich" presence that goes beyond the 100 basic 'open' and 'closed' status information in PIDF. The presence 101 information described in these two documents can be supplied 102 independently, although in practice, both will often appear in the 103 same PIDF document. CIPID elements describe the more static aspects 104 of somebody's presence information, while RPID focuses on elements 105 that will likely change throughout the day. Thus, CIPID information 106 can often be statically configured by the user through the graphical 107 user interface of a presence client, while this is less likely to be 108 sufficient for RPID. 110 The namespace URI for these elements defined by this specification is 111 a URN [2], using the namespace identifier 'ietf' defined by [4] and 112 extended by [6]: 114 urn:ietf:params:xml:ns:pidf:cipid 116 2. Terminology and Conventions 118 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 119 RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 120 as described in BCP 14, RFC 2119 [1]. 122 3. CIPID Elements 124 Unless otherwise noted below, each element may only appear at most 125 once. 127 3.1 Card Element 129 The element includes a URI pointing to a business card, e.g., 130 in LDIF [13] or vCard [12] format. 132 3.2 Display-Name Element 134 The element includes the name identifying the tuple or 135 person that the presentity suggests should be shown by the watcher 136 user interface. It is left to the watcher user interface design to 137 choose whether to heed this suggestion or use some other suitable 138 string. The CIPID information MAY contain multiple display names, 139 but only if they are labeled with different 'xml:lang' attributes. 140 This allows a Korean-speaking presentity to convey its display name 141 in different Latin and Hangul, for example. 143 3.3 Homepage Element 145 The element provides a URI pointing to general information 146 about the tuple or person, typically a web home page. 148 3.4 Icon Element 150 The element provides a URI pointing to an image (icon) 151 representing the tuple or person. The watcher can use this 152 information to represent the tuple or person in a graphical user 153 interface. Presentities SHOULD provide images of sizes and aspect 154 ratios that are appropriate for rendering as an icon. Support for 155 JPEG, PNG and GIF formats is REQUIRED. 157 3.5 Map Element 159 The element provides a URI pointing to a map related to the 160 tuple or person. The watcher can use this information to represent 161 the tuple or person in a graphical user interface. The map may be 162 either an image, an HTML client-side image map or a geographical 163 information system (GIS) document, e.g., encoded as GML. Support for 164 images formatted as PNG and GIF is REQUIRED. 166 3.6 Sound Element 168 The element provides a URI pointing to a sound related to the 169 tuple or person. The watcher MAY use the sound object, such as a 170 MIDI or MP3 file, referenced by the URL to inform the watcher that 171 the presentity has assumed the status OPEN. Implementors are advised 172 to create user interfaces that provide the watcher with the 173 opportunity to choose whether to play such sounds. Support for 174 sounds coded as MPEG-2 Layer 3 (MP3) is RECOMMENDED. The sound 175 object might also be used to indicate how to pronounce the 176 presentity's name. 178 4. Example 180 An example using CIPID only is shown below: 182 183 192 193 194 open 195 196 im:alice@example.net 197 2005-11-21T16:14:29Z 198 200 201 http://example.com/~alice/card.vcd 202 Alice Lewis 203 http://example.com/~alice 204 http://example.com/~alice/me.png 205 http://example.com/~alice/gml-map.xml 206 http://example.com/~alice/hello.wav 207 2005-11-21T09:00:00+05:00 208 209 211 An example combining RPID and CIPID is shown below: 213 214 225 226 227 open 228 229 im:someone@mobile.example.net 230 2005-05-30T22:00:29Z 231 233 234 235 closed 236 237 238 http://example.com/~assistant/card.vcd 239 http://example.com/~assistant 240 im:assistant@example.com 241 2005-05-30T22:00:29Z 242 244 245 http://example.com/~someone/card.vcd 246 http://example.com/~someone 247 http://example.com/~someone/icon.gif 248 http://example.com/~someone/gml-map.xml 249 http://example.com/~someone/whoosh.wav 250 2005-05-30T22:02:44+05:00 251 252 254 5. The XML Schema Definition 256 The schema is shown below. 258 259 265 266 267 Describes CIPID tuple extensions for PIDF. 268 269 271 272 273 274 275 276 277 279 Figure 1: CIPID schema 281 6. IANA Considerations 283 This document calls for IANA to register a new XML namespace URN and 284 schema per [6]. 286 6.1 URN Sub-Namespace Registration for 287 'urn:ietf:params:xml:ns:pidf:cipid' 289 URI: urn:ietf:params:xml:ns:pidf:cipid 290 Description: This is the XML namespace for XML elements defined by 291 RFCXXXX to describe contact information presence information 292 extensions for the status element in the PIDF presence document 293 format in the application/pidf+xml content type. 294 Registrant Contact: IETF, SIMPLE working group, simple@ietf.org; 295 Henning Schulzrinne, hgs@cs.columbia.edu 296 XML: 298 BEGIN 299 300 302 306 CIPID -- Contact Information in Presence Information 307 Data Format 308 309 310

Namespace for contact information presence extension 311 (status)

312

urn:ietf:params:xml:ns:pidf:cipid

313

See RFCXXXX.

314 315 316 END 318 6.2 Schema Registration for Schema urn:ietf:params:xml:ns:pidf:cipid' 320 URI: please assign 321 Registrant Contact: IESG 322 XML: See Figure 1 324 7. Internationalization Considerations 326 CIPID delivers only URLs, except for the element. The 327 resolution of the URLs can negotiate appropriate language and 328 character sets within the URL-designated protocol. 330 For the display name and to handle Internationalized Resource 331 Identifiers (IRIs) [14], since CIPID is represented in XML, it 332 provides native support for encoding information using the Unicode 333 character set and its more compact representations including UTF-8. 334 Conformant XML processors recognize both UTF-8 and UTF-16. Though 335 XML includes provisions to identify and use other character encodings 336 through use of an "encoding" attribute in an declaration, use 337 of UTF-8 is RECOMMENDED in environments where parser encoding support 338 incompatibility exists. 340 The XML 'xml:lang' attribute can be used to identify the language and 341 script for the element. The specification allows 342 multiple occurrences of this element so that the presentity can 343 convey display names in multiple scripts and languages. If no 'xml: 345 lang' attribute is provided, the default value is "i-default" [3]. 347 8. Security Considerations 349 The security issues are similar to those for RPID [9]. Watchers need 350 to restrict which content types of content pointed to by , 351 , , , and elements they render. 353 Also, when a watcher accesses these URIs, the presentity may deduce 354 that the watcher is currently using the presence application. Thus, 355 a presence application concerned about leaking this information may 356 want to cache these objects for later use. (A presentity could 357 easily customize the URLs for each watcher, so that it can tell who 358 is referencing the objects.) This caching behavior may cause the 359 information to become stale, out-of-sync with the current data until 360 the cache is refreshed. Fortunately, the elements in CIPID are 361 expected to retain the same content for periods measured in days, so 362 that privacy-conscious applications may well decide to perform 363 caching over durations that reveal little current activity 364 information. Presentities need to keep in mind that clients may 365 cache the content referenced by URIs for long periods as they use 366 their presence system to construct presence documents using this 367 extension. If the referenced content needs to change frequently, the 368 presentity could, for example, update the presence document with a 369 new URI to encourage clients to notice. 371 Icons and other URIs in this document could be used as a covert 372 channel to convey messages to the watcher, outside the content 373 monitoring that might be in place for instant messages or other 374 communications channels. Thus, entities that worry about such 375 channels may want to prohibit the usage of URLs pointing to resources 376 outside their domain, for example. 378 Implementors must take care to adhere to the mechanisms for verifying 379 the identity in the referenced server's certificate against the URI. 380 For instance, if the URI scheme is https, the requirements of RFC 381 2818 [5], section 3.1, must be met. In particular, the domain 382 represented in the URI must match the subjectAltName in the 383 certificate presented by the referenced server. If this identity 384 check fails, the referenced content SHOULD NOT be retrieved and MUST 385 NOT be used. 387 9. References 389 9.1 Normative References 391 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 392 Levels", BCP 14, RFC 2119, March 1997. 394 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 396 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 397 BCP 18, RFC 2277, January 1998. 399 [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 400 August 1999. 402 [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 404 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 405 January 2004. 407 [7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 408 J. Peterson, "Presence Information Data Format (PIDF)", 409 RFC 3863, August 2004. 411 [8] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. 412 Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", 413 W3C REC REC-xml-20040204, February 2004. 415 9.2 Informative References 417 [9] Schulzrinne, H., "RPID: Rich Presence Extensions to the 418 Presence Information Data Format (PIDF)", 419 draft-ietf-simple-rpid-09 (work in progress), September 2005. 421 [10] Schulzrinne, H., "Timed Presence Extensions to the Presence 422 Information Data Format (PIDF) to Indicate Status Information 423 for Past and Future Time Intervals", 424 draft-ietf-simple-future-04 (work in progress), June 2005. 426 [11] Rosenberg, J., "A Data Model for Presence", 427 draft-ietf-simple-presence-data-model-06 (work in progress), 428 October 2005. 430 [12] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 431 RFC 2426, September 1998. 433 [13] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical 434 Specification", RFC 2849, June 2000. 436 [14] Duerst, M. and M. Suignard, "Internationalized Resource 437 Identifiers (IRIs)", RFC 3987, January 2005. 439 Author's Address 441 Henning Schulzrinne 442 Columbia University 443 Department of Computer Science 444 450 Computer Science Building 445 New York, NY 10027 446 US 448 Phone: +1 212 939 7004 449 Email: hgs+simple@cs.columbia.edu 450 URI: http://www.cs.columbia.edu 452 Appendix A. Acknowledgments 454 This document is based on discussions within the IETF SIMPLE working 455 group. Spencer Dawkins, Vijay Gurbani, Avshalom Houri, Hisham 456 Khartabil, Paul Kyzivat, Eva Leppanen, Mikko Lonnfors, Aki Niemi, Jon 457 Peterson, Jonathan Rosenberg and Robert Sparks provided helpful 458 comments. 460 Intellectual Property Statement 462 The IETF takes no position regarding the validity or scope of any 463 Intellectual Property Rights or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; nor does it represent that it has 467 made any independent effort to identify any such rights. Information 468 on the procedures with respect to rights in RFC documents can be 469 found in BCP 78 and BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the use of 474 such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR repository at 476 http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights that may cover technology that may be required to implement 481 this standard. Please address the information to the IETF at 482 ietf-ipr@ietf.org. 484 Disclaimer of Validity 486 This document and the information contained herein are provided on an 487 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 488 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 489 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 490 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 491 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 492 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 494 Copyright Statement 496 Copyright (C) The Internet Society (2005). This document is subject 497 to the rights, licenses and restrictions contained in BCP 78, and 498 except as set forth therein, the authors retain all their rights. 500 Acknowledgment 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society.