IANA Registration of Enumservices for Internet Calendaring
draft-ietf-enum-calendar-service-04

ENUM WG                                                          R. Mahy
Internet-Draft                                               Plantronics
Intended status: Standards Track                          March 10, 2008
Expires: September 11, 2008

  A Telephone Number Mapping (ENUM) Service Registration for Internet
                          Calendaring Services
                draft-ietf-enum-calendar-service-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 11, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document registers a Telephone Number Mapping (ENUM) service for
   Internet Calendaring Services.  Specifically, this document focuses
   on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.

Mahy                   Expires September 11, 2008               [Page 1]
Internet-Draft               IM Enumservice                   March 2008

1.  Introduction

   ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS
   (Domain Name Service, RFC 1034 [2]) to translate telephone numbers,
   such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC
   3986 [3]), such as 'mailto:user@example.com'.  ENUM exists primarily
   to facilitate the interconnection of systems that rely on telephone
   numbers with those that use URIs to identify resources.  The ENUM
   registration here could be used to allow phones for example to check
   the free/busy status of a user in their address book or propose a
   meeting with him or her from the user's phone number.

   The Guide to Internet Calendaring [10] describes the relationship
   between various internet calendaring specifications like this:
   "iCalendar [4] is the language used to describe calendar objects.
   iTIP [5] [Transport-Independent Interoperability Protocol] describes
   a way to use the iCalendar language to do scheduling. iMIP [6]
   [Message-Based Interoperability Protocol] describes how to do iTIP
   scheduling via e-mail."

   Recently another standard track protocol for calendar and scheduling
   access has appeared.  CalDAV [7] (Calendaring Extensions to WebDAV)
   is a WebDAV [8] (Web-based Distributed Authoring and Versioning)
   based mechanism for manipulating internet calendars, viewing free/
   busy lists, and via a planned scheduling extension [15], could be
   used for proposing calendar events as well.

   The existing 'mailto:' URI scheme (defined in RFC 3986 [3]) is
   already used to address iMIP compatible Calendar Services.  Likewise
   the existing 'http:' and 'https:' URI schemes (defined in RFC 2616
   [11] and RFC 2818 [12]) are already used to address CalDAV compatible
   Calendar Services.

   This document registers an enumservice for advertising internet
   calendaring information associated with an E.164 number, using the
   'mailto:', 'http:', or 'https:' schemes.

2.  ENUM Service Registration - ical

   As defined in RFC 3761 [1], the following is a template covering
   information needed for the registration of the enumservice specified
   in this document:
   Enumservice Name:

Mahy                   Expires September 11, 2008               [Page 2]
Internet-Draft               IM Enumservice                   March 2008

      "ical"
   Enumservice Type:
      "ical"
   Enumservice Subtypes:
      sched
   URI scheme(s):
      "mailto:", "http:", "https:"
   Functional Specification:
      This Enumservice indicates that the resource identified is a URI
      used for scheduling using Internet Calendaring.  Supported URI
      schemes are the 'mailto:' URI for the iMIP [6] protocol, and
      'http:' or 'https:' URIs for a planned scheduling extension [15]
      to the CalDAV [7] protocol.
   Security considerations:
      See section 3.
   Intended usage:
      COMMON
   Author:
      Rohan Mahy (rohan@ekabal.com)
   Enumservice Name:
      "ical"
   Enumservice Type:
      "ical"
   Enumservice Subtypes:
      access
   URI scheme(s):
      "http:", "https:"
   Functional Specification:
      This Enumservice indicates that the resource identified is a URI
      used for Internet Calendaring which is available to access a
      user's calendar (for example free/busy status).  Supported URI
      schemes are 'http:' or 'https:' URIs for the CalDAV [7] protocol.
   Security considerations:
      See section 3.
   Intended usage:
      COMMON
   Author:
      Rohan Mahy (rohan@ekabal.com)

3.  Example of Usage

   Below is a set of sample resource records for this enumservice.

Mahy                   Expires September 11, 2008               [Page 3]
Internet-Draft               IM Enumservice                   March 2008

   $ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
   @ NAPTR 10 100 "u" "E2U+ical:access"
     "!^.*$!http://cal.example.com/home/alice/calendars/!" .

   $ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
   @ NAPTR 10 100 "u" "E2U+ical:sched"
     "!^.*$!mailto:alice@example.com!" .

