diff options
Diffstat (limited to 'rfcs/RFC 6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV).html.html')
| -rw-r--r-- | rfcs/RFC 6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV).html.html | 854 |
1 files changed, 854 insertions, 0 deletions
diff --git a/rfcs/RFC 6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV).html.html b/rfcs/RFC 6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV).html.html new file mode 100644 index 0000000..15610d7 --- /dev/null +++ b/rfcs/RFC 6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV).html.html @@ -0,0 +1,854 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> +<meta http-equiv="content-type" content="text/html; charset=UTF-8"> + <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> + <meta name="robots" content="index,follow"> + <meta name="creator" content="rfcmarkup version 1.111"> + <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> +<meta name="DC.Identifier" content="urn:ietf:rfc:6764"> +<meta name="DC.Description.Abstract" content="This specification describes how DNS SRV records, DNS TXT records, and +well-known URIs can be used together or separately to locate CalDAV +(Calendaring Extensions to Web Distributed Authoring and Versioning +(WebDAV)) or CardDAV (vCard Extensions to WebDAV) services."> +<meta name="DC.Creator" content="Cyrus Daboo <cyrus@daboo.name>"> +<meta name="DC.Date.Issued" content="February, 2013"> +<meta name="DC.Title" content="Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)"> + + <link rel="icon" href="index_files/rfc.png" type="image/png"> + <link rel="shortcut icon" href="index_files/rfc.png" type="image/png"> + <title>RFC 6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)</title> + + + <style type="text/css"><!--
+/* Effective stylesheet produced by snapshot save */
+body { margin: 0px 8px; font-size: 1em; }
+h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
+pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
+.pre { white-space: pre; font-family: monospace; }
+.newpage { page-break-before: always; }
+.invisible { text-decoration: none; color: white; }
+a.selflink { color: black; text-decoration: none; }
+@media print {
+ body { font-family: monospace; font-size: 10.5pt; }
+ h1, h2, h3, h4, h5, h6 { font-size: 1em; }
+ a:link, a:visited { color: inherit; text-decoration: none; }
+ .noprint { display: none; }
+}
+@media screen {
+ .grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
+ .docinfo { background-color: rgb(238, 238, 238); }
+ .top { border-top: 7px solid rgb(238, 238, 238); }
+ .bgblue { background-color: rgb(102, 102, 255); }
+ .legend { font-size: 90%; }
+}
+--></style> + <!--[if IE]> + <style> + body { + font-size: 13px; + margin: 10px 10px; + } + </style> + <![endif]--> + + <script type="text/javascript"><!--
+/* Script removed by snapshot save */
+--></script> +</head> +<body onload=""> + <div style="height: 13px;"> + <div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgblue" title="Click for colour legend."> </div> + <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout=""> + </div> + </div> +<span class="pre noprint docinfo top">[<a href="http://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/rfc/rfc6764.txt" title="Plaintext version of this document">txt</a>|<a href="http://tools.ietf.org/pdf/rfc6764" title="PDF version of this document">pdf</a>] [<a href="http://tools.ietf.org/html/draft-daboo-srv-caldav" title="draft-daboo-srv-caldav">draft-daboo-srv-c...</a>] [<a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc6764" title="Inline diff (wdiff)">Diff1</a>] [<a href="http://tools.ietf.org/rfcdiff?url2=rfc6764" title="Side-by-side diff">Diff2</a>] </span><br> +<span class="pre noprint docinfo"> </span><br> +<span class="pre noprint docinfo"> PROPOSED STANDARD</span><br> +<span class="pre noprint docinfo"> </span><br> +<pre>Internet Engineering Task Force (IETF) C. Daboo +Request for Comments: 6764 Apple Inc. +Updates: <a href="http://tools.ietf.org/html/rfc4791">4791</a>, <a href="http://tools.ietf.org/html/rfc6352">6352</a> February 2013 +Category: Standards Track +ISSN: 2070-1721 + + + <span class="h1"><h1>Locating Services for Calendaring Extensions to</h1></span> + <span class="h1"><h1>WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)</h1></span> + +Abstract + + This specification describes how DNS SRV records, DNS TXT records, + and well-known URIs can be used together or separately to locate + CalDAV (Calendaring Extensions to Web Distributed Authoring and + Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) + services. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in <a href="http://tools.ietf.org/html/rfc5741#section-2">Section 2 of RFC 5741</a>. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + <a href="http://www.rfc-editor.org/info/rfc6764">http://www.rfc-editor.org/info/rfc6764</a>. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to <a href="http://tools.ietf.org/html/bcp78">BCP 78</a> and the IETF Trust's Legal + Provisions Relating to IETF Documents + (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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 <a href="#section-4">Section 4</a>.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +<span class="grey">Daboo Standards Track [Page 1]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + +Table of Contents + + <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a> + <a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-3">3</a> + <a href="#section-3">3</a>. CalDAV SRV Service Labels .......................................<a href="#page-3">3</a> + <a href="#section-4">4</a>. CalDAV and CardDAV Service TXT Records ..........................<a href="#page-4">4</a> + <a href="#section-5">5</a>. CalDAV and CardDAV Service Well-Known URI .......................<a href="#page-4">4</a> + 5.1. Example: Well-Known URI Redirects to Actual + "Context Path" .............................................<a href="#page-5">5</a> + <a href="#section-6">6</a>. Client "Bootstrapping" Procedures ...............................<a href="#page-5">5</a> + <a href="#section-7">7</a>. Guidance for Service Providers ..................................<a href="#page-8">8</a> + <a href="#section-8">8</a>. Security Considerations .........................................<a href="#page-9">9</a> + <a href="#section-9">9</a>. IANA Considerations .............................................<a href="#page-9">9</a> + <a href="#section-9.1">9.1</a>. Well-Known URI Registrations ...............................<a href="#page-9">9</a> + <a href="#section-9.1.1">9.1.1</a>. caldav Well-Known URI Registration .................<a href="#page-10">10</a> + <a href="#section-9.1.2">9.1.2</a>. carddav Well-Known URI Registration ................<a href="#page-10">10</a> + <a href="#section-9.2">9.2</a>. Service Name Registrations ................................<a href="#page-10">10</a> + <a href="#section-9.2.1">9.2.1</a>. caldav Service Name Registration ...................<a href="#page-10">10</a> + <a href="#section-9.2.2">9.2.2</a>. caldavs Service Name Registration ..................<a href="#page-11">11</a> + <a href="#section-9.2.3">9.2.3</a>. carddav Service Name Registration ..................<a href="#page-11">11</a> + <a href="#section-9.2.4">9.2.4</a>. carddavs Service Name Registration .................<a href="#page-12">12</a> + <a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-12">12</a> + <a href="#section-11">11</a>. References ....................................................<a href="#page-12">12</a> + <a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-12">12</a> + <a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-14">14</a> + +<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span> + + [<a name="ref-RFC4791" id="ref-RFC4791">RFC4791</a>] defines the CalDAV calendar access protocol, based on HTTP + [<a href="http://tools.ietf.org/html/rfc2616" title="" hypertext transfer protocol http>RFC2616</a>], for accessing calendar data stored on a server. CalDAV + clients need to be able to discover appropriate CalDAV servers within + their local area network and at other domains, e.g., to minimize the + need for end users to know specific details such as the fully + qualified domain name (FQDN) and port number for their servers. + + [<a name="ref-RFC6352" id="ref-RFC6352">RFC6352</a>] defines the CardDAV address book access protocol based on + HTTP [<a href="http://tools.ietf.org/html/rfc2616" title="" hypertext transfer protocol http>RFC2616</a>], for accessing contact data stored on a server. As + with CalDAV, clients also need to be able to discover CardDAV + servers. + + [<a name="ref-RFC2782" id="ref-RFC2782">RFC2782</a>] defines a DNS-based service discovery protocol that has + been widely adopted as a means of locating particular services within + a local area network and beyond, using DNS SRV Resource Records + (RRs). This has been enhanced to provide additional service meta- + data by use of DNS TXT RRs as per [<a href="http://tools.ietf.org/html/rfc6763" title="" dns-based service discovery>RFC6763</a>]. + + + + + + +<span class="grey">Daboo Standards Track [Page 2]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + This specification defines new SRV service types for the CalDAV + protocol and gives an example of how clients can use this together + with other protocol features to enable simple client configuration. + SRV service types for CardDAV are already defined in <a href="http://tools.ietf.org/html/rfc6352#section-11">Section 11 of + [RFC6352]</a>. + + Another issue with CalDAV or CardDAV service discovery is that the + service might not be located at the "root" URI of the HTTP server + hosting it. Thus, a client needs to be able to determine the + complete path component of the Request-URI to use in HTTP requests: + the "context path". For example, if CalDAV is implemented as a + "servlet" in a web server "container", the servlet "context path" + might be "/caldav/". So the URI for the CalDAV service would be, + e.g., "http://caldav.example.com/caldav/" rather than + "http://caldav.example.com/". SRV RRs by themselves only provide an + FQDN and port number for the service, not a path. Since the client + "bootstrapping" process requires initial access to the "context path" + of the service, there needs to be a simple way for clients to also + discover what that path is. + + This specification makes use of the "well-known URI" feature + [<a href="http://tools.ietf.org/html/rfc5785" title="" defining well-known uniform resource identifiers>RFC5785</a>] of HTTP servers to provide a well-known URI for CalDAV or + CardDAV services that clients can use. The well-known URI will point + to a resource on the server that is simply a "stub" resource that + provides a redirect to the actual "context path" resource + representing the service endpoint. + +<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. Conventions Used in This Document</h2></span> + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [<a href="http://tools.ietf.org/html/rfc2119" title="" key words for use in rfcs to indicate requirement levels>RFC2119</a>]. + +<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. CalDAV SRV Service Labels</h2></span> + + This specification adds two SRV service labels for use with CalDAV: + + _caldav: Identifies a CalDAV server that uses HTTP without + Transport Layer Security (TLS) [<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>]. + + _caldavs: Identifies a CalDAV server that uses HTTP with TLS + [<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>]. + + + + + + + + + +<span class="grey">Daboo Standards Track [Page 3]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + Clients MUST honor Priority and Weight values in the SRV RRs, as + described by [<a href="http://tools.ietf.org/html/rfc2782" title="" a dns rr for specifying the location of services srv>RFC2782</a>]. + + Example: service record for server without TLS + + _caldav._tcp SRV 0 1 80 calendar.example.com. + + Example: service record for server with TLS + + _caldavs._tcp SRV 0 1 443 calendar.example.com. + +<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. CalDAV and CardDAV Service TXT Records</h2></span> + + When SRV RRs are used to advertise CalDAV and CardDAV services, it is + also convenient to be able to specify a "context path" in the DNS to + be retrieved at the same time. To enable that, this specification + uses a TXT RR that follows the syntax defined in <a href="http://tools.ietf.org/html/rfc6763#section-6">Section 6 of + [RFC6763]</a> and defines a "path" key for use in that record. The value + of the key MUST be the actual "context path" to the corresponding + service on the server. + + A site might provide TXT records in addition to SRV records for each + service. When present, clients MUST use the "path" value as the + "context path" for the service in HTTP requests. When not present, + clients use the ".well-known" URI approach described next. + + Example: text record for service with TLS + + _caldavs._tcp TXT path=/caldav + +<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. CalDAV and CardDAV Service Well-Known URI</h2></span> + + Two ".well-known" URIs are registered by this specification for + CalDAV and CardDAV services, "caldav" and "carddav" respectively (see + <a href="#section-9">Section 9</a>). These URIs point to a resource that the client can use + as the initial "context path" for the service they are trying to + connect to. The server MUST redirect HTTP requests for that resource + to the actual "context path" using one of the available mechanisms + provided by HTTP (e.g., using a 301, 303, or 307 response). Clients + MUST handle HTTP redirects on the ".well-known" URI. Servers MUST + NOT locate the actual CalDAV or CardDAV service endpoint at the + ".well-known" URI as per <a href="http://tools.ietf.org/html/rfc5785#section-1.1">Section 1.1 of [RFC5785]</a>. + + Servers SHOULD set an appropriate Cache-Control header value (as per + <a href="http://tools.ietf.org/html/rfc2616#section-14.9">Section 14.9 of [RFC2616]</a>) in the redirect response to ensure caching + occurs or does not occur as needed or as required by the type of + response generated. For example, if it is anticipated that the + + + + +<span class="grey">Daboo Standards Track [Page 4]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + location of the redirect might change over time, then a "no-cache" + value would be used. + + To facilitate "context paths" that might differ from user to user, + the server MAY require authentication when a client tries to access + the ".well-known" URI (i.e., the server would return a 401 status + response to the unauthenticated request from the client, then return + the redirect response only after a successful authentication by the + client). + +<span class="h3"><h3><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. Example: Well-Known URI Redirects to Actual "Context Path"</h3></span> + + A CalDAV server has a "context path" that is "/servlet/caldav". The + client will use "/.well-known/caldav" as the path for its + "bootstrapping" process after it has first found the FQDN and port + number via an SRV lookup or via manual entry of information by the + user, from which the client can parse suitable information. When the + client makes an HTTP request against "/.well-known/caldav", the + server would issue an HTTP redirect response with a Location response + header using the path "/servlet/caldav". The client would then + "follow" this redirect to the new resource and continue making HTTP + requests there to complete its "bootstrapping" process. + +<span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>. Client "Bootstrapping" Procedures</h2></span> + + This section describes a procedure that CalDAV or CardDAV clients + SHOULD use to do their initial configuration based on minimal user + input. The goal is to determine an http: or https: URI that + describes the full path to the user's principal-URL [<a href="http://tools.ietf.org/html/rfc3744" title="" web distributed authoring and versioning access control protocol>RFC3744</a>]. + + 1. Processing user input: + + * For a CalDAV server: + + + Minimal input from a user would consist of a calendar user + address and a password. A calendar user address is defined + by iCalendar [<a href="http://tools.ietf.org/html/rfc5545" title="" internet calendaring and scheduling core object specification>RFC5545</a>] to be a URI [<a href="http://tools.ietf.org/html/rfc3986" title="" uniform resource identifier generic syntax>RFC3986</a>]. Provided a + user identifier and a domain name can be extracted from the + URI, this simple "bootstrapping" configuration can be done. + + + If the calendar user address is a "mailto:" [<a href="http://tools.ietf.org/html/rfc6068" title="" the uri scheme>RFC6068</a>] URI, + the "mailbox" portion of the URI is examined, and the + "local-part" and "domain" portions are extracted. + + + If the calendar user address is an "http:" [<a href="http://tools.ietf.org/html/rfc2616" title="" hypertext transfer protocol http>RFC2616</a>] or + "https:" [<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>] URI, the "userinfo" and "host" portion + of the URI [<a href="http://tools.ietf.org/html/rfc3986" title="" uniform resource identifier generic syntax>RFC3986</a>] is extracted. + + + + +<span class="grey">Daboo Standards Track [Page 5]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + * For a CardDAV server: + + + Minimal input from a user would consist of their email + address [<a href="http://tools.ietf.org/html/rfc5322" title="" internet message format>RFC5322</a>] for the domain where the CardDAV service + is hosted, and a password. The "mailbox" portion of the + email address is examined, and the "local-part" and + "domain" portions are extracted. + + 2. Determination of service FQDN and port number: + + * An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp + (for CardDAV) is done with the extracted "domain" as the + service domain. + + * If no result is found, the client can try _caldav._tcp (for + CalDAV) or _carddav._tcp (for CardDAV) provided non-TLS + connections are appropriate. + + * If an SRV record is returned, the client extracts the target + FQDN and port number. If multiple SRV records are returned, + the client MUST use the Priority and Weight fields in the + record to determine which one to pick (as per [<a href="http://tools.ietf.org/html/rfc2782" title="" a dns rr for specifying the location of services srv>RFC2782</a>]). + + * If an SRV record is not found, the client will need to prompt + the user to enter the FQDN and port number information + directly or use some other heuristic, for example, using the + extracted "domain" as the FQDN and default HTTPS or HTTP port + numbers. In this situation, clients MUST first attempt an + HTTP connection with TLS. + + 3. Determination of initial "context path": + + * When an SRV lookup is done and a valid SRV record returned, + the client MUST also query for a corresponding TXT record and + check for the presence of a "path" key in its response. If + present, the value of the "path" key is used for the initial + "context path". + + * When an initial "context path" has not been determined from a + TXT record, the initial "context path" is taken to be + "/.well-known/caldav" (for CalDAV) or "/.well-known/carddav" + (for CardDAV). + + * If the initial "context path" derived from a TXT record + generates HTTP errors when targeted by requests, the client + SHOULD repeat its "bootstrapping" procedure using the + appropriate ".well-known" URI instead. + + + + +<span class="grey">Daboo Standards Track [Page 6]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + 4. Determination of user identifier: + + * The client will need to make authenticated HTTP requests to + the service. Typically, a "user identifier" is required for + some form of user/password authentication. When a user + identifier is required, clients MUST first use the "mailbox" + portion of the calendar user address provided by the user in + the case of a "mailto:" address and, if that results in an + authentication failure, SHOULD fall back to using the "local- + part" extracted from the "mailto:" address. For an "http:" or + "https:" calendar user address, the "userinfo" portion is used + as the user identifier for authentication. This is in line + with the guidance outlined in <a href="#section-7">Section 7</a>. If these user + identifiers result in authentication failure, the client + SHOULD prompt the user for a valid identifier. + + 5. Connecting to the service: + + * Subsequent to configuration, the client will make HTTP + requests to the service. When using "_caldavs" or "_carddavs" + services, a TLS negotiation is done immediately upon + connection. The client MUST do certificate verification using + the procedure outlined in <a href="http://tools.ietf.org/html/rfc6125#section-6">Section 6 of [RFC6125]</a> in regard to + verification with an SRV RR as the starting point. + + * The client does a "PROPFIND" [<a href="http://tools.ietf.org/html/rfc4918" title="" http extensions for web distributed authoring and versioning>RFC4918</a>] request with the + request URI set to the initial "context path". The body of + the request SHOULD include the DAV:current-user-principal + [<a href="http://tools.ietf.org/html/rfc5397" title="" webdav current principal extension>RFC5397</a>] property as one of the properties to return. Note + that clients MUST properly handle HTTP redirect responses for + the request. The server will use the HTTP authentication + procedure outlined in [<a href="http://tools.ietf.org/html/rfc2617" title="" http authentication: basic and digest access authentication>RFC2617</a>] or use some other appropriate + authentication schemes to authenticate the user. + + * If the server returns a 404 ("Not Found") HTTP status response + to the request on the initial "context path", clients MAY try + repeating the request on the "root" URI "/" or prompt the user + for a suitable path. + + * If the DAV:current-user-principal property is returned on the + request, the client uses that value for the principal-URL of + the authenticated user. With that, it can execute a + "PROPFIND" request on the principal-URL and discover + additional properties for configuration (e.g., calendar or + address book "home" collections). + + + + + + +<span class="grey">Daboo Standards Track [Page 7]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + * If the DAV:current-user-principal property is not returned, + then the client will need to request the principal-URL path + from the user in order to continue with configuration. + + Once a successful account discovery step has been done, clients + SHOULD cache the service details that were successfully used (user + identity, principal-URL with full scheme/host/port details) and reuse + those when connecting again at a later time. + + If a subsequent connection attempt fails, or authentication fails + persistently, clients SHOULD retry the SRV lookup and account + discovery to "refresh" the cached data. + +<span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>. Guidance for Service Providers</h2></span> + + Service providers wanting to offer CalDAV or CardDAV services that + can be configured by clients using SRV records need to follow certain + procedures to ensure proper operation. + + o CalDAV or CardDAV servers SHOULD be configured to allow + authentication with calendar user addresses (just taking the + "mailbox" portion of any "mailto:" URI) or email addresses + respectively, or with "user identifiers" extracted from them. In + the former case, the addresses MUST NOT conflict with other forms + of a permitted user login name. In the latter case, the extracted + "user identifiers" need to be unique across the server and MUST + NOT conflict with any login name on the server. + + o Servers MUST force authentication for "PROPFIND" requests that + retrieve the DAV:current-user-principal property to ensure that + the value of the DAV:current-user-principal property returned + corresponds to the principal-URL of the user making the request. + + o If the service provider uses TLS, the service provider MUST ensure + a certificate is installed that can be verified by clients using + the procedure outlined in <a href="http://tools.ietf.org/html/rfc6125#section-6">Section 6 of [RFC6125]</a> in regard to + verification with an SRV RR as the starting point. In particular, + certificates SHOULD include SRV-ID and DNS-ID identifiers as + appropriate, as described in <a href="#section-8">Section 8</a>. + + o Service providers should install the appropriate SRV records for + the offered services and optionally include TXT records. + + + + + + + + + +<span class="grey">Daboo Standards Track [Page 8]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + +<span class="h2"><h2><a class="selflink" name="section-8" href="#section-8">8</a>. Security Considerations</h2></span> + + Clients that support TLS as defined by [<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>] SHOULD try the + "_caldavs" or "_carddavs" services first before trying the "_caldav" + or "_carddav" services respectively. If a user has explicitly + requested a connection with TLS, the client MUST NOT use any service + information returned for the "_caldav" or "_carddav" services. + Clients MUST follow the certificate-verification process specified in + [<a href="http://tools.ietf.org/html/rfc6125" title="" representation and verification of domain-based application service identity within internet public key infrastructure using x.509 certificates in the context transport layer security>RFC6125</a>]. + + A malicious attacker with access to the DNS server data, or that is + able to get spoofed answers cached in a recursive resolver, can + potentially cause clients to connect to any server chosen by the + attacker. In the absence of a secure DNS option, clients SHOULD + check that the target FQDN returned in the SRV record matches the + original service domain that was queried. If the target FQDN is not + in the queried domain, clients SHOULD verify with the user that the + SRV target FQDN is suitable for use before executing any connections + to the host. Alternatively, if TLS is being used for the service, + clients MUST use the procedure outlined in <a href="http://tools.ietf.org/html/rfc6125#section-6">Section 6 of [RFC6125]</a> to + verify the service. When the target FQDN does not match the original + service domain that was queried, clients MUST check the SRV-ID + identifier in the server's certificate. If the FQDN does match, + clients MUST check any SRV-ID identifiers in the server's certificate + or, if no SRV-ID identifiers are present, MUST check the DNS-ID + identifiers in the server's certificate. + + Implementations of TLS [<a href="http://tools.ietf.org/html/rfc5246" title="" the transport layer security protocol version>RFC5246</a>], used as the basis for TLS + ([<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>]), typically support multiple versions of the protocol as + well as the older SSL (Secure Sockets Layer) protocol. Because of + known security vulnerabilities, clients and servers MUST NOT request, + offer, or use SSL 2.0. See <a href="http://tools.ietf.org/html/rfc5246#appendix-E.2">Appendix E.2 of [RFC5246]</a> for further + details. + +<span class="h2"><h2><a class="selflink" name="section-9" href="#section-9">9</a>. IANA Considerations</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-9.1" href="#section-9.1">9.1</a>. Well-Known URI Registrations</h3></span> + + This document defines two ".well-known" URIs using the registration + procedure and template from <a href="http://tools.ietf.org/html/rfc5785#section-5.1">Section 5.1 of [RFC5785]</a>. + + + + + + + + + + + +<span class="grey">Daboo Standards Track [Page 9]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + +<span class="h4"><h4><a class="selflink" name="section-9.1.1" href="#section-9.1.1">9.1.1</a>. caldav Well-Known URI Registration</h4></span> + + URI suffix: caldav + + Change controller: IETF + + Specification document(s): This RFC + + Related information: See also [<a href="http://tools.ietf.org/html/rfc4791" title="" calendaring extensions to webdav>RFC4791</a>]. + +<span class="h4"><h4><a class="selflink" name="section-9.1.2" href="#section-9.1.2">9.1.2</a>. carddav Well-Known URI Registration</h4></span> + + URI suffix: carddav + + Change controller: IETF + + Specification document(s): This RFC + + Related information: See also [<a href="http://tools.ietf.org/html/rfc6352" title="" carddav: vcard extensions to web distributed authoring and versioning>RFC6352</a>]. + +<span class="h3"><h3><a class="selflink" name="section-9.2" href="#section-9.2">9.2</a>. Service Name Registrations</h3></span> + + This document registers four new service names as per [<a href="http://tools.ietf.org/html/rfc6335" title="" internet assigned numbers authority procedures for the management of service name and transport protocol port number registry>RFC6335</a>]. Two + are defined in this document, and two are defined in <a href="http://tools.ietf.org/html/rfc6352#section-11">[RFC6352], + Section 11</a>. + +<span class="h4"><h4><a class="selflink" name="section-9.2.1" href="#section-9.2.1">9.2.1</a>. caldav Service Name Registration</h4></span> + + Service Name: caldav + + Transport Protocol(s): TCP + + Assignee: IESG <iesg@ietf.org> + + Contact: IETF Chair <chair@ietf.org> + + Description: Calendaring Extensions to WebDAV (CalDAV) - non-TLS + + Reference: [<a href="#">RFC6764</a>] + + Assignment Note: This is an extension of the http service. Defined + TXT keys: path=<context path> + + + + + + + + + +<span class="grey">Daboo Standards Track [Page 10]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + +<span class="h4"><h4><a class="selflink" name="section-9.2.2" href="#section-9.2.2">9.2.2</a>. caldavs Service Name Registration</h4></span> + + Service Name: caldavs + + Transport Protocol(s): TCP + + Assignee: IESG <iesg@ietf.org> + + Contact: IETF Chair <chair@ietf.org> + + Description: Calendaring Extensions to WebDAV (CalDAV) - over TLS + + Reference: [<a href="#">RFC6764</a>] + + Assignment Note: This is an extension of the https service. Defined + TXT keys: path=<context path> + +<span class="h4"><h4><a class="selflink" name="section-9.2.3" href="#section-9.2.3">9.2.3</a>. carddav Service Name Registration</h4></span> + + Service Name: carddav + + Transport Protocol(s): TCP + + Assignee: IESG <iesg@ietf.org> + + Contact: IETF Chair <chair@ietf.org> + + Description: vCard Extensions to WebDAV (CardDAV) - non-TLS + + Reference: [<a href="http://tools.ietf.org/html/rfc6352" title="" carddav: vcard extensions to web distributed authoring and versioning>RFC6352</a>] + + Assignment Note: This is an extension of the http service. Defined + TXT keys: path=<context path> + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo Standards Track [Page 11]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + +<span class="h4"><h4><a class="selflink" name="section-9.2.4" href="#section-9.2.4">9.2.4</a>. carddavs Service Name Registration</h4></span> + + Service Name: carddavs + + Transport Protocol(s): TCP + + Assignee: IESG <iesg@ietf.org> + + Contact: IETF Chair <chair@ietf.org> + + Description: vCard Extensions to WebDAV (CardDAV) - over TLS + + Reference: [<a href="http://tools.ietf.org/html/rfc6352" title="" carddav: vcard extensions to web distributed authoring and versioning>RFC6352</a>] + + Assignment Note: This is an extension of the https service. Defined + TXT keys: path=<context path> + +<span class="h2"><h2><a class="selflink" name="section-10" href="#section-10">10</a>. Acknowledgments</h2></span> + + This specification was suggested by discussion that took place within + the Calendaring and Scheduling Consortium's CalDAV Technical + Committee. The author thanks the following for their contributions: + Stuart Cheshire, Bernard Desruisseaux, Eran Hammer-Lahav, Helge Hess, + Arnaud Quillaud, Wilfredo Sanchez, and Joe Touch. + +<span class="h2"><h2><a class="selflink" name="section-11" href="#section-11">11</a>. References</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-11.1" href="#section-11.1">11.1</a>. Normative References</h3></span> + + [<a name="ref-RFC2119" id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", <a href="http://tools.ietf.org/html/bcp14">BCP 14</a>, <a href="http://tools.ietf.org/html/rfc2119">RFC 2119</a>, March 1997. + + [<a name="ref-RFC2616" id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", <a href="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, June 1999. + + [<a name="ref-RFC2617" id="ref-RFC2617">RFC2617</a>] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A., and L. Stewart, "HTTP + Authentication: Basic and Digest Access Authentication", + <a href="http://tools.ietf.org/html/rfc2617">RFC 2617</a>, June 1999. + + [<a name="ref-RFC2782" id="ref-RFC2782">RFC2782</a>] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", <a href="http://tools.ietf.org/html/rfc2782">RFC 2782</a>, + February 2000. + + [<a name="ref-RFC2818" id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="http://tools.ietf.org/html/rfc2818">RFC 2818</a>, May 2000. + + + + + +<span class="grey">Daboo Standards Track [Page 12]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + + [<a name="ref-RFC3744" id="ref-RFC3744">RFC3744</a>] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web + Distributed Authoring and Versioning (WebDAV) + Access Control Protocol", <a href="http://tools.ietf.org/html/rfc3744">RFC 3744</a>, May 2004. + + [<a name="ref-RFC3986" id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + <a href="http://tools.ietf.org/html/rfc3986">RFC 3986</a>, January 2005. + + [<a name="ref-RFC4791" id="ref-RFC4791">RFC4791</a>] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", <a href="http://tools.ietf.org/html/rfc4791">RFC 4791</a>, + March 2007. + + [<a name="ref-RFC4918" id="ref-RFC4918">RFC4918</a>] Dusseault, L., "HTTP Extensions for Web Distributed + Authoring and Versioning (WebDAV)", <a href="http://tools.ietf.org/html/rfc4918">RFC 4918</a>, June 2007. + + [<a name="ref-RFC5246" id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", <a href="http://tools.ietf.org/html/rfc5246">RFC 5246</a>, August 2008. + + [<a name="ref-RFC5322" id="ref-RFC5322">RFC5322</a>] Resnick, P., Ed., "Internet Message Format", <a href="http://tools.ietf.org/html/rfc5322">RFC 5322</a>, + October 2008. + + [<a name="ref-RFC5397" id="ref-RFC5397">RFC5397</a>] Sanchez, W. and C. Daboo, "WebDAV Current Principal + Extension", <a href="http://tools.ietf.org/html/rfc5397">RFC 5397</a>, December 2008. + + [<a name="ref-RFC5785" id="ref-RFC5785">RFC5785</a>] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known + Uniform Resource Identifiers (URIs)", <a href="http://tools.ietf.org/html/rfc5785">RFC 5785</a>, + April 2010. + + [<a name="ref-RFC6068" id="ref-RFC6068">RFC6068</a>] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' + URI Scheme", <a href="http://tools.ietf.org/html/rfc6068">RFC 6068</a>, October 2010. + + [<a name="ref-RFC6125" id="ref-RFC6125">RFC6125</a>] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", <a href="http://tools.ietf.org/html/rfc6125">RFC 6125</a>, March 2011. + + [<a name="ref-RFC6335" id="ref-RFC6335">RFC6335</a>] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. + Cheshire, "Internet Assigned Numbers Authority (IANA) + Procedures for the Management of the Service Name and + Transport Protocol Port Number Registry", <a href="http://tools.ietf.org/html/bcp165">BCP 165</a>, + <a href="http://tools.ietf.org/html/rfc6335">RFC 6335</a>, August 2011. + + [<a name="ref-RFC6352" id="ref-RFC6352">RFC6352</a>] Daboo, C., "CardDAV: vCard Extensions to Web Distributed + Authoring and Versioning (WebDAV)", <a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a>, August 2011. + + [<a name="ref-RFC6763" id="ref-RFC6763">RFC6763</a>] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", <a href="http://tools.ietf.org/html/rfc6763">RFC 6763</a>, February 2013. + + + +<span class="grey">Daboo Standards Track [Page 13]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a> +<span class="grey"><a href="#">RFC 6764</a> SRV for CalDAV & CardDAV February 2013</span> + + +<span class="h3"><h3><a class="selflink" name="section-11.2" href="#section-11.2">11.2</a>. Informative References</h3></span> + + [<a name="ref-RFC5545" id="ref-RFC5545">RFC5545</a>] Desruisseaux, B., "Internet Calendaring and Scheduling + Core Object Specification (iCalendar)", <a href="http://tools.ietf.org/html/rfc5545">RFC 5545</a>, + September 2009. + +Author's Address + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + EMail: cyrus@daboo.name + URI: <a href="http://www.apple.com/">http://www.apple.com/</a> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daboo Standards Track [Page 14] + +</pre><br> +<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.111, available from +<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a> +</small></small></span> + +</body></html>
\ No newline at end of file |