idnits 2.17.1 draft-saintandre-header-im-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 250. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (November 7, 2007) is 6012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2822 (ref. 'MESSAGE') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIMSIG') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 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 XMPP Standards Foundation 4 Intended status: Informational November 7, 2007 5 Expires: May 10, 2008 7 The IM-ID Header Field 8 draft-saintandre-header-im-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 10, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines a header field that enables the author of an 42 email or netnews message to include an Instant Messaging (IM) URI in 43 the message header block for the purpose of associating the author 44 with an instant messaging address. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.4. Disposition . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . . . 7 63 1. Introduction 65 Several technologies enable entities to exchange messages in close to 66 real time, also known as "instant messaging" or IM [IMP-REQS]. Such 67 technologies include the Extensible Messaging and Presence Protocol 68 [XMPP-IM] and the Session Initiation Protocol [SIP-IM]. To 69 facilitate the exchange of instant messages, a URI scheme for IM is 70 defined in [CPIM]. 72 Because almost all human users of instant messaging systems also use 73 email systems and because many such users also use netnews systems, 74 it can be helpful for such users to specify their IM URIs in the 75 messages they author. The IM-ID header field provides a standard 76 location for such information. This document documents the syntax 77 and implementation of the IM-ID header field, including the 78 information necessary to register it in the Permanent Message Header 79 Field Registry maintained by the IANA. 81 2. Syntax 83 The syntax of the IM-ID header field is defined below using Augmented 84 Backus-Naur Form (as specified by [ABNF]), where the "IM-URI" rule is 85 defined in [CPIM] and the remaining rules are defined in [MESSAGE]: 87 "IM-ID:" SP *WSP pathxmpp *WSP CRLF 89 3. Implementation 91 3.1. Inclusion 93 The IM-ID header field is associated with the author of the message; 94 see [MESSAGE]. If the "From:" header field contains more than one 95 mailbox, the IM-ID header field should not be added to the message. 96 There should be no more than one instance of the IM-ID header field. 98 3.2. Generation 100 For a user whose instant messaging URI is "im:juliet@example.com", 101 the corresponding IM-ID header field would be: 103 IM-ID: im:juliet@example.com 105 3.3. Processing 107 Upon receiving a message containing an IM-ID header field, a user 108 agent that supports the field should process the field by resolving 109 the instant messaging URI in accordance with the procedures specified 110 in [CPIM]. 112 3.4. Disposition 114 A user agent that has processed an IM-ID header field may provide 115 appropriate interface elements if it has independent information 116 linking the author of the message with the specified instant 117 messaging URI (e.g., via a user-controlled address book or automated 118 directory lookup). Such interface elements might include an element 119 that enables the user to initiate a text chat with the author. 121 4. IANA Considerations 123 In accordance with [REG], the IANA registers the "IM-ID" header field 124 in the Permanent Message Header Field Registry. The registration 125 template is as follows: 127 Header field name: IM-ID 128 Applicable protocol: mail, netnews 129 Status: permanent 130 Author/Change controller: Peter Saint-Andre 131 132 Specification document(s): draft-saintandre-header-im-00 [Note to 133 IANA and RFC Editor: Replace I-D name with RFC XXXX, where "XXXX" 134 is the number of the RFC that results from this specification, if 135 any] 136 Related information: For detail information regarding instant 137 messaging URIs, refer to RFC 3860. 139 5. Security Considerations 141 Message headers are an existing standard and are designed to easily 142 accommodate new types. Although the IM-ID header field may be 143 forged, this problem is inherent in Internet email; however, because 144 a forged IM-ID header field may break automated processing, 145 applications should not depend on the IM-ID header field to indicate 146 the authenticity of an email message or the identity of its author or 147 sender. Including the IM-ID header field among the signer header 148 fields in DomainKeys Identified Mail (DKIM) can help to mitigate 149 against forging of the header (see [DKIMSIG]). 151 Advertising instant messaging URIs in message headers may make it 152 easier for malicious users to harvest such URIs and therefore to send 153 unsolicited bulk communications to the users or applications 154 represented by those URIs. Care should be taken in balancing the 155 benefits of open information exchange against the potential costs of 156 unwanted communication. An user agent that is capable of including 157 the IM-ID header field in outgoing messages should provide an option 158 for its user to disable inclusion of the IM-ID header field 159 generally, on a per-recipient basis, and on a per-message basis. 161 The security considerations discussed in [URI] and [CPIM] may also 162 apply to the IM-ID message header. 164 6. References 166 6.1. Normative References 168 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 169 Specifications: ABNF", RFC 4234, October 2005. 171 [CPIM] Peterson, J., "Common Profile for Instant Messaging 172 (CPIM)", RFC 3860, August 2004. 174 [MESSAGE] Resnick, P., "Internet Message Format", RFC 2822, 175 April 2001. 177 6.2. Informative References 179 [DKIMSIG] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 180 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 181 Signatures", RFC 4871, May 2007. 183 [IMP-REQS] 184 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 185 / Presence Protocol Requirements", RFC 2779, 186 February 2000. 188 [REG] Klyne, G., Nottingham, M., and J. Mogul, "Registration 189 Procedures for Message Header Fields", BCP 90, RFC 3864, 190 September 2004. 192 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 193 and D. Gurle, "Session Initiation Protocol (SIP) Extension 194 for Instant Messaging", RFC 3428, December 2002. 196 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 197 Resource Identifier (URI): Generic Syntax", STD 66, 198 RFC 3986, January 2005. 200 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 201 Protocol (XMPP): Instant Messaging and Presence", 202 RFC 3921, October 2004. 204 Author's Address 206 Peter Saint-Andre 207 XMPP Standards Foundation 209 Email: stpeter@jabber.org 210 URI: https://stpeter.im/ 212 Full Copyright Statement 214 Copyright (C) The IETF Trust (2007). 216 This document is subject to the rights, licenses and restrictions 217 contained in BCP 78, and except as set forth therein, the authors 218 retain all their rights. 220 This document and the information contained herein are provided on an 221 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 222 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 223 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 224 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 225 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 226 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 228 Intellectual Property 230 The IETF takes no position regarding the validity or scope of any 231 Intellectual Property Rights or other rights that might be claimed to 232 pertain to the implementation or use of the technology described in 233 this document or the extent to which any license under such rights 234 might or might not be available; nor does it represent that it has 235 made any independent effort to identify any such rights. Information 236 on the procedures with respect to rights in RFC documents can be 237 found in BCP 78 and BCP 79. 239 Copies of IPR disclosures made to the IETF Secretariat and any 240 assurances of licenses to be made available, or the result of an 241 attempt made to obtain a general license or permission for the use of 242 such proprietary rights by implementers or users of this 243 specification can be obtained from the IETF on-line IPR repository at 244 http://www.ietf.org/ipr. 246 The IETF invites any interested party to bring to its attention any 247 copyrights, patents or patent applications, or other proprietary 248 rights that may cover technology that may be required to implement 249 this standard. Please address the information to the IETF at 250 ietf-ipr@ietf.org. 252 Acknowledgment 254 Funding for the RFC Editor function is provided by the IETF 255 Administrative Support Activity (IASA).