idnits 2.17.1 draft-mahy-enum-calendar-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 222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 212. ** 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 6630 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) == Outdated reference: A later version (-15) exists of draft-dusseault-caldav-09 ** Obsolete normative reference: RFC 2518 (ref. '8') (Obsoleted by RFC 4918) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '10') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '11') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '12') (Obsoleted by RFC 4346) Summary: 9 errors (**), 0 flaws (~~), 3 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 Expires: August 24, 2006 Feb 20, 2006 6 A Telephone Number Mapping (ENUM) Service Registration for Internet 7 Calendaring Services 8 draft-mahy-enum-calendar-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 Internet Calendaring Services. Specifically, this document focuses 43 on provisioning mailto: (iMIP) and http: (CalDAV) 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 3986 [3]), such as mailto: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 The Guide to Internet Calendaring [9] describes the relationship 55 between various internet calendaring specifications like this: 56 "iCalendar [4] is the language used to describe calendar objects. 57 iTIP [5] [Transport-Independent Interoperability Protocol] describes 58 a way to use the iCalendar language to do scheduling. iMIP [6] 59 [Message-Based Interoperability Protocol] describes how to do iTIP 60 scheduling via e-mail." 62 Recently another standard track protocol for calendar and scheduling 63 access has appeared. CalDAV [7] (Calendaring Extensions to WebDAV) 64 is a WebDAV [8] (Web-based Distributed Authoring and Versioning) 65 based mechanism for manipulating internet calendars, viewing free/ 66 busy lists, and proposing calendar events. 68 The existing 'mailto' URI scheme (defined in RFC 3986 [3]) is already 69 used to address iMIP compatible Calendar Services. Likewise the 70 existing 'http' and 'https' URI schemes (defined in RFC 2616 [10] and 71 RFC 2818 [11]) are already used to address CalDAV compatible Calendar 72 Services. 74 This document registers an enumservice for advertising internet 75 calendaring information associated with an E.164 number, using the 76 'mailto', 'http', or 'https' schemes. 78 2. ENUM Service Registration 80 As defined in RFC 3761 [1], the following is a template covering 81 information needed for the registration of the enumservice specified 82 in this document: 83 Service name: "E2U+ical" 84 URI scheme(s): "mailto:", "http:", "https:" 85 Functional Specification: This Enumservice indicates that the 86 resource identified is a URI used for Internet Calendaring. 87 Supported URI schemes are the 'mailto' URI for the iMIP [6] 88 protocol, and 'http' or 'https' URIs for the CalDAV [7] protocol. 89 Security considerations: See section 3. 90 Intended usage: COMMON 91 Author: Rohan Mahy (rohan@ekabal.com) 93 3. Security Considerations 95 The Domain Name System (DNS) does not make policy decisions about 96 which records it provides to a DNS resolver. All DNS records must be 97 assumed to be available to all inquirers at all times. The 98 information provided within an ENUM record set must therefore be 99 considered open to the public -- which is a cause for some privacy 100 considerations. 102 Revealing a calendaring URI by itself is unlikely to introduce many 103 privacy concerns, although, depending on the structure of the URI, it 104 might reveal the full name or employer of the target. The use of 105 anonymous URIs mitigates this risk. 107 More serious security concerns are associated with potential attacks 108 against an underlying calendaring system (for example, unauthorized 109 modification or viewing). For this reason, iTIP discusses a number 110 of security requirements (detailed in RFC 2446 [5]) that call for 111 authentication, integrity and confidentiality properties, and similar 112 measures to prevent such attacks. Any calendaring protocol used in 113 conjunction with a URI scheme currently meets these requirements. 114 The use of CalDAV with the 'https' scheme makes use of TLS [12] 115 (Transport Layer Security) to provide server authentication, 116 confidentiality, and message integrity. 118 Unlike a traditional telephone number, the resource identified by an 119 calendaring URI is often already guessable and often requires that 120 users provide cryptographic credentials for authentication and 121 authorization before calendar data can be exchanged. Despite the 122 public availability of ENUM records, the use of this information to 123 reveal an unprotected calendaring resource is unlikely in practice. 125 4. IANA Considerations 127 This document requests registration of the "iCal" Enumservice 128 according to the definitions in this document and RFC 3761 [1]. 130 5. References 132 5.1 Normative References 134 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 135 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 136 Application (ENUM)", RFC 3761, April 2004. 138 [2] Mockapetris, P., "Domain names - concepts and facilities", 139 STD 13, RFC 1034, November 1987. 141 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 142 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 143 January 2005. 145 [4] Dawson, F. and Stenerson, D., "Internet Calendaring and 146 Scheduling Core Object Specification (iCalendar)", RFC 2445, 147 November 1998. 149 [5] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, 150 "iCalendar Transport-Independent Interoperability Protocol 151 (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", 152 RFC 2446, November 1998. 154 [6] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message- 155 Based Interoperability Protocol (iMIP)", RFC 2447, 156 November 1998. 158 [7] Dusseault, L., "Calendaring Extensions to WebDAV (CalDAV)", 159 draft-dusseault-caldav-09 (work in progress), December 2005. 161 [8] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, 162 "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, 163 February 1999. 165 5.2 Informational References 167 [9] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet 168 Calendaring", RFC 3283, June 2002. 170 [10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 171 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 172 HTTP/1.1", RFC 2616, June 1999. 174 [11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 176 [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 177 RFC 2246, January 1999. 179 Author's Address 181 Rohan Mahy 182 Plantronics 184 Email: rohan@ekabal.com 186 Appendix A. Acknowlegments 188 Thanks to Lisa Dusseault for reviewing this document. 190 Intellectual Property Statement 192 The IETF takes no position regarding the validity or scope of any 193 Intellectual Property Rights or other rights that might be claimed to 194 pertain to the implementation or use of the technology described in 195 this document or the extent to which any license under such rights 196 might or might not be available; nor does it represent that it has 197 made any independent effort to identify any such rights. Information 198 on the procedures with respect to rights in RFC documents can be 199 found in BCP 78 and BCP 79. 201 Copies of IPR disclosures made to the IETF Secretariat and any 202 assurances of licenses to be made available, or the result of an 203 attempt made to obtain a general license or permission for the use of 204 such proprietary rights by implementers or users of this 205 specification can be obtained from the IETF on-line IPR repository at 206 http://www.ietf.org/ipr. 208 The IETF invites any interested party to bring to its attention any 209 copyrights, patents or patent applications, or other proprietary 210 rights that may cover technology that may be required to implement 211 this standard. Please address the information to the IETF at 212 ietf-ipr@ietf.org. 214 Disclaimer of Validity 216 This document and the information contained herein are provided on an 217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 219 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 220 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 221 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 224 Copyright Statement 226 Copyright (C) The Internet Society (2006). This document is subject 227 to the rights, licenses and restrictions contained in BCP 78, and 228 except as set forth therein, the authors retain all their rights. 230 Acknowledgment 232 Funding for the RFC Editor function is currently provided by the 233 Internet Society.