doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc5333.txt b/doc/rfc/rfc5333.txt
new file mode 100644
index 0000000..86d5bce
--- /dev/null
+++ b/doc/rfc/rfc5333.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 1]
+
+RFC 5333           Internet Calendaring Enumservices        October 2009
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 2]
+
+RFC 5333           Internet Calendaring Enumservices        October 2009
+
+
+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)
+
+
+
+
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 3]
+
+RFC 5333           Internet Calendaring Enumservices        October 2009
+
+
+   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.
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 4]
+
+RFC 5333           Internet Calendaring Enumservices        October 2009
+
+
+   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.
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 5]
+
+RFC 5333           Internet Calendaring Enumservices        October 2009
+
+
+   [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.
+
+
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 6]
+
+RFC 5333           Internet Calendaring Enumservices        October 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 7]
+
+RFC 5333           Internet Calendaring Enumservices        October 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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy & Hoeneisen            Standards Track                     [Page 8]
+