[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