idnits 2.17.1 draft-ietf-enum-calendar-service-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 298. 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 (March 10, 2008) is 5862 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 2445 (ref. '4') (Obsoleted by RFC 5545) ** Obsolete normative reference: RFC 2446 (ref. '5') (Obsoleted by RFC 5546) ** Obsolete normative reference: RFC 2447 (ref. '6') (Obsoleted by RFC 6047) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '11') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '12') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '13') (Obsoleted by RFC 5246) == Outdated reference: A later version (-12) exists of draft-desruisseaux-caldav-sched-04 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 Intended status: Standards Track March 10, 2008 5 Expires: September 11, 2008 7 A Telephone Number Mapping (ENUM) Service Registration for Internet 8 Calendaring Services 9 draft-ietf-enum-calendar-service-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document registers a Telephone Number Mapping (ENUM) service for 43 Internet Calendaring Services. Specifically, this document focuses 44 on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. 46 1. Introduction 48 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS 49 (Domain Name Service, RFC 1034 [2]) to translate telephone numbers, 50 such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC 51 3986 [3]), such as 'mailto:user@example.com'. ENUM exists primarily 52 to facilitate the interconnection of systems that rely on telephone 53 numbers with those that use URIs to identify resources. The ENUM 54 registration here could be used to allow phones for example to check 55 the free/busy status of a user in their address book or propose a 56 meeting with him or her from the user's phone number. 58 The Guide to Internet Calendaring [10] describes the relationship 59 between various internet calendaring specifications like this: 60 "iCalendar [4] is the language used to describe calendar objects. 61 iTIP [5] [Transport-Independent Interoperability Protocol] describes 62 a way to use the iCalendar language to do scheduling. iMIP [6] 63 [Message-Based Interoperability Protocol] describes how to do iTIP 64 scheduling via e-mail." 66 Recently another standard track protocol for calendar and scheduling 67 access has appeared. CalDAV [7] (Calendaring Extensions to WebDAV) 68 is a WebDAV [8] (Web-based Distributed Authoring and Versioning) 69 based mechanism for manipulating internet calendars, viewing free/ 70 busy lists, and via a planned scheduling extension [15], could be 71 used for proposing calendar events as well. 73 The existing 'mailto:' URI scheme (defined in RFC 3986 [3]) is 74 already used to address iMIP compatible Calendar Services. Likewise 75 the existing 'http:' and 'https:' URI schemes (defined in RFC 2616 76 [11] and RFC 2818 [12]) are already used to address CalDAV compatible 77 Calendar Services. 79 This document registers an enumservice for advertising internet 80 calendaring information associated with an E.164 number, using the 81 'mailto:', 'http:', or 'https:' schemes. 83 2. ENUM Service Registration - ical 85 As defined in RFC 3761 [1], the following is a template covering 86 information needed for the registration of the enumservice specified 87 in this document: 88 Enumservice Name: 90 "ical" 91 Enumservice Type: 92 "ical" 93 Enumservice Subtypes: 94 sched 95 URI scheme(s): 96 "mailto:", "http:", "https:" 97 Functional Specification: 98 This Enumservice indicates that the resource identified is a URI 99 used for scheduling using Internet Calendaring. Supported URI 100 schemes are the 'mailto:' URI for the iMIP [6] protocol, and 101 'http:' or 'https:' URIs for a planned scheduling extension [15] 102 to the CalDAV [7] protocol. 103 Security considerations: 104 See section 3. 105 Intended usage: 106 COMMON 107 Author: 108 Rohan Mahy (rohan@ekabal.com) 109 Enumservice Name: 110 "ical" 111 Enumservice Type: 112 "ical" 113 Enumservice Subtypes: 114 access 115 URI scheme(s): 116 "http:", "https:" 117 Functional Specification: 118 This Enumservice indicates that the resource identified is a URI 119 used for Internet Calendaring which is available to access a 120 user's calendar (for example free/busy status). Supported URI 121 schemes are 'http:' or 'https:' URIs for the CalDAV [7] protocol. 122 Security considerations: 123 See section 3. 124 Intended usage: 125 COMMON 126 Author: 127 Rohan Mahy (rohan@ekabal.com) 129 3. Example of Usage 131 Below is a set of sample resource records for this enumservice. 133 $ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. 134 @ NAPTR 10 100 "u" "E2U+ical:access" 135 "!^.*$!http://cal.example.com/home/alice/calendars/!" . 137 $ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. 138 @ NAPTR 10 100 "u" "E2U+ical:sched" 139 "!^.*$!mailto:alice@example.com!" . 141 4. Security Considerations 143 The Domain Name System (DNS) does not make policy decisions about 144 which records it provides to a DNS resolver. All DNS records must be 145 assumed to be available to all inquirers at all times. The 146 information provided within an ENUM record set must therefore be 147 considered open to the public -- which is a cause for some privacy 148 considerations. 150 Revealing a calendaring URI by itself is unlikely to introduce many 151 privacy concerns, although, depending on the structure of the URI, it 152 might reveal the full name or employer of the target. The use of 153 anonymous URIs mitigates this risk. 155 As ENUM uses DNS, which in its current form is an insecure protocol, 156 there is no mechanism for ensuring that the answer returned to a 157 query is authentic. An analysis of threats specific to the 158 dependence of ENUM on the DNS is provided in RFC 3761 and a thorough 159 analysis of threats to the DNS itself is covered in RFC 3833 [14]. 160 Many of these problems are prevented when the resolver verifies the 161 authenticity of answers to its ENUM queries via DNSSEC [9] in zones 162 where it is available. 164 More serious security concerns are associated with potential attacks 165 against an underlying calendaring system (for example, unauthorized 166 modification or viewing). For this reason, iTIP discusses a number 167 of security requirements (detailed in RFC 2446 [5]) that call for 168 authentication, integrity and confidentiality properties, and similar 169 measures to prevent such attacks. Any calendaring protocol used in 170 conjunction with a URI scheme currently meets these requirements. 171 The use of CalDAV with the 'https:' scheme makes use of TLS [13] 172 (Transport Layer Security) to provide server authentication, 173 confidentiality, and message integrity. 175 Unlike a traditional telephone number, the resource identified by an 176 calendaring URI is often already guessable and often requires that 177 users provide cryptographic credentials for authentication and 178 authorization before calendar data can be exchanged. Despite the 179 public availability of ENUM records, the use of this information to 180 reveal an unprotected calendaring resource is unlikely in practice. 182 5. IANA Considerations 184 This document requests registration of the "iCal" Enumservice 185 according to the definitions in Section 2 of this document and RFC 186 3761 [1]. 188 6. References 190 6.1. Normative References 192 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 193 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 194 Application (ENUM)", RFC 3761, April 2004. 196 [2] Mockapetris, P., "Domain names - concepts and facilities", 197 STD 13, RFC 1034, November 1987. 199 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 200 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 201 January 2005. 203 [4] Dawson, F. and Stenerson, D., "Internet Calendaring and 204 Scheduling Core Object Specification (iCalendar)", RFC 2445, 205 November 1998. 207 [5] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, 208 "iCalendar Transport-Independent Interoperability Protocol 209 (iTIP) Scheduling Events, BusyTime, To-dos and Journal 210 Entries", RFC 2446, November 1998. 212 [6] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message- 213 Based Interoperability Protocol (iMIP)", RFC 2447, 214 November 1998. 216 [7] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring 217 Extensions to WebDAV (CalDAV)", RFC 4791, March 2007. 219 [8] Dusseault, L., "HTTP Extensions for Web Distributed Authoring 220 and Versioning (WebDAV)", RFC 4918, June 2007. 222 [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 223 "Protocol Modifications for the DNS Security Extensions", 224 RFC 4035, March 2005. 226 6.2. Informational References 228 [10] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet 229 Calendaring", RFC 3283, June 2002. 231 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 232 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 233 HTTP/1.1", RFC 2616, June 1999. 235 [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 237 [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 238 Protocol Version 1.1", RFC 4346, April 2006. 240 [14] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 241 System (DNS)", RFC 3833, August 2004. 243 [15] Daboo, C., Desruisseaux, B., and L. Dusseault, "CalDAV 244 Scheduling Extensions to WebDAV", 245 draft-desruisseaux-caldav-sched-04 (work in progress), 246 November 2007. 248 Appendix A. Acknowlegments 250 Thanks to Lisa Dusseault and Alexander Mayrhofer for reviewing this 251 document. 253 Author's Address 255 Rohan Mahy 256 Plantronics 258 Email: rohan@ekabal.com 260 Full Copyright Statement 262 Copyright (C) The IETF Trust (2008). 264 This document is subject to the rights, licenses and restrictions 265 contained in BCP 78, and except as set forth therein, the authors 266 retain all their rights. 268 This document and the information contained herein are provided on an 269 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 270 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 271 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 272 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 273 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 274 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Intellectual Property 278 The IETF takes no position regarding the validity or scope of any 279 Intellectual Property Rights or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; nor does it represent that it has 283 made any independent effort to identify any such rights. Information 284 on the procedures with respect to rights in RFC documents can be 285 found in BCP 78 and BCP 79. 287 Copies of IPR disclosures made to the IETF Secretariat and any 288 assurances of licenses to be made available, or the result of an 289 attempt made to obtain a general license or permission for the use of 290 such proprietary rights by implementers or users of this 291 specification can be obtained from the IETF on-line IPR repository at 292 http://www.ietf.org/ipr. 294 The IETF invites any interested party to bring to its attention any 295 copyrights, patents or patent applications, or other proprietary 296 rights that may cover technology that may be required to implement 297 this standard. Please address the information to the IETF at 298 ietf-ipr@ietf.org. 300 Acknowledgment 302 Funding for the RFC Editor function is provided by the IETF 303 Administrative Support Activity (IASA).