7Internet Engineering Task Force (IETF) C. Daboo
8Request for Comments: 6764 Apple Inc.
9Updates: 4791, 6352 February 2013
10Category: Standards Track
14 Locating Services for Calendaring Extensions to
15 WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
19 This specification describes how DNS SRV records, DNS TXT records,
20 and well-known URIs can be used together or separately to locate
21 CalDAV (Calendaring Extensions to Web Distributed Authoring and
22 Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV)
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6764.
41 Copyright (c) 2013 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Daboo Standards Track [Page 1]
60RFC 6764 SRV for CalDAV & CardDAV February 2013
65 1. Introduction ....................................................2
66 2. Conventions Used in This Document ...............................3
67 3. CalDAV SRV Service Labels .......................................3
68 4. CalDAV and CardDAV Service TXT Records ..........................4
69 5. CalDAV and CardDAV Service Well-Known URI .......................4
70 5.1. Example: Well-Known URI Redirects to Actual
71 "Context Path" .............................................5
72 6. Client "Bootstrapping" Procedures ...............................5
73 7. Guidance for Service Providers ..................................8
74 8. Security Considerations .........................................9
75 9. IANA Considerations .............................................9
76 9.1. Well-Known URI Registrations ...............................9
77 9.1.1. caldav Well-Known URI Registration .................10
78 9.1.2. carddav Well-Known URI Registration ................10
79 9.2. Service Name Registrations ................................10
80 9.2.1. caldav Service Name Registration ...................10
81 9.2.2. caldavs Service Name Registration ..................11
82 9.2.3. carddav Service Name Registration ..................11
83 9.2.4. carddavs Service Name Registration .................12
84 10. Acknowledgments ...............................................12
85 11. References ....................................................12
86 11.1. Normative References .....................................12
87 11.2. Informative References ...................................14
91 [RFC4791] defines the CalDAV calendar access protocol, based on HTTP
92 [RFC2616], for accessing calendar data stored on a server. CalDAV
93 clients need to be able to discover appropriate CalDAV servers within
94 their local area network and at other domains, e.g., to minimize the
95 need for end users to know specific details such as the fully
96 qualified domain name (FQDN) and port number for their servers.
98 [RFC6352] defines the CardDAV address book access protocol based on
99 HTTP [RFC2616], for accessing contact data stored on a server. As
100 with CalDAV, clients also need to be able to discover CardDAV
103 [RFC2782] defines a DNS-based service discovery protocol that has
104 been widely adopted as a means of locating particular services within
105 a local area network and beyond, using DNS SRV Resource Records
106 (RRs). This has been enhanced to provide additional service meta-
107 data by use of DNS TXT RRs as per [RFC6763].
114Daboo Standards Track [Page 2]
116RFC 6764 SRV for CalDAV & CardDAV February 2013
119 This specification defines new SRV service types for the CalDAV
120 protocol and gives an example of how clients can use this together
121 with other protocol features to enable simple client configuration.
122 SRV service types for CardDAV are already defined in Section 11 of
125 Another issue with CalDAV or CardDAV service discovery is that the
126 service might not be located at the "root" URI of the HTTP server
127 hosting it. Thus, a client needs to be able to determine the
128 complete path component of the Request-URI to use in HTTP requests:
129 the "context path". For example, if CalDAV is implemented as a
130 "servlet" in a web server "container", the servlet "context path"
131 might be "/caldav/". So the URI for the CalDAV service would be,
132 e.g., "http://caldav.example.com/caldav/" rather than
133 "http://caldav.example.com/". SRV RRs by themselves only provide an
134 FQDN and port number for the service, not a path. Since the client
135 "bootstrapping" process requires initial access to the "context path"
136 of the service, there needs to be a simple way for clients to also
137 discover what that path is.
139 This specification makes use of the "well-known URI" feature
140 [RFC5785] of HTTP servers to provide a well-known URI for CalDAV or
141 CardDAV services that clients can use. The well-known URI will point
142 to a resource on the server that is simply a "stub" resource that
143 provides a redirect to the actual "context path" resource
144 representing the service endpoint.
1462. Conventions Used in This Document
148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
150 document are to be interpreted as described in [RFC2119].
1523. CalDAV SRV Service Labels
154 This specification adds two SRV service labels for use with CalDAV:
156 _caldav: Identifies a CalDAV server that uses HTTP without
157 Transport Layer Security (TLS) [RFC2818].
159 _caldavs: Identifies a CalDAV server that uses HTTP with TLS
170Daboo Standards Track [Page 3]
172RFC 6764 SRV for CalDAV & CardDAV February 2013
175 Clients MUST honor Priority and Weight values in the SRV RRs, as
176 described by [RFC2782].
178 Example: service record for server without TLS
180 _caldav._tcp SRV 0 1 80 calendar.example.com.
182 Example: service record for server with TLS
184 _caldavs._tcp SRV 0 1 443 calendar.example.com.
1864. CalDAV and CardDAV Service TXT Records
188 When SRV RRs are used to advertise CalDAV and CardDAV services, it is
189 also convenient to be able to specify a "context path" in the DNS to
190 be retrieved at the same time. To enable that, this specification
191 uses a TXT RR that follows the syntax defined in Section 6 of
192 [RFC6763] and defines a "path" key for use in that record. The value
193 of the key MUST be the actual "context path" to the corresponding
194 service on the server.
196 A site might provide TXT records in addition to SRV records for each
197 service. When present, clients MUST use the "path" value as the
198 "context path" for the service in HTTP requests. When not present,
199 clients use the ".well-known" URI approach described next.
201 Example: text record for service with TLS
203 _caldavs._tcp TXT path=/caldav
2055. CalDAV and CardDAV Service Well-Known URI
207 Two ".well-known" URIs are registered by this specification for
208 CalDAV and CardDAV services, "caldav" and "carddav" respectively (see
209 Section 9). These URIs point to a resource that the client can use
210 as the initial "context path" for the service they are trying to
211 connect to. The server MUST redirect HTTP requests for that resource
212 to the actual "context path" using one of the available mechanisms
213 provided by HTTP (e.g., using a 301, 303, or 307 response). Clients
214 MUST handle HTTP redirects on the ".well-known" URI. Servers MUST
215 NOT locate the actual CalDAV or CardDAV service endpoint at the
216 ".well-known" URI as per Section 1.1 of [RFC5785].
218 Servers SHOULD set an appropriate Cache-Control header value (as per
219 Section 14.9 of [RFC2616]) in the redirect response to ensure caching
220 occurs or does not occur as needed or as required by the type of
221 response generated. For example, if it is anticipated that the
226Daboo Standards Track [Page 4]
228RFC 6764 SRV for CalDAV & CardDAV February 2013
231 location of the redirect might change over time, then a "no-cache"
234 To facilitate "context paths" that might differ from user to user,
235 the server MAY require authentication when a client tries to access
236 the ".well-known" URI (i.e., the server would return a 401 status
237 response to the unauthenticated request from the client, then return
238 the redirect response only after a successful authentication by the
2415.1. Example: Well-Known URI Redirects to Actual "Context Path"
243 A CalDAV server has a "context path" that is "/servlet/caldav". The
244 client will use "/.well-known/caldav" as the path for its
245 "bootstrapping" process after it has first found the FQDN and port
246 number via an SRV lookup or via manual entry of information by the
247 user, from which the client can parse suitable information. When the
248 client makes an HTTP request against "/.well-known/caldav", the
249 server would issue an HTTP redirect response with a Location response
250 header using the path "/servlet/caldav". The client would then
251 "follow" this redirect to the new resource and continue making HTTP
252 requests there to complete its "bootstrapping" process.
2546. Client "Bootstrapping" Procedures
256 This section describes a procedure that CalDAV or CardDAV clients
257 SHOULD use to do their initial configuration based on minimal user
258 input. The goal is to determine an http: or https: URI that
259 describes the full path to the user's principal-URL [RFC3744].
261 1. Processing user input:
263 * For a CalDAV server:
265 + Minimal input from a user would consist of a calendar user
266 address and a password. A calendar user address is defined
267 by iCalendar [RFC5545] to be a URI [RFC3986]. Provided a
268 user identifier and a domain name can be extracted from the
269 URI, this simple "bootstrapping" configuration can be done.
271 + If the calendar user address is a "mailto:" [RFC6068] URI,
272 the "mailbox" portion of the URI is examined, and the
273 "local-part" and "domain" portions are extracted.
275 + If the calendar user address is an "http:" [RFC2616] or
276 "https:" [RFC2818] URI, the "userinfo" and "host" portion
277 of the URI [RFC3986] is extracted.
282Daboo Standards Track [Page 5]
284RFC 6764 SRV for CalDAV & CardDAV February 2013
287 * For a CardDAV server:
289 + Minimal input from a user would consist of their email
290 address [RFC5322] for the domain where the CardDAV service
291 is hosted, and a password. The "mailbox" portion of the
292 email address is examined, and the "local-part" and
293 "domain" portions are extracted.
295 2. Determination of service FQDN and port number:
297 * An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp
298 (for CardDAV) is done with the extracted "domain" as the
301 * If no result is found, the client can try _caldav._tcp (for
302 CalDAV) or _carddav._tcp (for CardDAV) provided non-TLS
303 connections are appropriate.
305 * If an SRV record is returned, the client extracts the target
306 FQDN and port number. If multiple SRV records are returned,
307 the client MUST use the Priority and Weight fields in the
308 record to determine which one to pick (as per [RFC2782]).
310 * If an SRV record is not found, the client will need to prompt
311 the user to enter the FQDN and port number information
312 directly or use some other heuristic, for example, using the
313 extracted "domain" as the FQDN and default HTTPS or HTTP port
314 numbers. In this situation, clients MUST first attempt an
315 HTTP connection with TLS.
317 3. Determination of initial "context path":
319 * When an SRV lookup is done and a valid SRV record returned,
320 the client MUST also query for a corresponding TXT record and
321 check for the presence of a "path" key in its response. If
322 present, the value of the "path" key is used for the initial
325 * When an initial "context path" has not been determined from a
326 TXT record, the initial "context path" is taken to be
327 "/.well-known/caldav" (for CalDAV) or "/.well-known/carddav"
330 * If the initial "context path" derived from a TXT record
331 generates HTTP errors when targeted by requests, the client
332 SHOULD repeat its "bootstrapping" procedure using the
333 appropriate ".well-known" URI instead.
338Daboo Standards Track [Page 6]
340RFC 6764 SRV for CalDAV & CardDAV February 2013
343 4. Determination of user identifier:
345 * The client will need to make authenticated HTTP requests to
346 the service. Typically, a "user identifier" is required for
347 some form of user/password authentication. When a user
348 identifier is required, clients MUST first use the "mailbox"
349 portion of the calendar user address provided by the user in
350 the case of a "mailto:" address and, if that results in an
351 authentication failure, SHOULD fall back to using the "local-
352 part" extracted from the "mailto:" address. For an "http:" or
353 "https:" calendar user address, the "userinfo" portion is used
354 as the user identifier for authentication. This is in line
355 with the guidance outlined in Section 7. If these user
356 identifiers result in authentication failure, the client
357 SHOULD prompt the user for a valid identifier.
359 5. Connecting to the service:
361 * Subsequent to configuration, the client will make HTTP
362 requests to the service. When using "_caldavs" or "_carddavs"
363 services, a TLS negotiation is done immediately upon
364 connection. The client MUST do certificate verification using
365 the procedure outlined in Section 6 of [RFC6125] in regard to
366 verification with an SRV RR as the starting point.
368 * The client does a "PROPFIND" [RFC4918] request with the
369 request URI set to the initial "context path". The body of
370 the request SHOULD include the DAV:current-user-principal
371 [RFC5397] property as one of the properties to return. Note
372 that clients MUST properly handle HTTP redirect responses for
373 the request. The server will use the HTTP authentication
374 procedure outlined in [RFC2617] or use some other appropriate
375 authentication schemes to authenticate the user.
377 * If the server returns a 404 ("Not Found") HTTP status response
378 to the request on the initial "context path", clients MAY try
379 repeating the request on the "root" URI "/" or prompt the user
382 * If the DAV:current-user-principal property is returned on the
383 request, the client uses that value for the principal-URL of
384 the authenticated user. With that, it can execute a
385 "PROPFIND" request on the principal-URL and discover
386 additional properties for configuration (e.g., calendar or
387 address book "home" collections).
394Daboo Standards Track [Page 7]
396RFC 6764 SRV for CalDAV & CardDAV February 2013
399 * If the DAV:current-user-principal property is not returned,
400 then the client will need to request the principal-URL path
401 from the user in order to continue with configuration.
403 Once a successful account discovery step has been done, clients
404 SHOULD cache the service details that were successfully used (user
405 identity, principal-URL with full scheme/host/port details) and reuse
406 those when connecting again at a later time.
408 If a subsequent connection attempt fails, or authentication fails
409 persistently, clients SHOULD retry the SRV lookup and account
410 discovery to "refresh" the cached data.
4127. Guidance for Service Providers
414 Service providers wanting to offer CalDAV or CardDAV services that
415 can be configured by clients using SRV records need to follow certain
416 procedures to ensure proper operation.
418 o CalDAV or CardDAV servers SHOULD be configured to allow
419 authentication with calendar user addresses (just taking the
420 "mailbox" portion of any "mailto:" URI) or email addresses
421 respectively, or with "user identifiers" extracted from them. In
422 the former case, the addresses MUST NOT conflict with other forms
423 of a permitted user login name. In the latter case, the extracted
424 "user identifiers" need to be unique across the server and MUST
425 NOT conflict with any login name on the server.
427 o Servers MUST force authentication for "PROPFIND" requests that
428 retrieve the DAV:current-user-principal property to ensure that
429 the value of the DAV:current-user-principal property returned
430 corresponds to the principal-URL of the user making the request.
432 o If the service provider uses TLS, the service provider MUST ensure
433 a certificate is installed that can be verified by clients using
434 the procedure outlined in Section 6 of [RFC6125] in regard to
435 verification with an SRV RR as the starting point. In particular,
436 certificates SHOULD include SRV-ID and DNS-ID identifiers as
437 appropriate, as described in Section 8.
439 o Service providers should install the appropriate SRV records for
440 the offered services and optionally include TXT records.
450Daboo Standards Track [Page 8]
452RFC 6764 SRV for CalDAV & CardDAV February 2013
4558. Security Considerations
457 Clients that support TLS as defined by [RFC2818] SHOULD try the
458 "_caldavs" or "_carddavs" services first before trying the "_caldav"
459 or "_carddav" services respectively. If a user has explicitly
460 requested a connection with TLS, the client MUST NOT use any service
461 information returned for the "_caldav" or "_carddav" services.
462 Clients MUST follow the certificate-verification process specified in
465 A malicious attacker with access to the DNS server data, or that is
466 able to get spoofed answers cached in a recursive resolver, can
467 potentially cause clients to connect to any server chosen by the
468 attacker. In the absence of a secure DNS option, clients SHOULD
469 check that the target FQDN returned in the SRV record matches the
470 original service domain that was queried. If the target FQDN is not
471 in the queried domain, clients SHOULD verify with the user that the
472 SRV target FQDN is suitable for use before executing any connections
473 to the host. Alternatively, if TLS is being used for the service,
474 clients MUST use the procedure outlined in Section 6 of [RFC6125] to
475 verify the service. When the target FQDN does not match the original
476 service domain that was queried, clients MUST check the SRV-ID
477 identifier in the server's certificate. If the FQDN does match,
478 clients MUST check any SRV-ID identifiers in the server's certificate
479 or, if no SRV-ID identifiers are present, MUST check the DNS-ID
480 identifiers in the server's certificate.
482 Implementations of TLS [RFC5246], used as the basis for TLS
483 ([RFC2818]), typically support multiple versions of the protocol as
484 well as the older SSL (Secure Sockets Layer) protocol. Because of
485 known security vulnerabilities, clients and servers MUST NOT request,
486 offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further
4899. IANA Considerations
4919.1. Well-Known URI Registrations
493 This document defines two ".well-known" URIs using the registration
494 procedure and template from Section 5.1 of [RFC5785].
506Daboo Standards Track [Page 9]
508RFC 6764 SRV for CalDAV & CardDAV February 2013
5119.1.1. caldav Well-Known URI Registration
515 Change controller: IETF
517 Specification document(s): This RFC
519 Related information: See also [RFC4791].
5219.1.2. carddav Well-Known URI Registration
525 Change controller: IETF
527 Specification document(s): This RFC
529 Related information: See also [RFC6352].
5319.2. Service Name Registrations
533 This document registers four new service names as per [RFC6335]. Two
534 are defined in this document, and two are defined in [RFC6352],
5379.2.1. caldav Service Name Registration
541 Transport Protocol(s): TCP
543 Assignee: IESG <iesg@ietf.org>
545 Contact: IETF Chair <chair@ietf.org>
547 Description: Calendaring Extensions to WebDAV (CalDAV) - non-TLS
551 Assignment Note: This is an extension of the http service. Defined
552 TXT keys: path=<context path>
562Daboo Standards Track [Page 10]
564RFC 6764 SRV for CalDAV & CardDAV February 2013
5679.2.2. caldavs Service Name Registration
569 Service Name: caldavs
571 Transport Protocol(s): TCP
573 Assignee: IESG <iesg@ietf.org>
575 Contact: IETF Chair <chair@ietf.org>
577 Description: Calendaring Extensions to WebDAV (CalDAV) - over TLS
581 Assignment Note: This is an extension of the https service. Defined
582 TXT keys: path=<context path>
5849.2.3. carddav Service Name Registration
586 Service Name: carddav
588 Transport Protocol(s): TCP
590 Assignee: IESG <iesg@ietf.org>
592 Contact: IETF Chair <chair@ietf.org>
594 Description: vCard Extensions to WebDAV (CardDAV) - non-TLS
598 Assignment Note: This is an extension of the http service. Defined
599 TXT keys: path=<context path>
618Daboo Standards Track [Page 11]
620RFC 6764 SRV for CalDAV & CardDAV February 2013
6239.2.4. carddavs Service Name Registration
625 Service Name: carddavs
627 Transport Protocol(s): TCP
629 Assignee: IESG <iesg@ietf.org>
631 Contact: IETF Chair <chair@ietf.org>
633 Description: vCard Extensions to WebDAV (CardDAV) - over TLS
637 Assignment Note: This is an extension of the https service. Defined
638 TXT keys: path=<context path>
642 This specification was suggested by discussion that took place within
643 the Calendaring and Scheduling Consortium's CalDAV Technical
644 Committee. The author thanks the following for their contributions:
645 Stuart Cheshire, Bernard Desruisseaux, Eran Hammer-Lahav, Helge Hess,
646 Arnaud Quillaud, Wilfredo Sanchez, and Joe Touch.
65011.1. Normative References
652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
653 Requirement Levels", BCP 14, RFC 2119, March 1997.
655 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
656 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
657 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
659 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
660 Leach, P., Luotonen, A., and L. Stewart, "HTTP
661 Authentication: Basic and Digest Access Authentication",
664 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
665 specifying the location of services (DNS SRV)", RFC 2782,
668 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
674Daboo Standards Track [Page 12]
676RFC 6764 SRV for CalDAV & CardDAV February 2013
679 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
680 Distributed Authoring and Versioning (WebDAV)
681 Access Control Protocol", RFC 3744, May 2004.
683 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
684 Resource Identifier (URI): Generic Syntax", STD 66,
685 RFC 3986, January 2005.
687 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
688 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
691 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
692 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
694 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
695 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
697 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
700 [RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal
701 Extension", RFC 5397, December 2008.
703 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
704 Uniform Resource Identifiers (URIs)", RFC 5785,
707 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
708 URI Scheme", RFC 6068, October 2010.
710 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
711 Verification of Domain-Based Application Service Identity
712 within Internet Public Key Infrastructure Using X.509
713 (PKIX) Certificates in the Context of Transport Layer
714 Security (TLS)", RFC 6125, March 2011.
716 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
717 Cheshire, "Internet Assigned Numbers Authority (IANA)
718 Procedures for the Management of the Service Name and
719 Transport Protocol Port Number Registry", BCP 165,
720 RFC 6335, August 2011.
722 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
723 Authoring and Versioning (WebDAV)", RFC 6352, August 2011.
725 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
726 Discovery", RFC 6763, February 2013.
730Daboo Standards Track [Page 13]
732RFC 6764 SRV for CalDAV & CardDAV February 2013
73511.2. Informative References
737 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
738 Core Object Specification (iCalendar)", RFC 5545,
749 EMail: cyrus@daboo.name
750 URI: http://www.apple.com/
786Daboo Standards Track [Page 14]