Enumservices Calendaring: IANA Registration of Enumservices for Internet Calendaring
Registers the ENUM labels that let a phone number point to a person's calendar for invitations or for browsing.
Mahy, R. and B. Hoeneisen, "IANA Registration of Enumservices for Internet Calendaring", RFC 5333, DOI 10.17487/RFC5333, October 2009, <https://www.rfc-editor.org/info/rfc5333>.
@misc{rfc5333,
series = {Request for Comments},
number = 5333,
howpublished = {RFC 5333},
publisher = {RFC Editor},
doi = {10.17487/RFC5333},
url = {https://www.rfc-editor.org/info/rfc5333},
author = {R. Mahy and B. Hoeneisen},
title = {{IANA Registration of Enumservices for Internet Calendaring}},
pagetotal = 8,
year = 2009,
month = oct,
} RFC text
Contents
Network Working Group R. Mahy
Request for Comments: 5333 Unaffiliated
Category: Standards Track B. Hoeneisen
Swisscom
October 2009
IANA Registration of Enumservices for Internet Calendaring
Abstract
This document registers Enumservices for Internet calendaring.
Specifically, this document focuses on Enumservices for scheduling
with iMIP (iCalendar Message-Based Interoperability Protocol) and for
accessing Internet calendaring information with CalDAV (Calendaring
Extensions to WebDAV).
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
1. Introduction
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS
(Domain Name System, 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] [iCalendar Transport-Independent Interoperability Protocol]
describes a way to use the iCalendar language to do scheduling. iMIP
[6] [iCalendar Message-Based Interoperability Protocol] describes how
to do iTIP scheduling via e-mail".
Recently, another Standards Track protocol for calendar and
scheduling access has appeared. CalDAV (Calendaring Extensions to
WebDAV) [7] is a WebDAV (Web-based Distributed Authoring and
Versioning) [8] 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 in the future.
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 Enumservices for scheduling and accessing
Internet calendaring information associated with an E.164 number.
2. Enumservice Registrations
As defined in RFC 3761 [1], the following templates cover the
information needed for the registration of the Enumservices specified
in this document:
Enumservice Name:
"ical-sched"
Enumservice Type:
"ical-sched"
Enumservice Subtypes:
"mailto"
URI scheme(s):
'mailto:'
Functional Specification:
This Enumservice indicates that the resource identified can be
addressed by the associated URI used for scheduling using Internet
calendaring via Internet mail with the iMIP [6] protocol.
Security considerations:
See Section 4.
Intended usage:
COMMON
Author:
Rohan Mahy (rohan@ekabal.com)
Enumservice Name:
"ical-access"
Enumservice Type:
"ical-access"
Enumservice Subtypes:
"http"
URI scheme(s):
'http:'
Functional Specification:
This Enumservice indicates that the resource identified can be
addressed by the associated URI in order to access a user's
calendar (for example free/busy status) using the CalDAV [7]
protocol for Internet calendaring.
Security considerations:
See Section 4.
Intended usage:
COMMON
Author:
Rohan Mahy (rohan@ekabal.com)
Enumservice Name:
"ical-access"
Enumservice Type:
"ical-access"
Enumservice Subtypes:
"https"
URI scheme(s):
'https:'
Functional Specification:
This Enumservice indicates that the resource identified can be
addressed by the associated URI in order to access a user's
calendar (for example free/busy status) using the CalDAV [7]
protocol for Internet calendaring.
Security considerations:
See Section 4.
Intended usage:
COMMON
Author:
Rohan Mahy (rohan@ekabal.com)
Note: These Enumservices use a dash "-" in the Type strings. To
allow for hierarchical concepts (as required in this case), some kind
of boundary needs to be in place. Neither RFC 3761 [1] nor its
intended successor [17] foresee the concept of sub-subtyping. The
natural solution to address this requirement is the usage of dash "-"
in Type strings, which is slightly contradictory to RFC 3761 [1].
However, its intended successors [16] [17] clearly allow a dash "-"
in Type strings, so that using "-" is seen as a practical way
forward.
3. Examples
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
@ NAPTR 10 100 "u" "E2U+ical-access:https" \
"!^.*$!https://cal.example.com/home/alice/calendars/!" .
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
@ NAPTR 20 100 "u" "E2U+ical-sched:mailto" \
"!^.*$!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 [1], 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
(DNS Security, RFC 4035 [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
(Transport Layer Security, RFC 5246 [13]) 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 it 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.
5. IANA Considerations
This document requests registration of the "ical-sched" and "ical-
access" Enumservices 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.
6.2. Informative 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.2", RFC 5246, August 2008.
[14] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[15] Daboo, C. and B. Desruisseaux, "CalDAV Scheduling Extensions to
WebDAV", Work in Progress, August 2009.
[16] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery System
(DDDS) Application (ENUM)", Work in Progress, May 2009.
[17] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template and IANA
Considerations", Work in Progress, September 2009.
Appendix A. Acknowledgments
Thanks to Lisa Dusseault and Alexander Mayrhofer for reviewing this
document.
Authors' Addresses
Rohan Mahy
Unaffiliated
EMail: rohan@ekabal.com
Bernie Hoeneisen
Swisscom
CH-8000 Zuerich
Switzerland
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen@swisscom.com)
URI: http://www.swisscom.com/
AI ELI5
On this page
§1Why Calendar Enumservices
ENUM (E.164 Number Mapping, RFC 3761) uses the Domain Name System to translate a telephone number such as +12025550100 into a URI such as mailto:user@example.com. It exists mainly to connect systems that use telephone numbers with those that use URIs.
The RFC gives a concrete use: a phone could check the free/busy status of someone in its address book, or propose a meeting with them, starting from the person's phone number. This document registers the Enumservices needed to make that possible for Internet calendaring.
You know someone's phone number. This RFC lets your phone use that number to find their calendar, a bit like looking up an address from a name.
§2The Calendaring Protocols Involved
The RFC quotes the Guide to Internet Calendaring (RFC 3283) to place the pieces. iCalendar is the language used to describe calendar objects. iTIP describes how to use iCalendar to do scheduling. iMIP describes how to do iTIP scheduling via e-mail.
A newer Standards Track protocol, CalDAV (RFC 4791), is based on WebDAV. It manipulates Internet calendars and views free/busy lists, and a planned scheduling extension could later be used to propose events too.
These services are already addressed by existing URI schemes: mailto: for iMIP-compatible calendar services, and http: and https: for CalDAV-compatible ones.
There are two ways to deal with a calendar. One is to email an invitation, and the other is to open the calendar over the web. Each already has its own kind of address.
§3The Registered Enumservices
Following the templates of RFC 3761, the RFC registers two Enumservice names. Both are marked with intended usage COMMON, and the author is given as Rohan Mahy.
ical-schedwith subtypemailtoand URI schememailto:. The URI can be used for scheduling with Internet calendaring via Internet mail, using iMIP.ical-accesswith subtypehttpand URI schemehttp:. The URI can be used to access a user's calendar, for example free/busy status, using CalDAV.ical-accesswith subtypehttpsand URI schemehttps:, with the same purpose as thehttpsubtype.
There are two tags. One says send invitations here by email. The other says look at the calendar here on the web.
| Type | Subtype | URI scheme | Protocol |
|---|---|---|---|
| ical-sched | mailto | mailto: | iMIP |
| ical-access | http | http: | CalDAV |
| ical-access | https | https: | CalDAV |
§4The Dash in the Type Names
Both types contain a dash, as in ical-sched. The RFC explains that the Enumservices need hierarchical concepts, so some kind of boundary has to separate the parts of the name. Neither RFC 3761 nor its intended successor foresees sub-subtyping.
Using a dash is therefore described as slightly contradictory to RFC 3761. The intended successors clearly allow a dash in Type strings, so the authors treat it as a practical way forward.
The tag names have a small dash in the middle to split them into parts. The old rules did not plan for that, but the newer rules do, so the authors went ahead.
§5Example DNS Records
The RFC shows two NAPTR records under the same E.164 name. The first, with the service field E2U+ical-access:https, maps to an HTTPS calendar URL. The second, with E2U+ical-sched:mailto, maps to a mailto: address. The numbers 10 and 20 are the order values of the two records.
The phone number's listing has two lines. One line says where to browse the calendar, and the other says where to email invitations.
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
@ NAPTR 10 100 "u" "E2U+ical-access:https" \
"!^.*$!https://cal.example.com/home/alice/calendars/!" .
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
@ NAPTR 20 100 "u" "E2U+ical-sched:mailto" \
"!^.*$!mailto:alice@example.com!" .§6Security and Privacy
DNS makes no policy decisions about which records it gives out, so all records must be assumed available to all inquirers at all times. ENUM data is therefore open to the public. A calendaring URI alone is unlikely to cause many privacy problems, although depending on its structure it might reveal the full name or employer of the target. Anonymous URIs mitigate this.
DNS in its current form offers no way to confirm that an answer is authentic. Many of these problems are prevented when the resolver verifies answers with DNSSEC, where it is available. Threat analyses are in RFC 3761 and RFC 3833.
The more serious concern is attack on the calendaring system itself, such as unauthorized modification or viewing. iTIP lists security requirements for authentication, integrity and confidentiality, and CalDAV over https: uses TLS for server authentication, confidentiality and message integrity. Calendar URIs are often already guessable and usually need credentials, so revealing an unprotected calendar through ENUM is unlikely in practice.
A phone number listing is like a public phone book, so anyone can see it. The real protection is that the calendar itself asks for a password before showing anything.