From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4482.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc4482.txt (limited to 'doc/rfc/rfc4482.txt') diff --git a/doc/rfc/rfc4482.txt b/doc/rfc/rfc4482.txt new file mode 100644 index 0000000..775ebb1 --- /dev/null +++ b/doc/rfc/rfc4482.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group H. Schulzrinne +Request for Comments: 4482 Columbia U. +Category: Standards Track July 2006 + + + CIPID: Contact Information for the Presence Information Data Format + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Presence Information Data Format (PIDF) defines a basic XML + format for presenting presence information for a presentity. The + Contact Information for the Presence Information Data format (CIPID) + is an extension that adds elements to PIDF that provide additional + contact information about a presentity and its contacts, including + references to address book entries and icons. + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne Standards Track [Page 1] + +RFC 4482 CIPID July 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology and Conventions .....................................3 + 3. CIPID Elements ..................................................3 + 3.1. Card Element ...............................................3 + 3.2. Display-Name Element .......................................3 + 3.3. Homepage Element ...........................................3 + 3.4. Icon Element ...............................................4 + 3.5. Map Element ................................................4 + 3.6. Sound Element ..............................................4 + 4. Example .........................................................4 + 5. The XML Schema Definition .......................................6 + 6. IANA Considerations .............................................7 + 6.1. URN Sub-Namespace Registration for .........................7 + 'urn:ietf:params:xml:ns:pidf:cipid' + 6.2. Schema Registration for Schema + 'urn:ietf:params:xml:ns:pidf:cipid' ........................7 + 7. Internationalization Considerations .............................8 + 8. Security Considerations .........................................8 + 9. References ......................................................9 + 9.1. Normative References .......................................9 + 9.2. Informative References ....................................10 + +1. Introduction + + Presence information facilitates communication; its usefulness can be + enhanced by providing basic information about a presentity or + contact. This specification describes a basic set of information + elements that allow a watcher to retrieve additional information + about a presentity or contact. + + This specification defines extensions to the PIDF [9] Extensible + Markup Language [7][8][10] (XML) document format. + + We describe elements for providing a "business card", references to + the homepage, map, representative sound, display name, and an icon. + This additional presence information can be used in PIDF [9] + documents, together with Rich Presence Information Data format [11] + (RPID), future-status [12], and other PIDF extensions. + + All elements extend the or, less commonly, element + in the presence data model [13]. The element is only + extended with Contact Information for the Presence Information Data + format (CIPID) elements if the information describes a service + referring to another person that is marked by an RPID + element with a value other than 'self'. All elements described in + this document are optional. + + + +Schulzrinne Standards Track [Page 2] + +RFC 4482 CIPID July 2006 + + + RPID and CIPID both provide "rich" presence that goes beyond the + basic 'open' and 'closed' status information in PIDF. The presence + information described in these two documents can be supplied + independently, although in practice, both will often appear in the + same PIDF document. CIPID elements describe the more static aspects + of somebody's presence information, while RPID focuses on elements + that will likely change throughout the day. Thus, CIPID information + can often be statically configured by the user through the graphical + user interface of a presence client; this is less likely to be + sufficient for RPID. + + The namespace URI for these elements defined by this specification is + a URN [2], using the namespace identifier 'ietf' defined by [4] and + extended by [6]: + + urn:ietf:params:xml:ns:pidf:cipid + +2. Terminology and Conventions + + The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, + RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted + as described in BCP 14, RFC 2119 [1]. + +3. CIPID Elements + + Unless otherwise noted below, each element may only appear at most + once. + +3.1. Card Element + + The element includes a URI pointing to a business card, e.g., + in LDAP Data Interchange Format [15] (LDIF) or vCard [14] format. + +3.2. Display-Name Element + + The element includes the name identifying the tuple or + person that the presentity suggests should be shown by the watcher + user interface. It is left to the watcher user interface design to + choose whether to heed this suggestion or to use some other suitable + string. The CIPID information MAY contain multiple display names, + but only if they are labeled with different 'xml:lang' attributes. + This allows a Korean-speaking presentity to convey its display name + in different languages, Latin and Hangul, for example. + +3.3. Homepage Element + + The element provides a URI pointing to general information + about the tuple or person, typically a web home page. + + + +Schulzrinne Standards Track [Page 3] + +RFC 4482 CIPID July 2006 + + +3.4. Icon Element + + The element provides a URI pointing to an image (icon) + representing the tuple or person. The watcher can use this + information to represent the tuple or person in a graphical user + interface. Presentities SHOULD provide images of sizes and aspect + ratios that are appropriate for rendering as an icon. Support for + JPEG, PNG, and GIF formats is REQUIRED. + +3.5. Map Element + + The element provides a URI pointing to a map related to the + tuple or person. The watcher can use this information to represent + the tuple or person in a graphical user interface. The map may be + either an image, an HTML client-side image map, or a geographical + information system (GIS) document, e.g., encoded as GML. Support for + images formatted as PNG and GIF is REQUIRED. + +3.6. Sound Element + + The element provides a URI pointing to a sound related to the + tuple or person. The watcher MAY use the sound object, such as a + MIDI or MP3 file, referenced by the URL to inform the watcher that + the presentity has assumed the status OPEN. Implementors are advised + to create user interfaces that provide the watcher with the + opportunity to choose whether to play such sounds. Support for + sounds coded as MPEG-2 Layer 3 (MP3) is RECOMMENDED. The sound + object might also be used to indicate how to pronounce the + presentity's name. + +4. Example + + An example using CIPID only is shown below: + + + + + + + open + + im:alice@example.net + 2005-11-21T16:14:29Z + + + + + +Schulzrinne Standards Track [Page 4] + +RFC 4482 CIPID July 2006 + + + + http://example.com/~alice/card.vcd + Alice Lewis + http://example.com/~alice + http://example.com/~alice/me.png + http://example.com/~alice/gml-map.xml + http://example.com/~alice/hello.wav + 2005-11-21T09:00:00+05:00 + + + + An example combining RPID and CIPID is shown below: + + + + + + + open + + im:someone@mobile.example.net + 2005-05-30T22:00:29Z + + + + + closed + + + http://example.com/~assistant/card.vcd + http://example.com/~assistant + im:assistant@example.com + 2005-05-30T22:00:29Z + + + + http://example.com/~someone/card.vcd + http://example.com/~someone + http://example.com/~someone/icon.gif + + + +Schulzrinne Standards Track [Page 5] + +RFC 4482 CIPID July 2006 + + + http://example.com/~someone/gml-map.xml + http://example.com/~someone/whoosh.wav + 2005-05-30T22:02:44+05:00 + + + +5. The XML Schema Definition + + The schema is shown below. + + + + + + + Describes CIPID tuple extensions for PIDF. + + + + + + + + + + + + Figure 1: CIPID schema + + + + + + + + + + + + + + + + + + + +Schulzrinne Standards Track [Page 6] + +RFC 4482 CIPID July 2006 + + +6. IANA Considerations + + This document calls for IANA to register a new XML namespace URN and + schema per [6]. + +6.1. URN Sub-Namespace Registration for + 'urn:ietf:params:xml:ns:pidf:cipid' + + URI: urn:ietf:params:xml:ns:pidf:cipid + Description: This is the XML namespace for XML elements defined by + RFC 4482 to describe contact information presence information + extensions for the status element in the PIDF presence document + format in the application/pidf+xml content type. + Registrant Contact: IETF, SIMPLE working group, simple@ietf.org; + Henning Schulzrinne, hgs@cs.columbia.edu + XML: + + BEGIN + + + + CIPID: Contact Information for the Presence Information + Data Format + + +

