idnits 2.17.1 draft-ietf-enum-pres-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 3979, Section 5, paragraph 1 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 227. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 290), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 290. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...res' enumservice SHOULD be the 'pres' ...' RFC 2119 keyword, line 146: '...ppropriate to presence services MAY be...' 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 (May 20, 2004) is 7274 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) == Unused Reference: '10' is defined on line 264, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 268, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '9') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2806 (ref. '11') (Obsoleted by RFC 3966) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: November 18, 2004 May 20, 2004 6 Enumservice Registration for Presence Services 7 draft-ietf-enum-pres-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 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 November 18, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document registers an ENUM service for presence. Specifically, 39 this document focuses on provisioning pres URIs in ENUM. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. ENUM Service Registration . . . . . . . . . . . . . . . . . . . 3 45 3. Presence for E.164 numbers . . . . . . . . . . . . . . . . . . . 3 46 4. The 'E2U+pres' enumservice . . . . . . . . . . . . . . . . . . . 4 47 5. Example of E2U+pres enumservice . . . . . . . . . . . . . . . . 5 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 50 8. IPR Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 51 Normative References . . . . . . . . . . . . . . . . . . . . . . 6 52 Informative References . . . . . . . . . . . . . . . . . . . . . 7 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 54 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 56 1. Introduction 58 ENUM (E.164 Number Mapping, RFC3761 [1]) is a system that uses DNS 59 (Domain Name Service, RFC1034 [8]) to translate telephone numbers, 60 like '+12025332600', into URIs (Uniform Resource Identifiers, RFC2396 61 [9]), like 'pres:user@host.com'. ENUM exists primarily to facilitate 62 the interconnection of systems that rely on telephone numbers with 63 those that use URIs to identify resources. 65 Presence is a service defined in RFC2778 [2] that allows users of a 66 communications service to monitor one another's availability and 67 disposition in order to make decisions about communicating. Presence 68 information is highly dynamic, and generally characterizes whether a 69 not a user is online or offline, busy or idle, away from 70 communications devices or nearby, and the like. 72 The IETF has defined a generic URI used to identify a presence 73 service for a particular resource: the 'pres' URI scheme (defined in 74 CPP [4]). This document describes an enumservice for advertising 75 presence information associated with an E.164 number. 77 2. ENUM Service Registration 79 As defined in [1], the following is a template covering information 80 needed for the registration of the enumservice specified in this 81 document. 83 Service Name: "E2U+pres" 85 URI Scheme(s): "pres:" 87 Functional Specification: see Section 4 89 Security considerations: see Section 6 91 Intended usage: COMMON 93 Author: Jon Peterson (jon.peterson@neustar.biz) 95 Any other information that the author deems interesting: See 96 Section 3 98 3. Presence for E.164 numbers 100 This document specifies an enumservice field that allows presence 101 information to be provided for an E.164 number. This may include 102 presence states associated with telephones, or presence of non- 103 telephony communications services advertised by ENUM. 105 Endpoints that participate in a presence architecture are known 106 (following the framework in RFC2778 [2]) as watchers and 107 presentities. Watchers subscribe to the presence of presentities, 108 and are notified when the presence of a presentity changes. Watchers 109 generally monitor the presence of a group of presentities with whom 110 they have an ongoing association. As an example, consider a way that 111 this might apply a telephony service. Most cellular telephones today 112 have an address-book like feature, a small database of names and 113 telephone numbers. Such a telephone might act as a watcher, 114 subscribing to the presence of some or all of the telephone numbers 115 in its address book. The display of the telephone might then show 116 its user, when a presence-enabled telephone number is selected, the 117 availability of the destination. With this information, user might 118 change their calling habits to correspond better to the availability 119 of their associates. 121 The presence information that is shared varies by communications 122 service. The IETF has defined a Presence Information Data Format (or 123 PIDF [6]) for describing the presence data associated with a 124 presentity. The baseline PIDF specification declares only two 125 presence states: OPEN and CLOSED (these terms are defined in RFC2778 126 [2]); the former suggests that the destination resource is able to 127 accept communication requests, the latter that it is not. These two 128 states provide useful but rudimentary insight into the communications 129 status of a presentity; for that reason, PIDF is an extensible 130 format, and new sorts of status can be defined for specific 131 communications services. For example, a telephony-based presence 132 service might define a status corresponding to 'busy'. Extending 133 PIDF for telephony services is however outside the scope of this 134 document. 136 4. The 'E2U+pres' enumservice 138 Traditionally, the services field of a NAPTR record (as defined in 139 [12]) contains a string that is composed of two subfields: a 140 'protocol' subfield and a 'resolution service' subfield. ENUM in 141 particular defines an 'E2U' (E.164 to URI) resolution service. This 142 document defines an 'E2U+pres' enumservice for presence. 144 The scheme of the URI that will appear in the regexp field of a NAPTR 145 record using the 'E2U+pres' enumservice SHOULD be the 'pres' URI 146 scheme. Other URI schemes appropriate to presence services MAY be 147 used; however, the use of the 'pres' URI scheme ensures a greater 148 level of compatibility than the use of any URI specific to a 149 particular presence protocol. The purpose of a pres URI is to 150 provide a generic way of locating a presence service. Techniques for 151 dereferencing the pres URI scheme to locate a presence service are 152 given in [5]. 154 The 'pres' URI scheme does not identify any particular protocol that 155 will be used to handle presence operations (such as subscriptions and 156 notifications). Rather, the mechanism in [5] details a way to 157 discover whether or not the presence protocol(s) supported by the 158 watcher is/are also supported by the presentity. SIP [7] is one 159 protocol that can be used to convey presence information and manage 160 subscriptions/notifications. 162 5. Example of E2U+pres enumservice 164 The following is an example of the use of the enumservice registered 165 by this document in a NAPTR resource record. 167 $ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. 168 IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!pres:jon.peterson@neustar.biz!" . 170 6. Security Considerations 172 DNS does not make policy decisions about the records that it shares 173 with an inquirer. All DNS records must be assumed to be available to 174 all inquirers at all times. The information provided within an ENUM 175 record set must therefore be considered to be open to the public - 176 which is a cause for some privacy considerations. 178 However, revealing a pres URI in and of itself is unlikely to 179 introduce many privacy concerns, although depending on the structure 180 of the URI, it might reveal the full name or employer of the target. 181 The use of anonymous URIs mitigates that risk. There are more 182 serious privacy concerns associated with the unauthorized 183 distribution of presence information. For that reason, presence 184 protocols have a number of security requirements (detailed in RFC2779 185 [3]) that call for authentication of watchers, integrity and 186 confidentiality properties, and similar measures to prevent abuse of 187 presence information. Any presence protocol that is used in 188 conjunction with the 'pres' URI scheme is required to meet these 189 requirements. 191 Unlike a traditional telephone number, the resource identified by a 192 pres URI may require that callers provide cryptographic credentials 193 for authentication and authorization before presence information is 194 returned. In this respect, ENUM in concert with presence protocols 195 can actually provide far greater protection from unwanted callers 196 than the existing PSTN, despite the public availability of ENUM 197 records. 199 7. IANA Considerations 201 This document registers the 'E2U+pres' enumservice under the 202 enumservice registry described in the IANA considerations in RFC3761. 203 Details of the registration are given in Section 2. 205 8. IPR Considerations 207 The IETF takes no position regarding the validity or scope of any 208 Intellectual Property Rights or other rights that might be claimed to 209 pertain to the implementation or use of the technology described in 210 this document or the extent to which any license under such rights 211 might or might not be available; nor does it represent that it has 212 made any independent effort to identify any such rights. Information 213 on the procedures with respect to rights in RFC documents can be 214 found in BCP 78 and BCP 79. 216 Copies of IPR disclosures made to the IETF Secretariat and any 217 assurances of licenses to be made available, or the result of an 218 attempt made to obtain a general license or permission for the use of 219 such proprietary rights by implementers or users of this 220 specification can be obtained from the IETF on-line IPR repository at 221 http://www.ietf.org/ipr. 223 The IETF invites any interested party to bring to its attention any 224 copyrights, patents or patent applications, or other proprietary 225 rights that may cover technology that may be required to implement 226 this standard. Please address the information to the IETF at ietf- 227 ipr@ietf.org. 229 Normative References 231 [1] Faltstrom, P. and M. Mealling, "The E.164 to URI DDDS 232 Application", RFC 3761, April 2004. 234 [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 235 Instant Messaging", RFC 2778, February 2000. 237 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 238 Presence Protocol Requirements", RFC 2779, February 2000. 240 [4] Peterson, J., "A Model for Presence and Instant Messaging", 241 draft-ietf-impp-pres-04 (work in progress), September 2003. 243 [5] Peterson, J., "Address Resolution for Instant Messaging and 244 Presence", draft-ietf-impp-srv-04 (work in progress), September 245 2003. 247 Informative References 249 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 250 J. Peterson, "CPIM Presence Information Data Format", draft- 251 ietf-impp-cpim-pidf-08 (work in progress), May 2003. 253 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 254 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 255 Session Initiation Protocol", RFC 3261, May 2002. 257 [8] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 258 1034, November 1987. 260 [9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 261 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 262 1998. 264 [10] International Telecommunications Union, "Recommendation E.164: 265 The international public telecommunication numbering plan", May 266 1997, . 268 [11] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 269 2000. 271 [12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 272 Three: The Domain Name System (DNS) Database", RFC 3403, 273 October 2002. 275 Author's Address 277 Jon Peterson 278 NeuStar, Inc. 279 1800 Sutter St 280 Suite 570 281 Concord, CA 94520 282 USA 284 Phone: +1 925/363-8720 285 EMail: jon.peterson@neustar.biz 286 URI: http://www.neustar.biz/ 288 Full Copyright Statement 290 Copyright (C) The Internet Society (2004). All Rights Reserved. 292 This document and translations of it may be copied and furnished to 293 others, and derivative works that comment on or otherwise explain it 294 or assist in its implementation may be prepared, copied, published 295 and distributed, in whole or in part, without restriction of any 296 kind, provided that the above copyright notice and this paragraph are 297 included on all such copies and derivative works. However, this 298 document itself may not be modified in any way, such as by removing 299 the copyright notice or references to the Internet Society or other 300 Internet organizations, except as needed for the purpose of 301 developing Internet standards in which case the procedures for 302 copyrights defined in the Internet Standards process must be 303 followed, or as required to translate it into languages other than 304 English. 306 The limited permissions granted above are perpetual and will not be 307 revoked by the Internet Society or its successors or assigns. 309 This document and the information contained herein is provided on an 310 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 311 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 312 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 313 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 314 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 Acknowledgement 318 Funding for the RFC Editor function is currently provided by the 319 Internet Society.