summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4482.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4482.txt')
-rw-r--r--doc/rfc/rfc4482.txt619
1 files changed, 619 insertions, 0 deletions
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 <person> or, less commonly, <tuple> element
+ in the presence data model [13]. The <tuple> 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 <relationship>
+ 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 <card> 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 <display-name> 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 <homepage> 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 <icon> 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 <map> 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 <sound> 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:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
+ xmlns:c="urn:ietf:params:xml:ns:pidf:cipid"
+ entity="pres:someone@example.com">
+
+ <tuple id="bs35r9">
+ <status>
+ <basic>open</basic>
+ </status>
+ <contact priority="0.8">im:alice@example.net</contact>
+ <timestamp>2005-11-21T16:14:29Z</timestamp>
+ </tuple>
+
+
+
+
+Schulzrinne Standards Track [Page 4]
+
+RFC 4482 CIPID July 2006
+
+
+ <dm:person id="p1">
+ <c:card>http://example.com/~alice/card.vcd</c:card>
+ <c:display-name>Alice Lewis</c:card>
+ <c:homepage>http://example.com/~alice</c:homepage>
+ <c:icon>http://example.com/~alice/me.png</c:icon>
+ <c:map>http://example.com/~alice/gml-map.xml</c:map>
+ <c:sound>http://example.com/~alice/hello.wav</c:sound>
+ <dm:timestamp>2005-11-21T09:00:00+05:00</dm:timestamp>
+ </dm:person>
+ </presence>
+
+ An example combining RPID and CIPID is shown below:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
+ xmlns:c="urn:ietf:params:xml:ns:pidf:cipid"
+ xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
+ xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
+ urn:ietf:params:xml:ns:pidf:data-model data-model.xsd
+ urn:ietf:params:xml:ns:pidf:cipid cipid.xsd
+ urn:ietf:params:xml:ns:pidf:rpid rpid.xsd"
+ entity="pres:someone@example.com">
+
+ <tuple id="bs35r9">
+ <status>
+ <basic>open</basic>
+ </status>
+ <contact priority="0.8">im:someone@mobile.example.net</contact>
+ <timestamp>2005-05-30T22:00:29Z</timestamp>
+ </tuple>
+
+ <tuple id="bs78">
+ <status>
+ <basic>closed</basic>
+ </status>
+ <r:relationship><r:assistant/></r:relationship>
+ <c:card>http://example.com/~assistant/card.vcd</c:card>
+ <c:homepage>http://example.com/~assistant</c:homepage>
+ <contact priority="0.1">im:assistant@example.com</contact>
+ <timestamp>2005-05-30T22:00:29Z</timestamp>
+ </tuple>
+
+ <dm:person id="p1">
+ <c:card>http://example.com/~someone/card.vcd</c:card>
+ <c:homepage>http://example.com/~someone</c:homepage>
+ <c:icon>http://example.com/~someone/icon.gif</c:icon>
+
+
+
+Schulzrinne Standards Track [Page 5]
+
+RFC 4482 CIPID July 2006
+
+
+ <c:map>http://example.com/~someone/gml-map.xml</c:map>
+ <c:sound>http://example.com/~someone/whoosh.wav</c:sound>
+ <dm:timestamp>2005-05-30T22:02:44+05:00</dm:timestamp>
+ </dm:person>
+ </presence>
+
+5. The XML Schema Definition
+
+ The schema is shown below.
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:cipid"
+ xmlns:cipid="urn:ietf:params:xml:ns:pidf:cipid"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified"
+ attributeFormDefault="unqualified">
+
+ <xs:annotation>
+ <xs:documentation>
+ Describes CIPID tuple extensions for PIDF.
+ </xs:documentation>
+ </xs:annotation>
+
+ <xs:element name="card" type="xs:anyURI"/>
+ <xs:element name="display-name" type="xs:string"/>
+ <xs:element name="homepage" type="xs:anyURI"/>
+ <xs:element name="icon" type="xs:anyURI"/>
+ <xs:element name="map" type="xs:anyURI"/>
+ <xs:element name="sound" type="xs:anyURI"/>
+ </xs:schema>
+
+ 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
+ <?xml version="1.0"?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
+ "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml
+ <head>
+ <meta http-equiv="content-type"
+ content="text/html;charset=iso-8859-1"/>
+ <title>CIPID: Contact Information for the Presence Information
+ Data Format</title>
+ </head>
+ <body>
+ <h1>Namespace for contact information presence extension
+ (status)</h1>
+ <h2>urn:ietf:params:xml:ns:pidf:cipid</h2>
+ <p>See <a href="http://www.rfc-editor.org/rfc/rfc4482.txt">
+ RFC4482</a>.</p>
+ </body>
+ </html>
+ 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 <display-name> 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 <?xml?> 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 <display-name> 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 <icon>,
+ <homepage>, <map>, <sound>, and <vcard> 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]
+