doc: Add RFC documents

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]
+