ENUM WG R. Mahy
Internet-Draft Plantronics
Intended status: Standards Track March 4, 2007
Expires: September 5, 2007
A Telephone Number Mapping (ENUM) Service Registration for Internet
Calendaring Services
draft-ietf-enum-calendar-service-02.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 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 5, 2007 [Page 1]
Internet-Draft IM Enumservice March 2007
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 '+12025332600', 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 Guide to Internet Calendaring [9] 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 proposing calendar events.
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
[10] and RFC 2818 [11]) 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:
"ical"
Enumservice Type:
"ical"
Enumservice Subtypes:
Mahy Expires September 5, 2007 [Page 2]
Internet-Draft IM Enumservice March 2007
N/A
URI scheme(s):
"mailto:", "http:", "https:"
Functional Specification:
This Enumservice indicates that the resource identified is a URI
used for Internet Calendaring. Supported URI schemes are the
'mailto:' URI for the iMIP [6] protocol, and 'http:' or 'https:'
URIs for the CalDAV [7] protocol.
Security considerations:
See section 3.
Intended usage:
COMMON
Author:
Rohan Mahy (rohan@ekabal.com)
3. 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.
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 [12]
(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
reveal an unprotected calendaring resource is unlikely in practice.
Mahy Expires September 5, 2007 [Page 3]
Internet-Draft IM Enumservice March 2007
4. IANA Considerations
This document requests registration of the "iCal" Enumservice
according to the definitions in this document and RFC 3761 [1].
5. References
5.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] Dusseault, L., "Calendaring Extensions to WebDAV (CalDAV)",
draft-dusseault-caldav-15 (work in progress), September 2006.
[8] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV",
RFC 2518, February 1999.
5.2. Informational References
[9] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet
Calendaring", RFC 3283, June 2002.
[10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
Mahy Expires September 5, 2007 [Page 4]
Internet-Draft IM Enumservice March 2007
HTTP/1.1", RFC 2616, June 1999.
[11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
Appendix A. Acknowlegments
Thanks to Lisa Dusseault for reviewing this document.
Author's Address
Rohan Mahy
Plantronics
Email: rohan@ekabal.com
Mahy Expires September 5, 2007 [Page 5]
Internet-Draft IM Enumservice March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 5, 2007 [Page 6]