idnits 2.17.1 draft-mahy-enum-im-service-00.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 on line 199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 189. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 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 (Feb 20, 2006) is 6611 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) ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 2396 (ref. '3') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '8') (Obsoleted by RFC 6121) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM WG R. Mahy 3 Internet-Draft Plantronics 4 Expires: August 24, 2006 Feb 20, 2006 6 A Telephone Number Mapping (ENUM) Service Registration for Instant 7 Messaging (IM) Services 8 draft-mahy-enum-im-service-00.txt 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 August 24, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document registers a Telephone Number Mapping (ENUM) service for 42 Instant Messaging (IM). Specifically, this document focuses on 43 provisioning im: URIs in ENUM. 45 1. Discussion 47 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS 48 (Domain Name Service, RFC 1034 [2]) to translate telephone numbers, 49 such as +12025332600, into URIs (Uniform Resource Identifiers, RFC 50 2396 [3]), such as im:user@example.com. ENUM exists primarily to 51 facilitate the interconnection of systems that rely on telephone 52 numbers with those that use URIs to identify resources. 54 Instant Messaging (IM) is a service defined in RFC 2778 [5] that 55 allows users to send and receive typically short, often textual 56 messages in near real-time. The IETF has defined a generic URI used 57 to identify an IM service for a particular resource: the 'im' URI 58 scheme (defined in RFC 3861 [4]). RFC 3861 [4] also defines rules 59 for discovering service running specific protocols, such as SIP (the 60 Session Initiation Protocol, RFC 3261 [7]) and XMPP (the eXtensible 61 Messaging and Presence Protocol, RFC 3921 [8]) from a specific im: 62 URI. 64 RFC 3953 [9] already defines an enumservice for presence services 65 which returns pres: URIs (also defined in RFC 3861 [4]). This 66 document registers an enumservice for advertising IM information 67 associated with an E.164 number. 69 2. ENUM Service Registration 71 As defined in RFC 3761 [1], the following is a template covering 72 information needed for the registration of the enumservice specified 73 in this document: 74 Service name: "E2U+im" 75 URI scheme(s): "im:" 76 Functional Specification: This Enumservice indicates that the 77 resource identified is an 'im' URI. The 'im' URI scheme does not 78 identify any particular protocol that will be used to handle 79 instant messaging receipt or delivery, rather the mechanism in RFC 80 3861 [4] is used to discover whether an IM protocol supported by 81 the party querying ENUM is also supported by the target resource. 82 Security considerations: See section 3. 83 Intended usage: COMMON 84 Author: Rohan Mahy (rohan@ekabal.com) 86 3. Security Considerations 88 The Domain Name System (DNS) does not make policy decisions about 89 which records it provides to a DNS resolver. All DNS records must be 90 assumed to be available to all inquirers at all times. The 91 information provided within an ENUM record set must therefore be 92 considered open to the public -- which is a cause for some privacy 93 considerations. 95 Revealing an IM URI by itself is unlikely to introduce many privacy 96 concerns, although, depending on the structure of the URI, it might 97 reveal the full name or employer of the target. The use of anonymous 98 URIs mitigates this risk. 100 More serious security concerns are associated with potential attacks 101 against an underlying Instant Messaging system (for example, message 102 forgery and tampering). For this reason, IM protocols have a number 103 of security requirements (detailed in RFC 2779 [6]) that call for 104 authentication, integrity and confidentiality properties, and similar 105 measures to prevent such attacks. Any instant messaging protocol 106 used in conjunction with the 'im' URI scheme is required to meet 107 these requirements. 109 Unlike a traditional telephone number, the resource identified by an 110 im URI may require that callers provide cryptographic credentials for 111 authentication and authorization before instant messages are 112 exchanged. In concert with instant messaging protocols, ENUM can 113 actually provide far greater protection from unwanted callers than 114 does the existing PSTN, despite the public availability of ENUM 115 records. 117 4. IANA Considerations 119 This document requests registration of the "IM" Enumservice according 120 to the definitions in this document and RFC 3761 [1]. 122 5. References 124 5.1 Normative References 126 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 127 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 128 Application (ENUM)", RFC 3761, April 2004. 130 [2] Mockapetris, P., "Domain names - concepts and facilities", 131 STD 13, RFC 1034, November 1987. 133 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 134 Resource Identifiers (URI): Generic Syntax", RFC 2396, 135 August 1998. 137 [4] Peterson, J., "Address Resolution for Instant Messaging and 138 Presence", RFC 3861, August 2004. 140 5.2 Informational References 142 [5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and 143 Instant Messaging", RFC 2778, February 2000. 145 [6] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 146 Messaging / Presence Protocol Requirements", RFC 2779, 147 February 2000. 149 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 150 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 151 Session Initiation Protocol", RFC 3261, June 2002. 153 [8] Saint-Andre, P., Ed., "Extensible Messaging and Presence 154 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 155 October 2004. 157 [9] Peterson, J., "Telephone Number Mapping (ENUM) Service 158 Registration for Presence Services", RFC 3953, January 2005. 160 Author's Address 162 Rohan Mahy 163 Plantronics 165 Email: rohan@ekabal.com 167 Intellectual Property Statement 169 The IETF takes no position regarding the validity or scope of any 170 Intellectual Property Rights or other rights that might be claimed to 171 pertain to the implementation or use of the technology described in 172 this document or the extent to which any license under such rights 173 might or might not be available; nor does it represent that it has 174 made any independent effort to identify any such rights. Information 175 on the procedures with respect to rights in RFC documents can be 176 found in BCP 78 and BCP 79. 178 Copies of IPR disclosures made to the IETF Secretariat and any 179 assurances of licenses to be made available, or the result of an 180 attempt made to obtain a general license or permission for the use of 181 such proprietary rights by implementers or users of this 182 specification can be obtained from the IETF on-line IPR repository at 183 http://www.ietf.org/ipr. 185 The IETF invites any interested party to bring to its attention any 186 copyrights, patents or patent applications, or other proprietary 187 rights that may cover technology that may be required to implement 188 this standard. Please address the information to the IETF at 189 ietf-ipr@ietf.org. 191 Disclaimer of Validity 193 This document and the information contained herein are provided on an 194 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 195 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 196 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 197 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 198 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 199 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 201 Copyright Statement 203 Copyright (C) The Internet Society (2006). This document is subject 204 to the rights, licenses and restrictions contained in BCP 78, and 205 except as set forth therein, the authors retain all their rights. 207 Acknowledgment 209 Funding for the RFC Editor function is currently provided by the 210 Internet Society.