Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6764 Apple Inc.
Updates: 4791, 6352 February 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6764 Apple Inc.
Updates: 4791, 6352 February 2013
Category: Standards Track
ISSN: 2070-1721
Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
查找WebDAV日历扩展（CalDAV）和WebDAV vCard扩展（CardDAV）的服务
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.
本规范描述了如何将DNS SRV记录、DNS TXT记录和众所周知的URI一起或分别用于定位CalDAV（Web分布式创作和版本控制（WebDAV）日历扩展）或CardDAV（WebDAV vCard扩展）服务。
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 Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6764.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6764.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. CalDAV SRV Service Labels .......................................3
4. CalDAV and CardDAV Service TXT Records ..........................4
5. CalDAV and CardDAV Service Well-Known URI .......................4
5.1. Example: Well-Known URI Redirects to Actual
"Context Path" .............................................5
6. Client "Bootstrapping" Procedures ...............................5
7. Guidance for Service Providers ..................................8
8. Security Considerations .........................................9
9. IANA Considerations .............................................9
9.1. Well-Known URI Registrations ...............................9
9.1.1. caldav Well-Known URI Registration .................10
9.1.2. carddav Well-Known URI Registration ................10
9.2. Service Name Registrations ................................10
9.2.1. caldav Service Name Registration ...................10
9.2.2. caldavs Service Name Registration ..................11
9.2.3. carddav Service Name Registration ..................11
9.2.4. carddavs Service Name Registration .................12
10. Acknowledgments ...............................................12
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................14
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. CalDAV SRV Service Labels .......................................3
4. CalDAV and CardDAV Service TXT Records ..........................4
5. CalDAV and CardDAV Service Well-Known URI .......................4
5.1. Example: Well-Known URI Redirects to Actual
"Context Path" .............................................5
6. Client "Bootstrapping" Procedures ...............................5
7. Guidance for Service Providers ..................................8
8. Security Considerations .........................................9
9. IANA Considerations .............................................9
9.1. Well-Known URI Registrations ...............................9
9.1.1. caldav Well-Known URI Registration .................10
9.1.2. carddav Well-Known URI Registration ................10
9.2. Service Name Registrations ................................10
9.2.1. caldav Service Name Registration ...................10
9.2.2. caldavs Service Name Registration ..................11
9.2.3. carddav Service Name Registration ..................11
9.2.4. carddavs Service Name Registration .................12
10. Acknowledgments ...............................................12
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................14
[RFC4791] defines the CalDAV calendar access protocol, based on HTTP [RFC2616], 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.
[RFC4791]定义了基于HTTP[RFC2616]的CalDAV日历访问协议，用于访问存储在服务器上的日历数据。CalDAV客户端需要能够在其局域网和其他域中发现适当的CalDAV服务器，例如，最大限度地减少最终用户了解其服务器的完全限定域名（FQDN）和端口号等特定详细信息的需要。
[RFC6352] defines the CardDAV address book access protocol based on HTTP [RFC2616], for accessing contact data stored on a server. As with CalDAV, clients also need to be able to discover CardDAV servers.
[RFC6352]定义了基于HTTP[RFC2616]的CardDAV通讯簿访问协议，用于访问存储在服务器上的联系人数据。与CalDAV一样，客户端还需要能够发现CardDAV服务器。
[RFC2782] 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 [RFC6763].
[RFC2782]定义了一种基于DNS的服务发现协议，该协议已被广泛采用，作为使用DNS SRV资源记录（RRs）在局域网内外定位特定服务的一种手段。根据[RFC6763]，这一功能已得到增强，通过使用DNS TXT RRs提供额外的服务元数据。
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 Section 11 of [RFC6352].
本规范为CalDAV协议定义了新的SRV服务类型，并举例说明了客户端如何将其与其他协议功能结合使用，以实现简单的客户端配置。[RFC6352]第11节中已经定义了CardDAV的SRV服务类型。
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.
CalDAV或CardDAV服务发现的另一个问题是，该服务可能不位于承载它的HTTP服务器的“根”URI上。因此，客户机需要能够确定在HTTP请求中使用的请求URI的完整路径组件：“上下文路径”。例如，如果CalDAV在web服务器“容器”中实现为“servlet”，则servlet“上下文路径”可能是“/CalDAV/”。因此CalDAV服务的URI应该是，例如“http://caldav.example.com/caldav/“而不是”http://caldav.example.com/". SRV RRs本身仅为服务提供FQDN和端口号，而不是路径。由于客户机“引导”过程需要初始访问服务的“上下文路径”，因此需要有一种简单的方法让客户机也能发现该路径是什么。
This specification makes use of the "well-known URI" feature [RFC5785] 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.
本规范利用HTTP服务器的“众所周知的URI”功能[RFC5785]为客户端可以使用的CalDAV或CardDAV服务提供众所周知的URI。众所周知的URI将指向服务器上的一个资源，该资源只是一个“存根”资源，它提供了指向表示服务端点的实际“上下文路径”资源的重定向。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification adds two SRV service labels for use with CalDAV:
本规范添加了两个SRV服务标签，用于CalDAV：
_caldav: Identifies a CalDAV server that uses HTTP without Transport Layer Security (TLS) [RFC2818].
_caldav：标识使用HTTP而不使用传输层安全性（TLS）的caldav服务器[RFC2818]。
_caldavs: Identifies a CalDAV server that uses HTTP with TLS [RFC2818].
_caldavs：标识使用HTTP和TLS[RFC2818]的CalDAV服务器。
Clients MUST honor Priority and Weight values in the SRV RRs, as described by [RFC2782].
客户必须遵守[RFC2782]所述的SRV RRs中的优先级和权重值。
Example: service record for server without TLS
示例：不带TLS的服务器的服务记录
_caldav._tcp SRV 0 1 80 calendar.example.com.
_caldav._TCPSRV 0 1 80 calendar.example.com。
Example: service record for server with TLS
示例：具有TLS的服务器的服务记录
_caldavs._tcp SRV 0 1 443 calendar.example.com.
_caldavs._TCPSRV 0 1 443 calendar.example.com。
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 Section 6 of [RFC6763] 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.
当SRV RRs用于公布CalDAV和CardDAV服务时，还可以方便地在DNS中指定要同时检索的“上下文路径”。为了实现这一点，本规范使用了一个TXT RR，它遵循[RFC6763]第6节中定义的语法，并定义了一个在该记录中使用的“路径”键。密钥的值必须是服务器上相应服务的实际“上下文路径”。
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.
除了SRV记录外，站点还可以为每个服务提供TXT记录。当存在时，客户端必须使用“path”值作为HTTP请求中服务的“上下文路径”。当不存在时，客户端使用下面描述的“.well-known”URI方法。
Example: text record for service with TLS
示例：使用TLS的服务的文本记录
_caldavs._tcp TXT path=/caldav
_caldavs.\u tcp TXT路径=/caldav
Two ".well-known" URIs are registered by this specification for CalDAV and CardDAV services, "caldav" and "carddav" respectively (see Section 9). 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 Section 1.1 of [RFC5785].
本规范为CalDAV和CardDAV服务分别注册了两个“.众所周知的”URI，“CalDAV”和“CardDAV”（参见第9节）。这些URI指向一个资源，客户机可以将该资源用作其尝试连接到的服务的初始“上下文路径”。服务器必须使用HTTP提供的一种可用机制（例如，使用301、303或307响应）将该资源的HTTP请求重定向到实际的“上下文路径”。客户端必须在“.well-known”URI上处理HTTP重定向。根据[RFC5785]第1.1节，服务器不得在“.well-known”URI上定位实际的CalDAV或CardDAV服务端点。
Servers SHOULD set an appropriate Cache-Control header value (as per Section 14.9 of [RFC2616]) 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
服务器应在重定向响应中设置适当的缓存控制头值（根据[RFC2616]第14.9节），以确保缓存根据需要或根据生成的响应类型发生或不发生。例如，如果预计
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).
为了方便用户之间可能不同的“上下文路径”，当客户端尝试访问“.well-known”URI时，服务器可能需要身份验证（即，服务器将对来自客户端的未经身份验证的请求返回401状态响应，然后仅在客户端成功身份验证后返回重定向响应）。
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.
CalDAV服务器有一个“上下文路径”，即“/servlet/CalDAV”。客户机在通过SRV查找或用户手动输入信息首次找到FQDN和端口号后，将使用“/.well-known/caldav”作为其“引导”过程的路径，客户机可以从中解析合适的信息。当客户端对“/.well-known/caldav”发出HTTP请求时，服务器将使用路径“/servlet/caldav”发出带有位置响应头的HTTP重定向响应。然后，客户机将“遵循”这个重定向到新资源，并继续在那里发出HTTP请求以完成其“引导”过程。
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 [RFC3744].
本节介绍CalDAV或CardDAV客户端应使用的过程，以根据最少的用户输入进行初始配置。目标是确定描述用户主体URL的完整路径[RFC3744]的http:或https:URI。
1. Processing user input:
1. 处理用户输入：
* For a CalDAV server:
* 对于CalDAV服务器：
+ Minimal input from a user would consist of a calendar user address and a password. A calendar user address is defined by iCalendar [RFC5545] to be a URI [RFC3986]. Provided a user identifier and a domain name can be extracted from the URI, this simple "bootstrapping" configuration can be done.
+ 用户的最小输入包括日历用户地址和密码。日历用户地址由iCalendar[RFC5545]定义为URI[RFC3986]。如果可以从URI中提取用户标识符和域名，则可以完成此简单的“引导”配置。
+ If the calendar user address is a "mailto:" [RFC6068] URI, the "mailbox" portion of the URI is examined, and the "local-part" and "domain" portions are extracted.
+ 如果日历用户地址是“mailto:”[RFC6068]URI，则会检查URI的“邮箱”部分，并提取“本地部分”和“域”部分。
+ If the calendar user address is an "http:" [RFC2616] or "https:" [RFC2818] URI, the "userinfo" and "host" portion of the URI [RFC3986] is extracted.
+ 如果日历用户地址是“http:[RFC2616]或“https:[RFC2818]URI”，则提取URI[RFC3986]的“userinfo”和“host”部分。
* For a CardDAV server:
* 对于CardDAV服务器：
+ Minimal input from a user would consist of their email address [RFC5322] 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.
+ 用户的最小输入包括其CardDAV服务所在域的电子邮件地址[RFC5322]和密码。检查电子邮件地址的“邮箱”部分，提取“本地部分”和“域”部分。
2. Determination of service FQDN and port number:
2. 确定服务FQDN和端口号：
* An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp (for CardDAV) is done with the extracted "domain" as the service domain.
* 使用提取的“域”作为服务域，完成对_caldavs._tcp（用于CalDAV）或_carddavs._tcp（用于CardDAV）的SRV查找。
* If no result is found, the client can try _caldav._tcp (for CalDAV) or _carddav._tcp (for CardDAV) provided non-TLS connections are appropriate.
* 如果未找到结果，客户端可以尝试_caldav._tcp（用于caldav）或_carddav._tcp（用于carddav），前提是非TLS连接是合适的。
* 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 [RFC2782]).
* 如果返回SRV记录，客户端将提取目标FQDN和端口号。如果返回多个SRV记录，客户机必须使用记录中的优先级和权重字段来确定选择哪一个（根据[RFC2782]）。
* 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.
* 如果未找到SRV记录，客户端将需要提示用户直接输入FQDN和端口号信息，或使用其他启发式方法，例如，使用提取的“域”作为FQDN和默认HTTPS或HTTP端口号。在这种情况下，客户端必须首先尝试与TLS建立HTTP连接。
3. Determination of initial "context path":
3. 确定初始“上下文路径”：
* 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".
* 当完成SRV查找并返回有效的SRV记录时，客户端还必须查询相应的TXT记录，并检查其响应中是否存在“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).
* 如果未根据TXT记录确定初始“上下文路径”，则初始“上下文路径”将被视为“/.well-known/caldav”（对于caldav）或“/.well-known/carddav”（对于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.
* 如果从TXT记录派生的初始“上下文路径”在被请求定位时生成HTTP错误，则客户端应使用适当的“.well-known”URI重复其“引导”过程。
4. Determination of user identifier:
4. 确定用户标识符：
* 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 Section 7. If these user identifiers result in authentication failure, the client SHOULD prompt the user for a valid identifier.
* 客户端需要向服务发出经过身份验证的HTTP请求。通常，某种形式的用户/密码身份验证需要“用户标识符”。当需要用户标识符时，对于“mailto:”地址，客户端必须首先使用用户提供的日历用户地址的“邮箱”部分，如果这导致身份验证失败，则应返回使用从“mailto:”地址提取的“本地部分”。对于“http:”或“https:”日历用户地址，“userinfo”部分用作身份验证的用户标识符。这符合第7节中概述的指南。如果这些用户标识符导致身份验证失败，客户端应提示用户输入有效标识符。
5. Connecting to the service:
5. 连接到服务：
* 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 Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point.
* 配置之后，客户端将向服务发出HTTP请求。当使用“\u caldavs”或“\u carddavs”服务时，TLS协商在连接后立即完成。客户必须使用[RFC6125]第6节中概述的程序进行证书验证，以SRV RR为起点进行验证。
* The client does a "PROPFIND" [RFC4918] request with the request URI set to the initial "context path". The body of the request SHOULD include the DAV:current-user-principal [RFC5397] 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 [RFC2617] or use some other appropriate authentication schemes to authenticate the user.
* 客户端执行“PROPFIND”[RFC4918]请求，请求URI设置为初始“上下文路径”。请求主体应包括DAV:current user principal[RFC5397]属性，作为要返回的属性之一。请注意，客户端必须正确处理请求的HTTP重定向响应。服务器将使用[RFC2617]中概述的HTTP身份验证过程，或使用一些其他适当的身份验证方案对用户进行身份验证。
* 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.
* 如果服务器对初始“上下文路径”上的请求返回404（“未找到”）HTTP状态响应，则客户端可以尝试在“根”URI“/”上重复该请求，或提示用户选择合适的路径。
* 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).
* 如果在请求中返回DAV:current user principal属性，则客户端将该值用于已验证用户的主体URL。这样，它就可以在主体URL上执行“PROPFIND”请求，并发现用于配置的其他属性（例如，日历或通讯簿“主页”集合）。
* 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.
* 如果未返回DAV:current user principal属性，则客户端需要从用户请求主体URL路径以继续配置。
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.
成功完成帐户发现步骤后，客户端应缓存成功使用的服务详细信息（用户标识、包含完整方案/主机/端口详细信息的主体URL），并在以后再次连接时重用这些信息。
If a subsequent connection attempt fails, or authentication fails persistently, clients SHOULD retry the SRV lookup and account discovery to "refresh" the cached data.
如果后续连接尝试失败，或身份验证持续失败，客户端应重试SRV查找和帐户发现以“刷新”缓存数据。
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.
想要提供CalDAV或CardDAV服务（可由客户端使用SRV记录配置）的服务提供商需要遵循某些程序以确保正确操作。
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 CalDAV或CardDAV服务器应配置为允许分别使用日历用户地址（仅使用任何“mailto:”URI的“邮箱”部分）或电子邮件地址进行身份验证，或使用从中提取的“用户标识符”进行身份验证。在前一种情况下，地址不得与其他形式的允许用户登录名冲突。在后一种情况下，提取的“用户标识符”需要在整个服务器上是唯一的，并且不得与服务器上的任何登录名冲突。
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 服务器必须强制对检索DAV:current user principal属性的“PROPFIND”请求进行身份验证，以确保返回的DAV:current user principal属性的值对应于发出请求的用户的主体URL。
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 Section 6 of [RFC6125] 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 Section 8.
o 如果服务提供商使用TLS，则服务提供商必须确保安装了可由客户使用[RFC6125]第6节所述程序验证的证书，该程序以SRV RR为起点进行验证。具体而言，证书应包括SRV-ID和DNS-ID标识符（视情况而定），如第8节所述。
o Service providers should install the appropriate SRV records for the offered services and optionally include TXT records.
o 服务提供商应为提供的服务安装适当的SRV记录，并可选择包括TXT记录。
Clients that support TLS as defined by [RFC2818] 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 [RFC6125].
支持[RFC2818]定义的TLS的客户端应先尝试“\u caldav”或“\u carddav”服务，然后再分别尝试“\u caldav”或“\u carddav”服务。如果用户明确请求与TLS连接，则客户端不得使用为“_caldav”或“_carddav”服务返回的任何服务信息。客户端必须遵循[RFC6125]中指定的证书验证过程。
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 Section 6 of [RFC6125] 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.
具有DNS服务器数据访问权限的恶意攻击者，或能够获取缓存在递归解析程序中的伪造答案的恶意攻击者，可能会导致客户端连接到攻击者选择的任何服务器。在缺少安全DNS选项的情况下，客户端应检查SRV记录中返回的目标FQDN是否与查询的原始服务域匹配。如果目标FQDN不在查询的域中，则客户端应在执行到主机的任何连接之前，与用户验证SRV目标FQDN是否适合使用。或者，如果TLS用于服务，客户必须使用[RFC6125]第6节中概述的程序来验证服务。当目标FQDN与查询的原始服务域不匹配时，客户端必须检查服务器证书中的SRV-ID标识符。如果FQDN不匹配，则客户端必须检查服务器证书中的任何SRV-ID标识符，或者，如果不存在SRV-ID标识符，则必须检查服务器证书中的DNS-ID标识符。
Implementations of TLS [RFC5246], used as the basis for TLS ([RFC2818]), 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 Appendix E.2 of [RFC5246] for further details.
用作TLS（[RFC2818]）基础的TLS[RFC5246]的实现通常支持协议的多个版本以及较旧的SSL（安全套接字层）协议。由于已知的安全漏洞，客户端和服务器不得请求、提供或使用SSL 2.0。有关更多详细信息，请参见[RFC5246]的附录E.2。
This document defines two ".well-known" URIs using the registration procedure and template from Section 5.1 of [RFC5785].
本文件使用[RFC5785]第5.1节中的注册程序和模板定义了两个“.众所周知”的URI。
URI suffix: caldav
URI后缀：caldav
Change controller: IETF
更改控制器：IETF
Specification document(s): This RFC
规范文件：本RFC
Related information: See also [RFC4791].
相关信息：另请参见[RFC4791]。
URI suffix: carddav
URI后缀：carddav
Change controller: IETF
更改控制器：IETF
Specification document(s): This RFC
规范文件：本RFC
Related information: See also [RFC6352].
相关信息：另见[RFC6352]。
This document registers four new service names as per [RFC6335]. Two are defined in this document, and two are defined in [RFC6352], Section 11.
本文件根据[RFC6335]注册了四个新的服务名称。两个在本文件中定义，两个在[RFC6352]第11节中定义。
Service Name: caldav
服务名称：caldav
Transport Protocol(s): TCP
传输协议：TCP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Calendaring Extensions to WebDAV (CalDAV) - non-TLS
描述：WebDAV（CalDAV）的日历扩展-非TLS
Reference: [RFC6764]
参考文献：[RFC6764]
Assignment Note: This is an extension of the http service. Defined
TXT keys: path=<context path>
Assignment Note: This is an extension of the http service. Defined
TXT keys: path=<context path>
Service Name: caldavs
服务名称：caldavs
Transport Protocol(s): TCP
传输协议：TCP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Calendaring Extensions to WebDAV (CalDAV) - over TLS
描述：WebDAV（CalDAV）的日历扩展-通过TLS
Reference: [RFC6764]
参考文献：[RFC6764]
Assignment Note: This is an extension of the https service. Defined
TXT keys: path=<context path>
Assignment Note: This is an extension of the https service. Defined
TXT keys: path=<context path>
Service Name: carddav
服务名称：carddav
Transport Protocol(s): TCP
传输协议：TCP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: vCard Extensions to WebDAV (CardDAV) - non-TLS
描述：WebDAV（CardDAV）的vCard扩展-非TLS
Reference: [RFC6352]
参考文献：[RFC6352]
Assignment Note: This is an extension of the http service. Defined
TXT keys: path=<context path>
Assignment Note: This is an extension of the http service. Defined
TXT keys: path=<context path>
Service Name: carddavs
服务名称：carddavs
Transport Protocol(s): TCP
传输协议：TCP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: vCard Extensions to WebDAV (CardDAV) - over TLS
描述：WebDAV（CardDAV）的vCard扩展-通过TLS
Reference: [RFC6352]
参考文献：[RFC6352]
Assignment Note: This is an extension of the https service. Defined
TXT keys: path=<context path>
Assignment Note: This is an extension of the https service. Defined
TXT keys: path=<context path>
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.
本规范是由日历和日程安排联盟的CalDAV技术委员会讨论提出的。作者感谢以下人士的贡献：斯图尔特·切希尔、伯纳德·德斯鲁索、埃兰·哈默·拉哈夫、赫尔格·赫斯、阿诺·基劳德、威尔弗雷多·桑切斯和乔·图奇。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744]Clemm，G.，Reschke，J.，Sedlar，E.，和J.Whitehead，“Web分布式创作和版本控制（WebDAV）访问控制协议”，RFC 3744，2004年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
[RFC4791]Daboo，C.，Desruisseaux，B.，和L.Dusseault，“WebDAV（CalDAV）的日历扩展”，RFC 47912007年3月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，“用于Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal Extension", RFC 5397, December 2008.
[RFC5397]Sanchez，W.和C.Daboo，“WebDAV当前主要扩展”，RFC 53972008年12月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，2010年4月。
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[RFC6068]Duerst，M.，Masinter，L.，和J.Zawinski，“mailto”URI方案”，RFC 6068，2010年10月。
[RFC6125] 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)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6335] 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", BCP 165, RFC 6335, August 2011.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, August 2011.
[RFC6352]Daboo，C.，“CardDAV:Web分布式创作和版本控制（WebDAV）的vCard扩展”，RFC 63522011年8月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[RFC5545]Desruisseaux，B.“互联网日历和调度核心对象规范（iCalendar）”，RFC 55452009年9月。
Author's Address
作者地址
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Cyrus Daboo苹果公司，美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
EMail: cyrus@daboo.name
URI: http://www.apple.com/
EMail: cyrus@daboo.name
URI: http://www.apple.com/