4.  Security Considerations

   The Domain Name System (DNS) does not make policy decisions about
   which records it provides to a DNS resolver.  All DNS records must be
   assumed to be available to all inquirers at all times.  The
   information provided within an ENUM record set must therefore be
   considered open to the public -- which is a cause for some privacy
   considerations.

   Revealing a calendaring URI by itself is unlikely to introduce many
   privacy concerns, although, depending on the structure of the URI, it
   might reveal the full name or employer of the target.  The use of
   anonymous URIs mitigates this risk.

   As ENUM uses DNS, which in its current form is an insecure protocol,
   there is no mechanism for ensuring that the answer returned to a
   query is authentic.  An analysis of threats specific to the
   dependence of ENUM on the DNS is provided in RFC 3761 and a thorough
   analysis of threats to the DNS itself is covered in RFC 3833 [14].
   Many of these problems are prevented when the resolver verifies the
   authenticity of answers to its ENUM queries via DNSSEC [9] in zones
   where it is available.

   More serious security concerns are associated with potential attacks
   against an underlying calendaring system (for example, unauthorized
   modification or viewing).  For this reason, iTIP discusses a number
   of security requirements (detailed in RFC 2446 [5]) that call for
   authentication, integrity and confidentiality properties, and similar
   measures to prevent such attacks.  Any calendaring protocol used in
   conjunction with a URI scheme currently meets these requirements.
   The use of CalDAV with the 'https:' scheme makes use of TLS [13]
   (Transport Layer Security) to provide server authentication,
   confidentiality, and message integrity.

   Unlike a traditional telephone number, the resource identified by an
   calendaring URI is often already guessable and often requires that
   users provide cryptographic credentials for authentication and
   authorization before calendar data can be exchanged.  Despite the
   public availability of ENUM records, the use of this information to

Mahy                   Expires September 11, 2008               [Page 4]
Internet-Draft               IM Enumservice                   March 2008

   reveal an unprotected calendaring resource is unlikely in practice.

5.  IANA Considerations

   This document requests registration of the "iCal" Enumservice
   according to the definitions in Section 2 of this document and RFC
   3761 [1].

6.  References

6.1.  Normative References

   [1]   Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
         Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
         Application (ENUM)", RFC 3761, April 2004.

   [2]   Mockapetris, P., "Domain names - concepts and facilities",
         STD 13, RFC 1034, November 1987.

   [3]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

   [4]   Dawson, F. and Stenerson, D., "Internet Calendaring and
         Scheduling Core Object Specification (iCalendar)", RFC 2445,
         November 1998.

   [5]   Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
         "iCalendar Transport-Independent Interoperability Protocol
         (iTIP) Scheduling Events, BusyTime, To-dos and Journal
         Entries", RFC 2446, November 1998.

   [6]   Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message-
         Based Interoperability Protocol (iMIP)", RFC 2447,
         November 1998.

   [7]   Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring
         Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.

   [8]   Dusseault, L., "HTTP Extensions for Web Distributed Authoring
         and Versioning (WebDAV)", RFC 4918, June 2007.

   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Protocol Modifications for the DNS Security Extensions",
         RFC 4035, March 2005.

Mahy                   Expires September 11, 2008               [Page 5]
Internet-Draft               IM Enumservice                   March 2008

6.2.  Informational References

   [10]  Mahoney, B., Babics, G., and A. Taler, "Guide to Internet
         Calendaring", RFC 3283, June 2002.

   [11]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [12]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [13]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

   [14]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
         System (DNS)", RFC 3833, August 2004.

   [15]  Daboo, C., Desruisseaux, B., and L. Dusseault, "CalDAV
         Scheduling Extensions to WebDAV",
         draft-desruisseaux-caldav-sched-04 (work in progress),
         November 2007.

Appendix A.  Acknowlegments

   Thanks to Lisa Dusseault and Alexander Mayrhofer for reviewing this
   document.

Author's Address

   Rohan Mahy
   Plantronics

   Email: rohan@ekabal.com

Mahy                   Expires September 11, 2008               [Page 6]
Internet-Draft               IM Enumservice                   March 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Mahy                   Expires September 11, 2008               [Page 7]