idnits 2.17.1 draft-daboo-srv-caldav-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4791, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4791, updated by this document, for RFC5378 checks: 2004-06-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2010) is 4972 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-06 ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple Inc. 4 Updates: 4791,CardDAV-RFC-to-be September 16, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 20, 2011 9 Locating CalDAV and CardDAV services 10 draft-daboo-srv-caldav-10 12 Abstract 14 This specification describes how DNS SRV records, DNS TXT records and 15 well-known URIs can be used together or separately to locate 16 Calendaring Extensions to WebDAV (CalDAV) or vCard Extensions to 17 WebDAV (CardDAV) services. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 20, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 55 3. CalDAV SRV Service Labels . . . . . . . . . . . . . . . . . . 4 56 4. CalDAV and CardDAV Service TXT Records . . . . . . . . . . . . 4 57 5. CalDAV and CardDAV Service Well-Known URI . . . . . . . . . . 5 58 5.1. Example: well-known URI redirects to actual context 59 path . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Client "Bootstrapping" Procedures . . . . . . . . . . . . . . 5 61 7. Guidance for Service Providers . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9.1. caldav Well-Known URI Registration . . . . . . . . . . . . 10 65 9.2. carddav Well-Known URI Registration . . . . . . . . . . . 10 66 9.3. SRV Service Label Registration . . . . . . . . . . . . . . 10 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Change History (to be removed prior to 72 publication as an RFC) . . . . . . . . . . . . . . . 13 74 1. Introduction 76 [RFC4791] defines the CalDAV calendar access protocol, based on HTTP 77 [RFC2616], for accessing calendar data stored on a server. CalDAV 78 clients need to be able to discover appropriate CalDAV servers within 79 their local area network and at other domains, e.g., to minimize the 80 need for end users to know specific details such as the fully 81 qualified domain name (FQDN) and port number for their servers. 83 [I-D.ietf-vcarddav-carddav] defines the CardDAV address book access 84 protocol based on HTTP [RFC2616], for accessing contact data stored 85 on a server. As with CalDAV, clients also need to be able to 86 discover CardDAV servers. 88 [RFC2782] defines a DNS-based service discovery protocol that has 89 been widely adopted as a means of locating particular services within 90 a local area network and beyond, using DNS SRV Resource Records 91 (RRs). This has been enhanced to provide additional service meta- 92 data by use of DNS TXT Resource Records as per 93 [I-D.cheshire-dnsext-dns-sd]. 95 This specification defines new SRV service types for the CalDAV 96 protocol, and gives an example of how clients can use this together 97 with other protocol features to enable simple client configuration. 98 SRV service types for CardDAV are already defined in Section 11 of 99 [I-D.ietf-vcarddav-carddav]. 101 Another issue with CalDAV or CardDAV service discovery is that the 102 service might not be located at the "root" URI of the HTTP server 103 hosting it. Thus a client needs to be able to determine the complete 104 path component of the Request-URI to use in HTTP requests: the 105 "context path". For example, if CalDAV is implemented as a "servlet" 106 in a web server "container", the servlet "context path" might be 107 "/caldav/". So the URI for the CalDAV service would be, e.g., 108 "http://caldav.example.com/caldav/" rather than 109 "http://caldav.example.com/". SRV RRs by themselves only provide a 110 FQDN and port number for the service, not a path. Since the client 111 "bootstrapping" process requires initial access to the "context path" 112 of the service, there needs to be a simple way for clients to also 113 discover what that path is. 115 This specification makes use of the "well known URI" feature 116 [RFC5785] of HTTP servers to provide a well known URI for CalDAV or 117 CardDAV services that clients can make use of. The well known URI 118 will point to a resource on the server that is simply a "stub" 119 resource that provides a redirect to the actual "context path" 120 resource representing the service endpoint. 122 2. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. CalDAV SRV Service Labels 130 This specification adds two SRV service labels for use with CalDAV: 132 _caldav: Identifies a CalDAV server that uses HTTP without transport 133 layer security ([RFC2818]). 135 _caldavs: Identifies a CalDAV server that uses HTTP with transport 136 layer security ([RFC2818]). 138 Clients MUST honor "Priority" and "Weight" values in the SRV RRs, as 139 described by [RFC2782]. 141 Example: service record for server without transport layer security 143 _caldav._tcp SRV 0 1 80 calendar.example.com. 145 Example: service record for server with transport layer security 147 _caldavs._tcp SRV 0 1 443 calendar.example.com. 149 4. CalDAV and CardDAV Service TXT Records 151 When SRV RRs are used to advertise CalDAV and CardDAV services, it is 152 also convenient to be able to specify a "context path" in the DNS to 153 be retrieved at the same time. To enable that, this specification 154 uses a TXT RR that follows the syntax defined in Section 6 of 155 [I-D.cheshire-dnsext-dns-sd] and defines a "path" key for use in that 156 record. The value of the key MUST be the actual "context path" to 157 the corresponding service on the server. 159 A site might provide TXT records in addition to SRV records for each 160 service. When present, clients MUST use the "path" value as the 161 "context path" for the service in HTTP requests. When not present, 162 clients use the ".well-known" URI approach described next. 164 Example: text record for service with transport layer security 166 _caldavs._tcp TXT path=/caldav 168 5. CalDAV and CardDAV Service Well-Known URI 170 Two ".well-known" URIs are registered by this specification for 171 CalDAV and CardDAV services, "caldav" and "carddav" respectively (see 172 Section 9). These URIs point to a resource that the client can use 173 as the initial "context path" for the service they are trying to 174 connect to. The server MUST redirect HTTP requests for that resource 175 to the actual "context path" using one of the available mechanisms 176 provided by HTTP (e.g., using a 301, 303, 307 response). Clients 177 MUST handle HTTP redirects on the ".well-known" URI. Servers MUST 178 NOT locate the actual CalDAV or CardDAV service endpoint at the 179 ".well-known" URI as per Section 1.1 of [RFC5785]. 181 Servers SHOULD set an appropriate Cache-Control header value (as per 182 Section 14.9 of [RFC2616]) in the redirect response to ensure caching 183 occurs or does not occur as needed, or as required by the type of 184 response generated. For example, if it is anticipated that the 185 location of the redirect might change over time, then a "no-cache" 186 value would be used. 188 To facilitate "context path's" that might differ from user to user, 189 the server MAY require authentication when a client tries to access 190 the ".well-known" URI (i.e., the server would return a 401 status 191 response to the unauthenticated request from the client, then return 192 the redirect response only after a successful authentication by the 193 client). 195 5.1. Example: well-known URI redirects to actual context path 197 A CalDAV server has a "context path" that is "/servlet/caldav". The 198 client will use "/.well-known/caldav" as the path for its 199 "bootstrapping" process after it has first found the FQDN and port 200 number via an SRV lookup or via manual entry of information by the 201 user which the client can parse suitable information from. When the 202 client makes an HTTP request against "/.well-known/caldav", the 203 server would issue an HTTP redirect response with a Location response 204 header using the path "/servlet/caldav". The client would then 205 "follow" this redirect to the new resource and continue making HTTP 206 requests there to complete its "bootstrapping" process. 208 6. Client "Bootstrapping" Procedures 210 This section describes a procedure that CalDAV or CardDAV clients 211 SHOULD use to do their initial configuration based on minimal user 212 input. The goal is to determine an http: or https: URI that 213 describes the full path to the user's principal-URL [RFC3744]. 215 1. Processing user input: 217 * For a CalDAV server: 219 + Minimal input from a user would consist of a calendar user 220 address and a password. A calendar user address is defined 221 by iCalendar [RFC5545] to be a URI [RFC3986]. Provided a 222 user identifier and a domain name can be extracted from the 223 URI, this simple "bootstrap" configuration can be done. 225 + If the calendar user address is a "mailto:" [RFC2368] URI, 226 the "mailbox" portion of the URI is examined and the 227 "local-part" and "domain" portions extracted. 229 + If the calendar user address is an "http:" [RFC2616] or 230 "https:" [RFC2818] URI, the "userinfo" and "host" portion 231 of the URI [RFC3986] is extracted. 233 * For a CardDAV server: 235 + Minimal input from a user would consist of their email 236 address [RFC5322] for the domain where the CardDAV service 237 is hosted, and a password. The "mailbox" portion of the 238 email address is examined and the "local-part" and "domain" 239 portions extracted. 241 2. Determination of service FQDN and port number: 243 * An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp 244 (for CardDAV) is done with the extracted "domain" as the 245 service domain. 247 * If no result is found, the client can try _caldav._tcp (for 248 CalDAV) or _carddav._tcp (for CardDAV) provided non-SSL 249 connections are appropriate. 251 * If an SRV record is returned, the client extracts the target 252 FQDN and port number. In the case of multiple SRV records 253 returned, the client MUST use the priority and weight fields 254 in the record to determine which one to pick (as per 255 [RFC2782]). 257 * If an SRV record is not found, the client will need to prompt 258 the user to enter the FQDN and port number information 259 directly, or use some other heuristic, for example using the 260 extracted "domain" as the FQDN and default HTTPS or HTTP port 261 numbers. In this situation clients MUST first attempt an HTTP 262 connection with transport layer security. 264 3. Determination of initial "context path": 266 * When an SRV lookup is done and a valid SRV record returned, 267 the client MUST also query for a corresponding TXT record and 268 check for the presence of a "path" key in its response. If 269 present, the value of the "path" key is used for the initial 270 "context path". 272 * When an initial "context path" has not been determined from a 273 TXT record, the initial "context path" is taken to be "/.well- 274 known/caldav" (for CalDAV) or "/.well-known/carddav" (for 275 CardDAV). 277 * If the initial "context path" derived from a TXT record 278 generates HTTP errors when targeted by requests, the client 279 SHOULD repeat its bootstrap procedure using the appropriate 280 ".well-known" URI instead. 282 4. Determination of user identifier: 284 * The client will need to make authenticated HTTP requests to 285 the service. Typically a "user identifier" is required for 286 some form of user/password authentication. When a user 287 identifier is required, clients MUST first use the "mailbox" 288 portion of the calendar user address provided by the user in 289 the case of a "mailto:" address, and if that results in an 290 authentication failure, SHOULD fall back to using the "local- 291 part" extracted from the "mailto:" address. For an "http:" or 292 "https:" calendar user address, the "userinfo" portion is used 293 as the user identifier for authentication. This is in line 294 with the guidance outlined in Section 7. If these user 295 identifiers result in authentication failure, the client 296 SHOULD prompt the user for a valid identifier. 298 5. Connecting to the service: 300 * Subsequent to configuration, the client will make HTTP 301 requests to the service. When using "_caldavs" or "_carddavs" 302 services, a transport layer security negotiation is done 303 immediately upon connection. The client MUST do certificate 304 verification using the procedure outlined in Section 4 of 305 [I-D.saintandre-tls-server-id-check] in regard to verification 306 with an SRV RR as the starting point. 308 * The client does a "PROPFIND" [RFC4918] request with the 309 request URI set to the initial "context path". The body of 310 the request SHOULD include the DAV:current-user-principal 311 [RFC5397] property as one of the properties to return. Note 312 that clients MUST properly handle HTTP redirect responses for 313 the request. The server will use the HTTP authentication 314 procedure outlined in [RFC2617] or use some other appropriate 315 authentication schemes to authenticate the user. 317 * If the server returns a 404 Not Found HTTP status response to 318 the request on the initial "context path", clients MAY try 319 repeating the request on the "root" URI "/" or prompt the user 320 for a suitable path. 322 * If the DAV:current-user-principal property is returned on the 323 request, the client uses that value for the principal-URL of 324 the authenticated user. With that, it can execute a 325 "PROPFIND" request on the principal-URL and discover 326 additional properties for configuration (e.g., calendar or 327 address book "home" collections). 329 * If the DAV:current-user-principal property is not returned, 330 then the client will need to request the principal-URL path 331 from the user in order to continue with configuration. 333 Once a successful account discovery step has been done, clients 334 SHOULD cache the service details that were successfully used (user 335 identity, principal-URL with full scheme/host/port details), and re- 336 use those when connecting again at a later time. 338 If a subsequent connection attempt fails, or authentication fails 339 persistently, clients SHOULD re-try the SRV lookup and account 340 discovery to "refresh" the cached data. 342 7. Guidance for Service Providers 344 Service providers wanting to offer CalDAV or CardDAV services that 345 can be configured by clients using SRV records need to follow certain 346 procedures to ensure proper operation. 348 o CalDAV or CardDAV servers SHOULD be configured to allow 349 authentication with calendar user addresses (just taking the 350 "mailbox" portion of any "mailto:" URI) or email addresses 351 respectively, or "user identifiers" extracted from them. In the 352 former case, the addresses MUST NOT conflict with other forms of 353 permitted user login name. In the latter case, the extracted 354 "user identifiers" need to be unique across the server and MUST 355 NOT conflict with any login name on the server. 357 o Servers MUST force authentication for "PROPFIND" requests that 358 retrieve the DAV:current-user-principal property to ensure that 359 the value of the DAV:current-user-principal property returned 360 corresponds to the principal-URL of the user making the request. 362 o If the service provider uses transport layer security, the service 363 provider MUST ensure a certificate is installed that can be 364 verified by clients using the procedure outlined in Section 4 of 365 [I-D.saintandre-tls-server-id-check] in regard to verification 366 with an SRV RR as the starting point. 368 o Install the appropriate SRV records for the offered services. 369 Optionally include TXT records. 371 8. Security Considerations 373 Clients that support transport layer security as defined by [RFC2818] 374 SHOULD try the "_caldavs" or "_carddavs" services first before trying 375 the "_caldav" or "_carddav" services respectively. If a user has 376 explicitly requested a connection with transport layer security, the 377 client MUST NOT use any service information returned for the 378 "_caldav" or "_carddav" services. Clients MUST follow the 379 certificate verification process specified in 380 [I-D.saintandre-tls-server-id-check]. 382 A malicious attacker with access to the DNS server data, or able to 383 get spoofed answers cached in a recursive resolver, can potentially 384 cause clients to connect to any server chosen by the attacker. In 385 the absence of a secure DNS option, clients SHOULD check that the 386 target FQDN returned in the SRV record matches the original service 387 domain that was queried. If the target FQDN is not in the queried 388 domain, clients SHOULD verify with the user that the SRV target FQDN 389 is suitable for use before executing any connections to the host. 390 Alternatively, if transport layer security is being used for the 391 service, clients MUST use the procedure outlined in Section 4 of 392 [I-D.saintandre-tls-server-id-check] to verify the service. 394 Implementations of TLS [RFC5246], used as the basis for transport 395 layer security ([RFC2818]), typically support multiple versions of 396 the protocol as well as the older Secure Sockets Layer (SSL) 397 protocol. Because of known security vulnerabilities, clients and 398 servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of 399 [RFC5246] for further details. 401 9. IANA Considerations 403 This document defines two ".well-known" URIs using the registration 404 procedure and template from Section 5.1 of [RFC5785]. 406 9.1. caldav Well-Known URI Registration 408 URI suffix: caldav 410 Change controller: IETF. 412 Specification document(s): This RFC. 414 Related information: See also [RFC4791]. 416 9.2. carddav Well-Known URI Registration 418 URI suffix: carddav 420 Change controller: IETF. 422 Specification document(s): This RFC. 424 Related information: See also [I-D.ietf-vcarddav-carddav]. 426 9.3. SRV Service Label Registration 428 Service labels have been registered according to 429 [1] and will be 430 incorporated into IANA once a new registry is available there. 432 10. Acknowledgments 434 This specification was suggested by discussion that took place within 435 the Calendaring and Scheduling Consortium's CalDAV Technical 436 Committee. The author thanks the following for their contributions: 437 Stuart Cheshire, Bernard Desruisseaux, Eran Hammer-Lahav, Helge Hess, 438 Arnaud Quillaud, Wilfredo Sanchez, and Joe Touch. 440 11. References 442 11.1. Normative References 444 [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, 445 "DNS-Based Service Discovery", 446 draft-cheshire-dnsext-dns-sd-06 447 (work in progress), March 2010. 449 [I-D.ietf-vcarddav-carddav] Daboo, C., "vCard Extensions to 450 WebDAV (CardDAV)", 451 draft-ietf-vcarddav-carddav-10 452 (work in progress), 453 November 2009. 455 [I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges, 456 "Representation and 457 Verification of Domain-Based 458 Application Service Identity in 459 Certificates Used with 460 Transport Layer Security", draf 461 t-saintandre-tls-server-id- 462 check-09 (work in progress), 463 August 2010. 465 [RFC2119] Bradner, S., "Key words for use 466 in RFCs to Indicate Requirement 467 Levels", BCP 14, RFC 2119, 468 March 1997. 470 [RFC2368] Hoffman, P., Masinter, L., and 471 J. Zawinski, "The mailto URL 472 scheme", RFC 2368, July 1998. 474 [RFC2616] Fielding, R., Gettys, J., 475 Mogul, J., Frystyk, H., 476 Masinter, L., Leach, P., and T. 477 Berners-Lee, "Hypertext 478 Transfer Protocol -- HTTP/1.1", 479 RFC 2616, June 1999. 481 [RFC2617] Franks, J., Hallam-Baker, P., 482 Hostetler, J., Lawrence, S., 483 Leach, P., Luotonen, A., and L. 484 Stewart, "HTTP Authentication: 485 Basic and Digest Access 486 Authentication", RFC 2617, 487 June 1999. 489 [RFC2782] Gulbrandsen, A., Vixie, P., and 490 L. Esibov, "A DNS RR for 491 specifying the location of 492 services (DNS SRV)", RFC 2782, 493 February 2000. 495 [RFC2818] Rescorla, E., "HTTP Over TLS", 496 RFC 2818, May 2000. 498 [RFC3744] Clemm, G., Reschke, J., Sedlar, 499 E., and J. Whitehead, "Web 500 Distributed Authoring and 501 Versioning (WebDAV) 502 Access Control Protocol", 503 RFC 3744, May 2004. 505 [RFC3986] Berners-Lee, T., Fielding, R., 506 and L. Masinter, "Uniform 507 Resource Identifier (URI): 508 Generic Syntax", STD 66, 509 RFC 3986, January 2005. 511 [RFC4791] Daboo, C., Desruisseaux, B., 512 and L. Dusseault, "Calendaring 513 Extensions to WebDAV (CalDAV)", 514 RFC 4791, March 2007. 516 [RFC4918] Dusseault, L., "HTTP Extensions 517 for Web Distributed Authoring 518 and Versioning (WebDAV)", 519 RFC 4918, June 2007. 521 [RFC5246] Dierks, T. and E. Rescorla, 522 "The Transport Layer Security 523 (TLS) Protocol Version 1.2", 524 RFC 5246, August 2008. 526 [RFC5322] Resnick, P., Ed., "Internet 527 Message Format", RFC 5322, 528 October 2008. 530 [RFC5397] Sanchez, W. and C. Daboo, 531 "WebDAV Current Principal 532 Extension", RFC 5397, 533 December 2008. 535 [RFC5785] Nottingham, M. and E. Hammer- 536 Lahav, "Defining Well-Known 537 Uniform Resource Identifiers 538 (URIs)", RFC 5785, April 2010. 540 11.2. Informative References 542 [RFC5545] Desruisseaux, B., "Internet 543 Calendaring and Scheduling Core 544 Object Specification 545 (iCalendar)", RFC 5545, 546 September 2009. 548 URIs 550 [1] 552 Appendix A. Change History (to be removed prior to publication as an 553 RFC) 555 Changes in -09: 557 1. IESG Review: minor editorial changes. 559 2. GenART Review: minor editorial changes. 561 3. GenART Review: "guideline" -> "procedure". 563 4. GenART Review: "port" -> "port number". 565 5. GenART Review: added definition of "context path". 567 6. GenART Review: clarified OPTIONAL nature of suggested client 568 procedure. 570 7. GenART Review: clarified that TXT lookup is an additional query. 572 8. IESG Review: now allow any HTTP redirect response, not just 301. 574 9. IESG Review: added text on cache interaction with redirect. 576 Changes in -10: 578 1. AD Review: make client procedure a SHOULD. 580 Changes in -08: 582 1. Clarify that email address is a valid input in Section 7 for 583 CardDAV. 585 2. Clarified aspects of DAV:current-user-principal handling for 586 servers. 588 3. Added additional text to indicate TXT being used in abstract and 589 introduction. 591 Changes in -07: 593 1. Add password to required minimal user input 595 2. Section 3 -> Section 4 of server-id check draft. 597 Changes in -06: 599 1. Last call comments: Revised title, abstract and text to indicate 600 that SRV and .well-known can be done separately. 602 2. Revised IANA section to use dns-sd registry for now. 604 3. Added optional TXT RR with path key for service context path in 605 the DNS 607 4. Re-organized client bootstrap to take account of TXT and to call- 608 out the different "phases" involved via a numbered list. 610 Changes in -05: 612 1. AD Review: Added "Updates" for 4791 and CardDAV. 614 2. AD Review: Changed SHOULD to MUST for honoring priority and 615 weight. 617 3. AD Review: Added additional reference to 3986 when talking about 618 userinfo/host portions of the URI. 620 4. AD Review: Changed section reference for tls-server-id-check 621 draft. 623 5. AD Review: Changed should to SHOULD when describing PROPFIND 624 request and made 5397 normative. 626 6. AD Review: Made 3744 and 5322 normative references. 628 7. AD Review: Added IANA SRV registration request. 630 Changes in -04: 632 1. Added addition text to client guidelines indicating that clients 633 cache the discovery details and can re-do discovery if 634 connections later fail. 636 2. Changed principal-URI to principal-URL. 638 Changes in -03: 640 1. Updated to RFC 5785 reference. 642 2. Added SSL v2 restriction from srv-email document added after IESG 643 review. 645 3. Tweaked client/server guidelines to better match HTTP challenge/ 646 response authentication mechanism. 648 Changes in -02: 650 1. Re-organized introduction. 652 2. Brought terminology into line with srv-email document which has 653 been through last call. 655 3. Brought security section into line with srv-email document which 656 has been through last call. 658 Changes in -01: 660 1. Added discovery of CardDAV service. 662 2. Now makes use of well-known URIs for the service "context path". 664 3. Updated to RFC 5545 reference. 666 4. Added reference to certificate verification spec. 668 Author's Address 670 Cyrus Daboo 671 Apple Inc. 672 1 Infinite Loop 673 Cupertino, CA 95014 674 USA 676 EMail: cyrus@daboo.name 677 URI: http://www.apple.com/