doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc6764.txt b/doc/rfc/rfc6764.txt
new file mode 100644
index 0000000..aed17a8
--- /dev/null
+++ b/doc/rfc/rfc6764.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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)
+
+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 Section 2 of RFC 5741.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Daboo                        Standards Track                    [Page 1]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+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
+
+   [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.
+
+   [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.
+
+   [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].
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 2]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   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].
+
+   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
+   [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.
+
+2.  Conventions Used in This Document
+
+   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].
+
+3.  CalDAV SRV Service Labels
+
+   This specification adds two SRV service labels for use with CalDAV:
+
+   _caldav:   Identifies a CalDAV server that uses HTTP without
+      Transport Layer Security (TLS) [RFC2818].
+
+   _caldavs:  Identifies a CalDAV server that uses HTTP with TLS
+      [RFC2818].
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 3]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   Clients MUST honor Priority and Weight values in the SRV RRs, as
+   described by [RFC2782].
+
+   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.
+
+4.  CalDAV and CardDAV Service TXT Records
+
+   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.
+
+   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
+
+5.  CalDAV and CardDAV Service Well-Known URI
+
+   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].
+
+   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
+
+
+
+
+Daboo                        Standards Track                    [Page 4]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   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).
+
+5.1.  Example: Well-Known URI Redirects to Actual "Context Path"
+
+   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.
+
+6.  Client "Bootstrapping" Procedures
+
+   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].
+
+   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 [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.
+
+          +  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.
+
+          +  If the calendar user address is an "http:" [RFC2616] or
+             "https:" [RFC2818] URI, the "userinfo" and "host" portion
+             of the URI [RFC3986] is extracted.
+
+
+
+
+Daboo                        Standards Track                    [Page 5]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+       *  For a CardDAV server:
+
+          +  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.
+
+   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 [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.
+
+   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.
+
+
+
+
+Daboo                        Standards Track                    [Page 6]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   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 Section 7.  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 Section 6 of [RFC6125] in regard to
+          verification with an SRV RR as the starting point.
+
+       *  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.
+
+       *  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).
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 7]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+       *  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.
+
+7.  Guidance for Service Providers
+
+   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 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  Service providers should install the appropriate SRV records for
+      the offered services and optionally include TXT records.
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 8]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+8.  Security Considerations
+
+   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].
+
+   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.
+
+   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.
+
+9.  IANA Considerations
+
+9.1.  Well-Known URI Registrations
+
+   This document defines two ".well-known" URIs using the registration
+   procedure and template from Section 5.1 of [RFC5785].
+
+
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 9]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+9.1.1.  caldav Well-Known URI Registration
+
+   URI suffix:  caldav
+
+   Change controller:  IETF
+
+   Specification document(s):  This RFC
+
+   Related information:  See also [RFC4791].
+
+9.1.2.  carddav Well-Known URI Registration
+
+   URI suffix:  carddav
+
+   Change controller:  IETF
+
+   Specification document(s):  This RFC
+
+   Related information:  See also [RFC6352].
+
+9.2.  Service Name Registrations
+
+   This document registers four new service names as per [RFC6335].  Two
+   are defined in this document, and two are defined in [RFC6352],
+   Section 11.
+
+9.2.1.  caldav Service Name Registration
+
+   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:  [RFC6764]
+
+   Assignment Note:  This is an extension of the http service.  Defined
+      TXT keys: path=<context path>
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                   [Page 10]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+9.2.2.  caldavs Service Name Registration
+
+   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:  [RFC6764]
+
+   Assignment Note:  This is an extension of the https service.  Defined
+      TXT keys: path=<context path>
+
+9.2.3.  carddav Service Name Registration
+
+   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:  [RFC6352]
+
+   Assignment Note:  This is an extension of the http service.  Defined
+      TXT keys: path=<context path>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                   [Page 11]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+9.2.4.  carddavs Service Name Registration
+
+   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:  [RFC6352]
+
+   Assignment Note:  This is an extension of the https service.  Defined
+      TXT keys: path=<context path>
+
+10.  Acknowledgments
+
+   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.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [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.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+
+
+
+
+Daboo                        Standards Track                   [Page 12]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+              Distributed Authoring and Versioning (WebDAV)
+              Access Control Protocol", RFC 3744, May 2004.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
+              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+              March 2007.
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [RFC5397]  Sanchez, W. and C. Daboo, "WebDAV Current Principal
+              Extension", RFC 5397, December 2008.
+
+   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+              Uniform Resource Identifiers (URIs)", RFC 5785,
+              April 2010.
+
+   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
+              URI Scheme", RFC 6068, October 2010.
+
+   [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.
+
+   [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.
+
+   [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 6352, August 2011.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, February 2013.
+
+
+
+Daboo                        Standards Track                   [Page 13]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+11.2.  Informative References
+
+   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
+              Core Object Specification (iCalendar)", RFC 5545,
+              September 2009.
+
+Author's Address
+
+   Cyrus Daboo
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   EMail: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                   [Page 14]
+