[CalendarServer-changes] [10899] CalendarServer/branches/users/sagen/testing
source_changes at macosforge.org
source_changes at macosforge.org
Tue Mar 12 14:58:23 PDT 2013
Revision: 10899
http://trac.calendarserver.org//changeset/10899
Author: sagen at apple.com
Date: 2013-03-12 14:58:23 -0700 (Tue, 12 Mar 2013)
Log Message:
-----------
Pull up changes from trunk
Modified Paths:
--------------
CalendarServer/branches/users/sagen/testing/conf/auth/resources-test.xml
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/calendaruserproxy.py
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts-modified.xml
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts.xml
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/augments.xml
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/proxies.xml
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_directory.py
CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_proxyprincipalmembers.py
Added Paths:
-----------
CalendarServer/branches/users/sagen/testing/doc/RFC/RFC6764-srv-CalDAV.txt
Removed Paths:
-------------
CalendarServer/branches/users/sagen/testing/doc/RFC/draft-daboo-srv-caldav.txt
Property Changed:
----------------
CalendarServer/branches/users/sagen/testing/
Property changes on: CalendarServer/branches/users/sagen/testing
___________________________________________________________________
Modified: svn:mergeinfo
- /CalendarServer/branches/config-separation:4379-4443
/CalendarServer/branches/egg-info-351:4589-4625
/CalendarServer/branches/generic-sqlstore:6167-6191
/CalendarServer/branches/new-store:5594-5934
/CalendarServer/branches/new-store-no-caldavfile:5911-5935
/CalendarServer/branches/new-store-no-caldavfile-2:5936-5981
/CalendarServer/branches/release/CalendarServer-4.3-dev:10180-10190,10192
/CalendarServer/branches/users/cdaboo/batchupload-6699:6700-7198
/CalendarServer/branches/users/cdaboo/cached-subscription-calendars-5692:5693-5702
/CalendarServer/branches/users/cdaboo/component-set-fixes:8130-8346
/CalendarServer/branches/users/cdaboo/directory-cache-on-demand-3627:3628-3644
/CalendarServer/branches/users/cdaboo/implicituidrace:8137-8141
/CalendarServer/branches/users/cdaboo/ischedule-dkim:9747-9979
/CalendarServer/branches/users/cdaboo/managed-attachments:9985-10145
/CalendarServer/branches/users/cdaboo/more-sharing-5591:5592-5601
/CalendarServer/branches/users/cdaboo/partition-4464:4465-4957
/CalendarServer/branches/users/cdaboo/pods:7297-7377
/CalendarServer/branches/users/cdaboo/pycalendar:7085-7206
/CalendarServer/branches/users/cdaboo/pycard:7227-7237
/CalendarServer/branches/users/cdaboo/queued-attendee-refreshes:7740-8287
/CalendarServer/branches/users/cdaboo/relative-config-paths-5070:5071-5105
/CalendarServer/branches/users/cdaboo/shared-calendars-5187:5188-5440
/CalendarServer/branches/users/cdaboo/timezones:7443-7699
/CalendarServer/branches/users/cdaboo/txn-debugging:8730-8743
/CalendarServer/branches/users/glyph/always-abort-txn-on-error:9958-9969
/CalendarServer/branches/users/glyph/case-insensitive-uid:8772-8805
/CalendarServer/branches/users/glyph/conn-limit:6574-6577
/CalendarServer/branches/users/glyph/contacts-server-merge:4971-5080
/CalendarServer/branches/users/glyph/dalify:6932-7023
/CalendarServer/branches/users/glyph/db-reconnect:6824-6876
/CalendarServer/branches/users/glyph/deploybuild:7563-7572
/CalendarServer/branches/users/glyph/digest-auth-redux:10624-10635
/CalendarServer/branches/users/glyph/disable-quota:7718-7727
/CalendarServer/branches/users/glyph/dont-start-postgres:6592-6614
/CalendarServer/branches/users/glyph/imip-and-admin-html:7866-7984
/CalendarServer/branches/users/glyph/ipv6-client:9054-9105
/CalendarServer/branches/users/glyph/linux-tests:6893-6900
/CalendarServer/branches/users/glyph/migrate-merge:8690-8713
/CalendarServer/branches/users/glyph/misc-portability-fixes:7365-7374
/CalendarServer/branches/users/glyph/more-deferreds-6:6322-6368
/CalendarServer/branches/users/glyph/more-deferreds-7:6369-6445
/CalendarServer/branches/users/glyph/multiget-delete:8321-8330
/CalendarServer/branches/users/glyph/new-export:7444-7485
/CalendarServer/branches/users/glyph/one-home-list-api:10048-10073
/CalendarServer/branches/users/glyph/oracle:7106-7155
/CalendarServer/branches/users/glyph/oracle-nulls:7340-7351
/CalendarServer/branches/users/glyph/other-html:8062-8091
/CalendarServer/branches/users/glyph/parallel-sim:8240-8251
/CalendarServer/branches/users/glyph/parallel-upgrade:8376-8400
/CalendarServer/branches/users/glyph/parallel-upgrade_to_1:8571-8583
/CalendarServer/branches/users/glyph/q:9560-9688
/CalendarServer/branches/users/glyph/queue-locking-and-timing:10204-10289
/CalendarServer/branches/users/glyph/quota:7604-7637
/CalendarServer/branches/users/glyph/sendfdport:5388-5424
/CalendarServer/branches/users/glyph/shared-pool-fixes:8436-8443
/CalendarServer/branches/users/glyph/shared-pool-take2:8155-8174
/CalendarServer/branches/users/glyph/sharedpool:6490-6550
/CalendarServer/branches/users/glyph/sharing-api:9192-9205
/CalendarServer/branches/users/glyph/skip-lonely-vtimezones:8524-8535
/CalendarServer/branches/users/glyph/sql-store:5929-6073
/CalendarServer/branches/users/glyph/subtransactions:7248-7258
/CalendarServer/branches/users/glyph/table-alias:8651-8664
/CalendarServer/branches/users/glyph/uidexport:7673-7676
/CalendarServer/branches/users/glyph/unshare-when-access-revoked:10562-10595
/CalendarServer/branches/users/glyph/use-system-twisted:5084-5149
/CalendarServer/branches/users/glyph/uuid-normalize:9268-9296
/CalendarServer/branches/users/glyph/xattrs-from-files:7757-7769
/CalendarServer/branches/users/sagen/applepush:8126-8184
/CalendarServer/branches/users/sagen/inboxitems:7380-7381
/CalendarServer/branches/users/sagen/locations-resources:5032-5051
/CalendarServer/branches/users/sagen/locations-resources-2:5052-5061
/CalendarServer/branches/users/sagen/purge_old_events:6735-6746
/CalendarServer/branches/users/sagen/resource-delegates-4038:4040-4067
/CalendarServer/branches/users/sagen/resource-delegates-4066:4068-4075
/CalendarServer/branches/users/sagen/resources-2:5084-5093
/CalendarServer/branches/users/sagen/testing:10827-10851,10853-10855
/CalendarServer/branches/users/wsanchez/transations:5515-5593
/CalendarServer/trunk:10857-10878
+ /CalendarServer/branches/config-separation:4379-4443
/CalendarServer/branches/egg-info-351:4589-4625
/CalendarServer/branches/generic-sqlstore:6167-6191
/CalendarServer/branches/new-store:5594-5934
/CalendarServer/branches/new-store-no-caldavfile:5911-5935
/CalendarServer/branches/new-store-no-caldavfile-2:5936-5981
/CalendarServer/branches/release/CalendarServer-4.3-dev:10180-10190,10192
/CalendarServer/branches/users/cdaboo/batchupload-6699:6700-7198
/CalendarServer/branches/users/cdaboo/cached-subscription-calendars-5692:5693-5702
/CalendarServer/branches/users/cdaboo/component-set-fixes:8130-8346
/CalendarServer/branches/users/cdaboo/directory-cache-on-demand-3627:3628-3644
/CalendarServer/branches/users/cdaboo/implicituidrace:8137-8141
/CalendarServer/branches/users/cdaboo/ischedule-dkim:9747-9979
/CalendarServer/branches/users/cdaboo/managed-attachments:9985-10145
/CalendarServer/branches/users/cdaboo/more-sharing-5591:5592-5601
/CalendarServer/branches/users/cdaboo/partition-4464:4465-4957
/CalendarServer/branches/users/cdaboo/pods:7297-7377
/CalendarServer/branches/users/cdaboo/pycalendar:7085-7206
/CalendarServer/branches/users/cdaboo/pycard:7227-7237
/CalendarServer/branches/users/cdaboo/queued-attendee-refreshes:7740-8287
/CalendarServer/branches/users/cdaboo/relative-config-paths-5070:5071-5105
/CalendarServer/branches/users/cdaboo/shared-calendars-5187:5188-5440
/CalendarServer/branches/users/cdaboo/timezones:7443-7699
/CalendarServer/branches/users/cdaboo/txn-debugging:8730-8743
/CalendarServer/branches/users/glyph/always-abort-txn-on-error:9958-9969
/CalendarServer/branches/users/glyph/case-insensitive-uid:8772-8805
/CalendarServer/branches/users/glyph/conn-limit:6574-6577
/CalendarServer/branches/users/glyph/contacts-server-merge:4971-5080
/CalendarServer/branches/users/glyph/dalify:6932-7023
/CalendarServer/branches/users/glyph/db-reconnect:6824-6876
/CalendarServer/branches/users/glyph/deploybuild:7563-7572
/CalendarServer/branches/users/glyph/digest-auth-redux:10624-10635
/CalendarServer/branches/users/glyph/disable-quota:7718-7727
/CalendarServer/branches/users/glyph/dont-start-postgres:6592-6614
/CalendarServer/branches/users/glyph/imip-and-admin-html:7866-7984
/CalendarServer/branches/users/glyph/ipv6-client:9054-9105
/CalendarServer/branches/users/glyph/linux-tests:6893-6900
/CalendarServer/branches/users/glyph/migrate-merge:8690-8713
/CalendarServer/branches/users/glyph/misc-portability-fixes:7365-7374
/CalendarServer/branches/users/glyph/more-deferreds-6:6322-6368
/CalendarServer/branches/users/glyph/more-deferreds-7:6369-6445
/CalendarServer/branches/users/glyph/multiget-delete:8321-8330
/CalendarServer/branches/users/glyph/new-export:7444-7485
/CalendarServer/branches/users/glyph/one-home-list-api:10048-10073
/CalendarServer/branches/users/glyph/oracle:7106-7155
/CalendarServer/branches/users/glyph/oracle-nulls:7340-7351
/CalendarServer/branches/users/glyph/other-html:8062-8091
/CalendarServer/branches/users/glyph/parallel-sim:8240-8251
/CalendarServer/branches/users/glyph/parallel-upgrade:8376-8400
/CalendarServer/branches/users/glyph/parallel-upgrade_to_1:8571-8583
/CalendarServer/branches/users/glyph/q:9560-9688
/CalendarServer/branches/users/glyph/queue-locking-and-timing:10204-10289
/CalendarServer/branches/users/glyph/quota:7604-7637
/CalendarServer/branches/users/glyph/sendfdport:5388-5424
/CalendarServer/branches/users/glyph/shared-pool-fixes:8436-8443
/CalendarServer/branches/users/glyph/shared-pool-take2:8155-8174
/CalendarServer/branches/users/glyph/sharedpool:6490-6550
/CalendarServer/branches/users/glyph/sharing-api:9192-9205
/CalendarServer/branches/users/glyph/skip-lonely-vtimezones:8524-8535
/CalendarServer/branches/users/glyph/sql-store:5929-6073
/CalendarServer/branches/users/glyph/subtransactions:7248-7258
/CalendarServer/branches/users/glyph/table-alias:8651-8664
/CalendarServer/branches/users/glyph/uidexport:7673-7676
/CalendarServer/branches/users/glyph/unshare-when-access-revoked:10562-10595
/CalendarServer/branches/users/glyph/use-system-twisted:5084-5149
/CalendarServer/branches/users/glyph/uuid-normalize:9268-9296
/CalendarServer/branches/users/glyph/xattrs-from-files:7757-7769
/CalendarServer/branches/users/sagen/applepush:8126-8184
/CalendarServer/branches/users/sagen/inboxitems:7380-7381
/CalendarServer/branches/users/sagen/locations-resources:5032-5051
/CalendarServer/branches/users/sagen/locations-resources-2:5052-5061
/CalendarServer/branches/users/sagen/purge_old_events:6735-6746
/CalendarServer/branches/users/sagen/resource-delegates-4038:4040-4067
/CalendarServer/branches/users/sagen/resource-delegates-4066:4068-4075
/CalendarServer/branches/users/sagen/resources-2:5084-5093
/CalendarServer/branches/users/sagen/testing:10827-10851,10853-10855
/CalendarServer/branches/users/wsanchez/transations:5515-5593
/CalendarServer/trunk:10857-10898
Modified: CalendarServer/branches/users/sagen/testing/conf/auth/resources-test.xml
===================================================================
--- CalendarServer/branches/users/sagen/testing/conf/auth/resources-test.xml 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/conf/auth/resources-test.xml 2013-03-12 21:58:23 UTC (rev 10899)
@@ -35,7 +35,7 @@
<uid>mercury</uid>
<guid>mercury</guid>
<password>test</password>
- <name>Mecury Conference Room, Building 1, 2nd Floor</name>
+ <name>Mercury Conference Room, Building 1, 2nd Floor</name>
</location>
<location>
<uid>venus</uid>
Copied: CalendarServer/branches/users/sagen/testing/doc/RFC/RFC6764-srv-CalDAV.txt (from rev 10898, CalendarServer/trunk/doc/RFC/RFC6764-srv-CalDAV.txt)
===================================================================
--- CalendarServer/branches/users/sagen/testing/doc/RFC/RFC6764-srv-CalDAV.txt (rev 0)
+++ CalendarServer/branches/users/sagen/testing/doc/RFC/RFC6764-srv-CalDAV.txt 2013-03-12 21:58:23 UTC (rev 10899)
@@ -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 at ietf.org>
+
+ Contact: IETF Chair <chair at 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 at ietf.org>
+
+ Contact: IETF Chair <chair at 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 at ietf.org>
+
+ Contact: IETF Chair <chair at 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 at ietf.org>
+
+ Contact: IETF Chair <chair at 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 at daboo.name
+ URI: http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 14]
+
Deleted: CalendarServer/branches/users/sagen/testing/doc/RFC/draft-daboo-srv-caldav.txt
===================================================================
--- CalendarServer/branches/users/sagen/testing/doc/RFC/draft-daboo-srv-caldav.txt 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/doc/RFC/draft-daboo-srv-caldav.txt 2013-03-12 21:58:23 UTC (rev 10899)
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group C. Daboo
-Internet-Draft Apple Inc.
-Updates: 4791,CardDAV-RFC-to-be September 16, 2010
-(if approved)
-Intended status: Standards Track
-Expires: March 20, 2011
-
-
- Locating CalDAV and CardDAV services
- draft-daboo-srv-caldav-10
-
-Abstract
-
- This specification describes how DNS SRV records, DNS TXT records and
- well-known URIs can be used together or separately to locate
- Calendaring Extensions to WebDAV (CalDAV) or vCard Extensions to
- WebDAV (CardDAV) services.
-
-Status of This Memo
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on March 20, 2011.
-
-Copyright Notice
-
- Copyright (c) 2010 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
-
-
-
-Daboo Expires March 20, 2011 [Page 1]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- described in the Simplified BSD License.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
- 3. CalDAV SRV Service Labels . . . . . . . . . . . . . . . . . . 4
- 4. CalDAV and CardDAV Service TXT Records . . . . . . . . . . . . 4
- 5. CalDAV and CardDAV Service Well-Known URI . . . . . . . . . . 5
- 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. caldav Well-Known URI Registration . . . . . . . . . . . . 10
- 9.2. carddav Well-Known URI Registration . . . . . . . . . . . 10
- 9.3. SRV Service Label Registration . . . . . . . . . . . . . . 10
- 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
- 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
- Appendix A. Change History (to be removed prior to
- publication as an RFC) . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo Expires March 20, 2011 [Page 2]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
-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.
-
- [I-D.ietf-vcarddav-carddav] 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 Resource Records as per
- [I-D.cheshire-dnsext-dns-sd].
-
- 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
- [I-D.ietf-vcarddav-carddav].
-
- 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 a
- 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 make use of. 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.
-
-
-
-
-Daboo Expires March 20, 2011 [Page 3]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
-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 ([RFC2818]).
-
- _caldavs: Identifies a CalDAV server that uses HTTP with transport
- layer security ([RFC2818]).
-
- Clients MUST honor "Priority" and "Weight" values in the SRV RRs, as
- described by [RFC2782].
-
- Example: service record for server without transport layer security
-
- _caldav._tcp SRV 0 1 80 calendar.example.com.
-
- Example: service record for server with transport layer security
-
- _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
- [I-D.cheshire-dnsext-dns-sd] 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 transport layer security
-
- _caldavs._tcp TXT path=/caldav
-
-
-
-
-
-
-Daboo Expires March 20, 2011 [Page 4]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
-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, 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
- location of the redirect might change over time, then a "no-cache"
- value would be used.
-
- To facilitate "context path's" 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 which the client can parse suitable information from. 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].
-
-
-
-
-
-Daboo Expires March 20, 2011 [Page 5]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- 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 "bootstrap" configuration can be done.
-
- + If the calendar user address is a "mailto:" [RFC2368] URI,
- the "mailbox" portion of the URI is examined and the
- "local-part" and "domain" portions 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.
-
- * 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 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-SSL
- connections are appropriate.
-
- * If an SRV record is returned, the client extracts the target
- FQDN and port number. In the case of multiple SRV records
- 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 transport layer security.
-
-
-
-Daboo Expires March 20, 2011 [Page 6]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- 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 bootstrap procedure using the appropriate
- ".well-known" URI instead.
-
- 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 transport layer security negotiation is done
- immediately upon connection. The client MUST do certificate
- verification using the procedure outlined in Section 4 of
- [I-D.saintandre-tls-server-id-check] 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
-
-
-
-Daboo Expires March 20, 2011 [Page 7]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- 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).
-
- * 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 re-
- use those when connecting again at a later time.
-
- If a subsequent connection attempt fails, or authentication fails
- persistently, clients SHOULD re-try 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 "user identifiers" extracted from them. In the
- former case, the addresses MUST NOT conflict with other forms of
- 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
-
-
-
-Daboo Expires March 20, 2011 [Page 8]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- corresponds to the principal-URL of the user making the request.
-
- o If the service provider uses transport layer security, the service
- provider MUST ensure a certificate is installed that can be
- verified by clients using the procedure outlined in Section 4 of
- [I-D.saintandre-tls-server-id-check] in regard to verification
- with an SRV RR as the starting point.
-
- o Install the appropriate SRV records for the offered services.
- Optionally include TXT records.
-
-8. Security Considerations
-
- Clients that support transport layer security 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 transport layer security, the
- client MUST NOT use any service information returned for the
- "_caldav" or "_carddav" services. Clients MUST follow the
- certificate verification process specified in
- [I-D.saintandre-tls-server-id-check].
-
- A malicious attacker with access to the DNS server data, or 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 transport layer security is being used for the
- service, clients MUST use the procedure outlined in Section 4 of
- [I-D.saintandre-tls-server-id-check] to verify the service.
-
- Implementations of TLS [RFC5246], used as the basis for transport
- layer security ([RFC2818]), typically support multiple versions of
- the protocol as well as the older Secure Sockets Layer (SSL)
- 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
-
- This document defines two ".well-known" URIs using the registration
- procedure and template from Section 5.1 of [RFC5785].
-
-
-
-
-
-
-Daboo Expires March 20, 2011 [Page 9]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
-9.1. caldav Well-Known URI Registration
-
- URI suffix: caldav
-
- Change controller: IETF.
-
- Specification document(s): This RFC.
-
- Related information: See also [RFC4791].
-
-9.2. carddav Well-Known URI Registration
-
- URI suffix: carddav
-
- Change controller: IETF.
-
- Specification document(s): This RFC.
-
- Related information: See also [I-D.ietf-vcarddav-carddav].
-
-9.3. SRV Service Label Registration
-
- Service labels have been registered according to
- <http://www.dns-sd.org/ServiceTypes.html> [1] and will be
- incorporated into IANA once a new registry is available there.
-
-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
-
- [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal,
- "DNS-Based Service Discovery",
- draft-cheshire-dnsext-dns-sd-06
- (work in progress), March 2010.
-
- [I-D.ietf-vcarddav-carddav] Daboo, C., "vCard Extensions to
- WebDAV (CardDAV)",
- draft-ietf-vcarddav-carddav-10
- (work in progress),
- November 2009.
-
-
-
-Daboo Expires March 20, 2011 [Page 10]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- [I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges,
- "Representation and
- Verification of Domain-Based
- Application Service Identity in
- Certificates Used with
- Transport Layer Security", draf
- t-saintandre-tls-server-id-
- check-09 (work in progress),
- August 2010.
-
- [RFC2119] Bradner, S., "Key words for use
- in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119,
- March 1997.
-
- [RFC2368] Hoffman, P., Masinter, L., and
- J. Zawinski, "The mailto URL
- scheme", RFC 2368, July 1998.
-
- [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.
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar,
- E., and J. Whitehead, "Web
- Distributed Authoring and
- Versioning (WebDAV)
- Access Control Protocol",
-
-
-
-Daboo Expires March 20, 2011 [Page 11]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- 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.
-
-11.2. Informative References
-
- [RFC5545] Desruisseaux, B., "Internet
- Calendaring and Scheduling Core
- Object Specification
- (iCalendar)", RFC 5545,
- September 2009.
-
-URIs
-
- [1] <http://www.dns-sd.org/ServiceTypes.html>
-
-
-
-Daboo Expires March 20, 2011 [Page 12]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
-Appendix A. Change History (to be removed prior to publication as an
- RFC)
-
- Changes in -09:
-
- 1. IESG Review: minor editorial changes.
-
- 2. GenART Review: minor editorial changes.
-
- 3. GenART Review: "guideline" -> "procedure".
-
- 4. GenART Review: "port" -> "port number".
-
- 5. GenART Review: added definition of "context path".
-
- 6. GenART Review: clarified OPTIONAL nature of suggested client
- procedure.
-
- 7. GenART Review: clarified that TXT lookup is an additional query.
-
- 8. IESG Review: now allow any HTTP redirect response, not just 301.
-
- 9. IESG Review: added text on cache interaction with redirect.
-
- Changes in -10:
-
- 1. AD Review: make client procedure a SHOULD.
-
- Changes in -08:
-
- 1. Clarify that email address is a valid input in Section 7 for
- CardDAV.
-
- 2. Clarified aspects of DAV:current-user-principal handling for
- servers.
-
- 3. Added additional text to indicate TXT being used in abstract and
- introduction.
-
- Changes in -07:
-
- 1. Add password to required minimal user input
-
- 2. Section 3 -> Section 4 of server-id check draft.
-
- Changes in -06:
-
-
-
-
-
-Daboo Expires March 20, 2011 [Page 13]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- 1. Last call comments: Revised title, abstract and text to indicate
- that SRV and .well-known can be done separately.
-
- 2. Revised IANA section to use dns-sd registry for now.
-
- 3. Added optional TXT RR with path key for service context path in
- the DNS
-
- 4. Re-organized client bootstrap to take account of TXT and to call-
- out the different "phases" involved via a numbered list.
-
- Changes in -05:
-
- 1. AD Review: Added "Updates" for 4791 and CardDAV.
-
- 2. AD Review: Changed SHOULD to MUST for honoring priority and
- weight.
-
- 3. AD Review: Added additional reference to 3986 when talking about
- userinfo/host portions of the URI.
-
- 4. AD Review: Changed section reference for tls-server-id-check
- draft.
-
- 5. AD Review: Changed should to SHOULD when describing PROPFIND
- request and made 5397 normative.
-
- 6. AD Review: Made 3744 and 5322 normative references.
-
- 7. AD Review: Added IANA SRV registration request.
-
- Changes in -04:
-
- 1. Added addition text to client guidelines indicating that clients
- cache the discovery details and can re-do discovery if
- connections later fail.
-
- 2. Changed principal-URI to principal-URL.
-
- Changes in -03:
-
- 1. Updated to RFC 5785 reference.
-
- 2. Added SSL v2 restriction from srv-email document added after IESG
- review.
-
- 3. Tweaked client/server guidelines to better match HTTP challenge/
- response authentication mechanism.
-
-
-
-Daboo Expires March 20, 2011 [Page 14]
-
-Internet-Draft SRV for CalDAV & CardDAV September 2010
-
-
- Changes in -02:
-
- 1. Re-organized introduction.
-
- 2. Brought terminology into line with srv-email document which has
- been through last call.
-
- 3. Brought security section into line with srv-email document which
- has been through last call.
-
- Changes in -01:
-
- 1. Added discovery of CardDAV service.
-
- 2. Now makes use of well-known URIs for the service "context path".
-
- 3. Updated to RFC 5545 reference.
-
- 4. Added reference to certificate verification spec.
-
-Author's Address
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- EMail: cyrus at daboo.name
- URI: http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo Expires March 20, 2011 [Page 15]
-
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/calendaruserproxy.py
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/calendaruserproxy.py 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/calendaruserproxy.py 2013-03-12 21:58:23 UTC (rev 10899)
@@ -375,7 +375,9 @@
p = self.pcollection.principalForUID(uid)
if p:
# Only principals enabledForLogin can be a delegate
- if p.record.enabledForLogin:
+ # (and groups as well)
+ if (p.record.enabledForLogin or
+ p.record.recordType == p.record.service.recordType_groups):
found.append(p)
# Make sure any outstanding deletion timer entries for
# existing principals are removed
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts-modified.xml
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts-modified.xml 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts-modified.xml 2013-03-12 21:58:23 UTC (rev 10899)
@@ -115,6 +115,35 @@
<name>佐藤佐藤佐藤</name>
<email-address>nonascii at example.com</email-address>
</user>
+ <user>
+ <uid>delegator</uid>
+ <guid>FC465590-E9E9-4746-ACE8-6C756A49FE4D</guid>
+ <password>a</password>
+ <name>Calendar Delegator</name>
+ <email-address>calendardelegator at example.com</email-address>
+ </user>
+ <user>
+ <uid>occasionaldelegate</uid>
+ <guid>EC465590-E9E9-4746-ACE8-6C756A49FE4D</guid>
+ <password>a</password>
+ <name>Occasional Delegate</name>
+ <email-address>occasional at example.com</email-address>
+ </user>
+ <user>
+ <uid>delegateviagroup</uid>
+ <guid>46D9D716-CBEE-490F-907A-66FA6C3767FF</guid>
+ <password>a</password>
+ <name>Delegate Via Group</name>
+ <email-address>delegateviagroup at example.com</email-address>
+ </user>
+ <group>
+ <uid>delegategroup</uid>
+ <guid>00599DAF-3E75-42DD-9DB7-52617E79943F</guid>
+ <name>Delegate Group</name>
+ <members>
+ <member type="users">delegateviagroup</member>
+ </members>
+ </group>
<user repeat="2">
<uid>user%02d</uid>
<guid>user%02d</guid>
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts.xml
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts.xml 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/accounts.xml 2013-03-12 21:58:23 UTC (rev 10899)
@@ -124,6 +124,21 @@
<name>Occasional Delegate</name>
<email-address>occasional at example.com</email-address>
</user>
+ <user>
+ <uid>delegateviagroup</uid>
+ <guid>46D9D716-CBEE-490F-907A-66FA6C3767FF</guid>
+ <password>a</password>
+ <name>Delegate Via Group</name>
+ <email-address>delegateviagroup at example.com</email-address>
+ </user>
+ <group>
+ <uid>delegategroup</uid>
+ <guid>00599DAF-3E75-42DD-9DB7-52617E79943F</guid>
+ <name>Delegate Group</name>
+ <members>
+ <member type="users">delegateviagroup</member>
+ </members>
+ </group>
<user repeat="2">
<uid>user%02d</uid>
<guid>user%02d</guid>
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/augments.xml
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/augments.xml 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/augments.xml 2013-03-12 21:58:23 UTC (rev 10899)
@@ -186,4 +186,10 @@
<enable-calendar>true</enable-calendar>
<enable-login>true</enable-login>
</record>
+ <record>
+ <uid>00599DAF-3E75-42DD-9DB7-52617E79943F</uid>
+ <enable>true</enable>
+ <enable-calendar>false</enable-calendar>
+ <enable-login>false</enable-login>
+ </record>
</augments>
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/proxies.xml
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/proxies.xml 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/proxies.xml 2013-03-12 21:58:23 UTC (rev 10899)
@@ -63,6 +63,7 @@
<guid>FC465590-E9E9-4746-ACE8-6C756A49FE4D</guid>
<proxies>
<member>EC465590-E9E9-4746-ACE8-6C756A49FE4D</member>
+ <member>00599DAF-3E75-42DD-9DB7-52617E79943F</member>
</proxies>
</record>
</proxies>
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_directory.py
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_directory.py 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_directory.py 2013-03-12 21:58:23 UTC (rev 10899)
@@ -180,6 +180,8 @@
self.assertEquals(
groups,
{
+ '00599DAF-3E75-42DD-9DB7-52617E79943F':
+ set(['46D9D716-CBEE-490F-907A-66FA6C3767FF']),
'9FF60DAD-0BDE-4508-8C77-15F0CA5C8DD1':
set(['8B4288F6-CC82-491D-8EF9-642EF4F3E7D0']),
'admin':
@@ -210,6 +212,8 @@
self.assertEquals(
aliases,
{
+ '00599DAF-3E75-42DD-9DB7-52617E79943F':
+ '00599DAF-3E75-42DD-9DB7-52617E79943F',
'9FF60DAD-0BDE-4508-8C77-15F0CA5C8DD1':
'9FF60DAD-0BDE-4508-8C77-15F0CA5C8DD1',
'admin': 'admin',
@@ -235,7 +239,7 @@
)
)
- self.assertEquals((False, 8, 8), (yield updater.updateCache()))
+ self.assertEquals((False, 9, 9), (yield updater.updateCache()))
# Verify cache is populated:
self.assertTrue((yield cache.isPopulated()))
@@ -331,7 +335,7 @@
# that wsanchez is only a proxy for gemini (since that assignment does not involve groups)
self.directoryService.xmlFile = dirTest.child("accounts-modified.xml")
self.directoryService._alwaysStat = True
- self.assertEquals((False, 7, 1), (yield updater.updateCache()))
+ self.assertEquals((False, 8, 1), (yield updater.updateCache()))
delegate = self._getPrincipalByShortName(DirectoryService.recordType_users, "wsanchez")
proxyFor = (yield delegate.proxyFor(True))
self.assertEquals(
@@ -634,8 +638,8 @@
self.assertFalse((yield cache.isPopulated()))
fast, numMembers, numChanged = (yield updater.updateCache(fast=True))
self.assertEquals(fast, False)
- self.assertEquals(numMembers, 8)
- self.assertEquals(numChanged, 8)
+ self.assertEquals(numMembers, 9)
+ self.assertEquals(numChanged, 9)
self.assertTrue(snapshotFile.exists())
self.assertTrue((yield cache.isPopulated()))
@@ -651,7 +655,7 @@
# Try an update which faults in from the directory (fast=False)
fast, numMembers, numChanged = (yield updater.updateCache(fast=False))
self.assertEquals(fast, False)
- self.assertEquals(numMembers, 8)
+ self.assertEquals(numMembers, 9)
self.assertEquals(numChanged, 0)
# Verify the snapshot contains the pickled dictionary we expect
@@ -659,6 +663,10 @@
self.assertEquals(
members,
{
+ "46D9D716-CBEE-490F-907A-66FA6C3767FF":
+ set([
+ u"00599DAF-3E75-42DD-9DB7-52617E79943F",
+ ]),
"5A985493-EE2C-4665-94CF-4DFEA3A89500":
set([
u"non_calendar_group",
Modified: CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_proxyprincipalmembers.py
===================================================================
--- CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_proxyprincipalmembers.py 2013-03-12 17:47:59 UTC (rev 10898)
+++ CalendarServer/branches/users/sagen/testing/twistedcaldav/directory/test/test_proxyprincipalmembers.py 2013-03-12 21:58:23 UTC (rev 10899)
@@ -462,7 +462,17 @@
"""
self.assertEquals(
set((yield calendaruserproxy.ProxyDBService.getAllMembers())), #@UndefinedVariable
- set([u'6423F94A-6B76-4A3A-815B-D52CFD77935D', u'8A985493-EE2C-4665-94CF-4DFEA3A89500', u'9FF60DAD-0BDE-4508-8C77-15F0CA5C8DD2', u'both_coasts', u'left_coast', u'non_calendar_group', u'recursive1_coasts', u'recursive2_coasts', u'EC465590-E9E9-4746-ACE8-6C756A49FE4D'])
+ set([
+ u'00599DAF-3E75-42DD-9DB7-52617E79943F',
+ u'6423F94A-6B76-4A3A-815B-D52CFD77935D',
+ u'8A985493-EE2C-4665-94CF-4DFEA3A89500',
+ u'9FF60DAD-0BDE-4508-8C77-15F0CA5C8DD2',
+ u'both_coasts',
+ u'left_coast',
+ u'non_calendar_group',
+ u'recursive1_coasts',
+ u'recursive2_coasts',
+ u'EC465590-E9E9-4746-ACE8-6C756A49FE4D'])
)
@@ -470,6 +480,7 @@
def test_hideDisabledDelegates(self):
"""
Delegates who are not enabledForLogin are "hidden" from the delegate lists
+ (but groups *are* allowed)
"""
record = self.directoryService.recordWithGUID("EC465590-E9E9-4746-ACE8-6C756A49FE4D")
@@ -477,19 +488,19 @@
record.enabledForLogin = True
yield self._groupMembersTest(
DirectoryService.recordType_users, "delegator", "calendar-proxy-write",
- ("Occasional Delegate",),
+ ("Occasional Delegate", "Delegate Via Group", "Delegate Group"),
)
# Login disabled -- no longer shown as a delegate
record.enabledForLogin = False
yield self._groupMembersTest(
DirectoryService.recordType_users, "delegator", "calendar-proxy-write",
- [],
+ ("Delegate Via Group", "Delegate Group"),
)
# Login re-enabled -- once again a delegate (it wasn't not removed from proxydb)
record.enabledForLogin = True
yield self._groupMembersTest(
DirectoryService.recordType_users, "delegator", "calendar-proxy-write",
- ("Occasional Delegate",),
+ ("Occasional Delegate", "Delegate Via Group", "Delegate Group"),
)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20130312/e59ed118/attachment-0001.html>
More information about the calendarserver-changes
mailing list