Namespace for contact information presence extension + (status)

+

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

+

See + RFC4482.

+ + + END + +6.2. Schema Registration for Schema 'urn:ietf:params:xml:ns:pidf:cipid' + + URI: urn:ietf:params:xml:ns:pidf:cipid + Registrant Contact: IESG + XML: See Figure 1 + + + + + + + + +Schulzrinne Standards Track [Page 7] + +RFC 4482 CIPID July 2006 + + +7. Internationalization Considerations + + CIPID delivers only URLs, except for the element. The + resolution of the URLs can negotiate appropriate language and + character sets within the URL-designated protocol. + + For the display name and to handle Internationalized Resource + Identifiers (IRIs) [16], since CIPID is represented in XML, it + provides native support for encoding information using the Unicode + character set and its more compact representations including UTF-8. + Conformant XML processors recognize both UTF-8 and UTF-16. Though + XML includes provisions to identify and use other character encodings + through use of an "encoding" attribute in an declaration, use + of UTF-8 is RECOMMENDED in environments where parser encoding support + incompatibility exists. + + The XML 'xml:lang' attribute can be used to identify the language and + script for the element. The specification allows + multiple occurrences of this element so that the presentity can + convey display names in multiple scripts and languages. If no 'xml: + lang' attribute is provided, the default value is "i-default" [3]. + +8. Security Considerations + + The security issues are similar to those for RPID [11]. Watchers + need to restrict which content types of content pointed to by , + , , , and elements they render. + + Also, when a watcher accesses these URIs, the presentity may deduce + that the watcher is currently using the presence application. Thus, + a presence application concerned about leaking this information may + want to cache these objects for later use. (A presentity could + easily customize the URLs for each watcher, so that it can tell who + is referencing the objects.) This caching behavior may cause the + information to become stale, out-of-sync with the current data until + the cache is refreshed. Fortunately, the elements in CIPID are + expected to retain the same content for periods measured in days, so + that privacy-conscious applications may well decide to perform + caching over durations that reveal little current activity + information. Presentities need to keep in mind that clients may + cache the content referenced by URIs for long periods as they use + their presence system to construct presence documents using this + extension. If the referenced content needs to change frequently, the + presentity could, for example, update the presence document with a + new URI to encourage clients to notice. + + + + + + +Schulzrinne Standards Track [Page 8] + +RFC 4482 CIPID July 2006 + + + Icons and other URIs in this document could be used as a covert + channel to convey messages to the watcher, outside the content + monitoring that might be in place for instant messages or other + communications channels. Thus, entities that worry about such + channels may want to prohibit the usage of URLs pointing to resources + outside their domain, for example. + + Implementors must take care to adhere to the mechanisms for verifying + the identity in the referenced server's certificate against the URI. + For instance, if the URI scheme is https, the requirements of RFC + 2818 [5], section 3.1, must be met. In particular, the domain + represented in the URI must match the subjectAltName in the + certificate presented by the referenced server. If this identity + check fails, the referenced content SHOULD NOT be retrieved and MUST + NOT be used. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", + BCP 18, RFC 2277, January 1998. + + [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, + August 1999. + + [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January + 2004. + + [7] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML + Schema Part 1: Structures Second Edition", W3C REC REC- + xmlschema-1-20041028, October 2004. + + [8] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second + Edition", W3C REC REC-xmlschema-2-20041028, October 2004. + + [9] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and + J. Peterson, "Presence Information Data Format (PIDF)", RFC + 3863, August 2004. + + + + + +Schulzrinne Standards Track [Page 9] + +RFC 4482 CIPID July 2006 + + + [10] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. + Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", + W3C REC REC-xml-20040204, February 2004. + +9.2. Informative References + + [11] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, + "RPID: Rich Presence Extensions to the Presence Information Data + Format (PIDF)", RFC 4480, July 2006. + + [12] Schulzrinne, H., "Timed Presence Extensions to the Presence + Information Data Format (PIDF) to Indicate Status Information + for Past and Future Time Intervals", RFC 4481, July 2006. + + [13] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. + + [14] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC + 2426, September 1998. + + [15] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical + Specification", RFC 2849, June 2000. + + [16] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + +Acknowledgements + + This document is based on discussions within the IETF SIMPLE working + group. Spencer Dawkins, Vijay Gurbani, Avshalom Houri, Hisham + Khartabil, Paul Kyzivat, Eva Leppanen, Mikko Lonnfors, Aki Niemi, Jon + Peterson, Jonathan Rosenberg, and Robert Sparks provided helpful + comments. + +Author's Address + + Henning Schulzrinne + Columbia University + Department of Computer Science + 450 Computer Science Building + New York, NY 10027 + US + + Phone: +1 212 939 7004 + EMail: hgs+simple@cs.columbia.edu + URI: http://www.cs.columbia.edu + + + + + + +Schulzrinne Standards Track [Page 10] + +RFC 4482 CIPID July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Schulzrinne Standards Track [Page 11] + -- cgit v1.2.3