idnits 2.17.1 draft-saintandre-xmpp-pidf-00.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: ---------------------------------------------------------------------------- == 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 (February 6, 2004) is 7385 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES' == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-22 == Outdated reference: A later version (-09) exists of draft-ietf-xmpp-e2e-07 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-21 == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-pidf-lo-00 == Outdated reference: A later version (-10) exists of draft-ietf-simple-rpid-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Jabber Software Foundation 4 Expires: August 6, 2004 February 6, 2004 6 Transporting Presence Information Data Format (PIDF) over the 7 Extensible Messaging and Presence Protocol (XMPP) 8 draft-saintandre-xmpp-pidf-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 6, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document defines how to send information encoded in the CPIM 39 Presence Information Data Format (PIDF) over the Extensible Messaging 40 and Presence Protocol (XMPP). 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 49 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 50 Normative References . . . . . . . . . . . . . . . . . . . . . 5 51 Informative References . . . . . . . . . . . . . . . . . . . . 5 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 53 Intellectual Property and Copyright Statements . . . . . . . . 7 55 1. Introduction 57 The Presence Information Data Format ([PIDF]) defines a common 58 presence data format for presence protocols that conform to the 59 Common Profile for Presence ([CPP]), enabling presence information to 60 be transferred across CPP-compliant protocol boundaries without 61 modification, with attendant benefits for security and performance. 62 Because the syntax for PIDF is XML [XML], it should be 63 straightforward to send PIDF data over the Extensible Messaging and 64 Presence Protocol [XMPP-CORE], since XMPP is simply an XML streaming 65 protocol. This memo defines a mechanism for encapsulating PIDF data 66 within an "extended namespace" contained in an XMPP presence stanza. 68 1.1 Terminology 70 This document inherits terminology defined in [PIDF], [XMPP-CORE], 71 and [XMPP-IM]. 73 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 74 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 75 "OPTIONAL" in this document are to be interpreted as described in RFC 76 2119 [TERMS]. 78 1.2 Discussion Venue 80 The author welcomes discussion and comments related to the topics 81 presented in this document. The preferred forum is the 82 mailing list, for which archives and subscription 83 information are available at . 86 2. Protocol 88 The PIDF format is defined in [PIDF]. Briefly, the XML namespace 89 name is 'urn:ietf:params:xml:ns:pidf', the root element is , the element must possess an 'entity' attribute, and 91 the element may contain any number of child 92 elements specying information about an entity. 94 The recommended method for encapsulating PIDF data within an XMPP 95 presence stanza is by including the PIDF element as a 96 child of the XMPP stanza. Although it may appear that 97 this is potentially confusing, the inclusion of the 98 'urn:ietf:params:xml:ns:pidf' namespace ensures that PIDF data is 99 kept separate from XMPP presence data (in accordance with 100 [XML-NAMES]). The following is a simple example of encapsulating 101 PIDF data within an "extended namespace" in XMPP: 103 A basic example of PIDF over XMPP: 105 106 dnd 107 Wooing Juliet 108 110 111 112 open 113 114 115 116 118 Because base PIDF data does not encapsulate any additional 119 information over and above XMPP presence stanzas, there is little 120 point to including it in native XMPP systems when it is not encrypted 121 (obviously, encrypting PIDF data can help to ensure end-to-end 122 encryption of presence information, as described in [XMPP-E2E]). The 123 power of PIDF in the context of XMPP derives from extensions thereto, 124 such as the rich presence formats described in [RPID] and the 125 geographical location formats described in [GEOLOC]. Any such 126 extension to PIDF can be included in an XMPP presence stanza, since, 127 according to the definition of "extended namespaces" in [XMPP-IM], 128 the format of such extended data is defined by the extension rather 129 than by the base XMPP specification itself. Thus the ability to 130 include PIDF data and PIDF data extensions in XMPP enables XMPP-aware 131 applications to include any PIDF-compatible data that is currently 132 defined or that may be defined in the future. Naturally, there is no 133 guarantee that all XMPP entities will be able to understand such PIDF 134 data, and entities that do not understand the data MUST ignore it; 135 however, this memo at least defines a mechanism for including PIDF 136 data, which XMPP applications are encouraged to implement if they 137 desire to make use of PIDF data extensions for rich presence, 138 geographical location, and other kinds of presence-related 139 information. 141 3. IANA Considerations 143 This document requires no action on the part of the IANA. 145 4. Security Considerations 147 Detailed security considerations for XMPP are given in XMPP Core 148 [XMPP-CORE]. 150 Normative References 152 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 153 draft-ietf-impp-pres-04 (work in progress), August 2003. 155 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. 156 and J. Peterson, "Presence Information Data Format 157 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), 158 May 2003. 160 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, March 1997. 163 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 164 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C 165 REC-xml, October 2000, . 167 [XML-NAMES] 168 Bray, T., Hollander, D. and A. Layman, "Namespaces in 169 XML", W3C REC-xml-names, January 1999, . 172 [XMPP-CORE] 173 Saint-Andre, P., "Extensible Messaging and Presence 174 Protocol (XMPP): Core", draft-ietf-xmpp-core-22 (work in 175 progress), January 2004. 177 [XMPP-E2E] 178 Saint-Andre, P., "End-to-End Object Encryption in the 179 Extensible Messaging and Presence Protocol (XMPP)", 180 draft-ietf-xmpp-e2e-07 (work in progress), December 2003. 182 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 183 Protocol (XMPP): Instant Messaging and Presence", 184 draft-ietf-xmpp-im-21 (work in progress), January 2004. 186 Informative References 188 [GEOLOC] Peterson, J., "A Presence-based GEOPRIV Location Object 189 Format", draft-ietf-geopriv-pidf-lo-00 (work in progress), 190 January 2004. 192 [RPID] Schulzrinne, H., "RPID -- Rich Presence Information Data 193 Format", draft-ietf-simple-rpid-00 (work in progress), July 194 2003. 196 Author's Address 198 Peter Saint-Andre 199 Jabber Software Foundation 201 EMail: stpeter@jabber.org 203 Intellectual Property Statement 205 The IETF takes no position regarding the validity or scope of any 206 intellectual property or other rights that might be claimed to 207 pertain to the implementation or use of the technology described in 208 this document or the extent to which any license under such rights 209 might or might not be available; neither does it represent that it 210 has made any effort to identify any such rights. Information on the 211 IETF's procedures with respect to rights in standards-track and 212 standards-related documentation can be found in BCP-11. Copies of 213 claims of rights made available for publication and any assurances of 214 licenses to be made available, or the result of an attempt made to 215 obtain a general license or permission for the use of such 216 proprietary rights by implementors or users of this specification can 217 be obtained from the IETF Secretariat. 219 The IETF invites any interested party to bring to its attention any 220 copyrights, patents or patent applications, or other proprietary 221 rights which may cover technology that may be required to practice 222 this standard. Please address the information to the IETF Executive 223 Director. 225 Full Copyright Statement 227 Copyright (C) The Internet Society (2004). All Rights Reserved. 229 This document and translations of it may be copied and furnished to 230 others, and derivative works that comment on or otherwise explain it 231 or assist in its implementation may be prepared, copied, published 232 and distributed, in whole or in part, without restriction of any 233 kind, provided that the above copyright notice and this paragraph are 234 included on all such copies and derivative works. However, this 235 document itself may not be modified in any way, such as by removing 236 the copyright notice or references to the Internet Society or other 237 Internet organizations, except as needed for the purpose of 238 developing Internet standards in which case the procedures for 239 copyrights defined in the Internet Standards process must be 240 followed, or as required to translate it into languages other than 241 English. 243 The limited permissions granted above are perpetual and will not be 244 revoked by the Internet Society or its successors or assignees. 246 This document and the information contained herein is provided on an 247 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 248 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 249 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 250 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 251 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 253 Acknowledgment 255 Funding for the RFC Editor function is currently provided by the 256 Internet Society.