CalDAV/CardDAV service discovery with SRV/TXT records

* Structural changes in the strings file (for translations)

doc/rfc5785-well-known-uris.txt

@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     M. Nottingham
+Request for Comments: 5785                               E. Hammer-Lahav
+Updates: 2616, 2818                                           April 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+        Defining Well-Known Uniform Resource Identifiers (URIs)
+
+Abstract
+
+   This memo defines a path prefix for "well-known locations",
+   "/.well-known/", in selected Uniform Resource Identifier (URI)
+   schemes.
+
+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/rfc5785.
+
+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
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 1]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+     1.1.  Appropriate Use of Well-Known URIs  . . . . . . . . . . . . 3
+   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
+   3.  Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+     5.1.  The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
+       5.1.1.  Registration Template . . . . . . . . . . . . . . . . . 5
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7
+   Appendix B.  Frequently Asked Questions . . . . . . . . . . . . . . 7
+
+1.  Introduction
+
+   It is increasingly common for Web-based protocols to require the
+   discovery of policy or other information about a host ("site-wide
+   metadata") before making a request.  For example, the Robots
+   Exclusion Protocol <http://www.robotstxt.org/> specifies a way for
+   automated processes to obtain permission to access resources;
+   likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]
+   tells user-agents how to discover privacy policy beforehand.
+
+   While there are several ways to access per-resource metadata (e.g.,
+   HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
+   (either in terms of client-perceived latency and/or deployment
+   difficulties) associated with them often precludes their use in these
+   scenarios.
+
+   When this happens, it is common to designate a "well-known location"
+   for such data, so that it can be easily located.  However, this
+   approach has the drawback of risking collisions, both with other such
+   designated "well-known locations" and with pre-existing resources.
+
+   To address this, this memo defines a path prefix in HTTP(S) URIs for
+   these "well-known locations", "/.well-known/".  Future specifications
+   that need to define a resource for such site-wide metadata can
+   register their use to avoid collisions and minimise impingement upon
+   sites' URI space.
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 2]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+1.1.  Appropriate Use of Well-Known URIs
+
+   There are a number of possible ways that applications could use Well-
+   known URIs.  However, in keeping with the Architecture of the World-
+   Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
+   for general information retrieval or establishment of large URI
+   namespaces on the Web.  Rather, they are designed to facilitate
+   discovery of information on a site when it isn't practical to use
+   other mechanisms; for example, when discovering policy that needs to
+   be evaluated before a resource is accessed, or when using multiple
+   round-trips is judged detrimental to performance.
+
+   As such, the well-known URI space was created with the expectation
+   that it will be used to make site-wide policy information and other
+   metadata available directly (if sufficiently concise), or provide
+   references to other URIs that provide such metadata.
+
+2.  Notational Conventions
+
+   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 RFC 2119 [RFC2119].
+
+3.  Well-Known URIs
+
+   A well-known URI is a URI [RFC3986] whose path component begins with
+   the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
+   or another scheme that has explicitly been specified to use well-
+   known URIs.
+
+   Applications that wish to mint new well-known URIs MUST register
+   them, following the procedures in Section 5.1.
+
+   For example, if an application registers the name 'example', the
+   corresponding well-known URI on 'http://www.example.com/' would be
+   'http://www.example.com/.well-known/example'.
+
+   Registered names MUST conform to the segment-nz production in
+   [RFC3986].
+
+   Note that this specification defines neither how to determine the
+   authority to use for a particular context, nor the scope of the
+   metadata discovered by dereferencing the well-known URI; both should
+   be defined by the application itself.
+
+   Typically, a registration will reference a specification that defines
+   the format and associated media type to be obtained by dereferencing
+   the well-known URI.
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 3]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+   It MAY also contain additional information, such as the syntax of
+   additional path components, query strings and/or fragment identifiers
+   to be appended to the well-known URI, or protocol-specific details
+   (e.g., HTTP [RFC2616] method handling).
+
+   Note that this specification does not define a format or media-type
+   for the resource located at "/.well-known/" and clients should not
+   expect a resource to exist at that location.
+
+4.  Security Considerations
+
+   This memo does not specify the scope of applicability of metadata or
+   policy obtained from a well-known URI, and does not specify how to
+   discover a well-known URI for a particular application.  Individual
+   applications using this mechanism must define both aspects.
+
+   Applications minting new well-known URIs, as well as administrators
+   deploying them, will need to consider several security-related
+   issues, including (but not limited to) exposure of sensitive data,
+   denial-of-service attacks (in addition to normal load issues), server
+   and client authentication, vulnerability to DNS rebinding attacks,
+   and attacks where limited access to a server grants the ability to
+   affect how well-known URIs are served.
+
+5.  IANA Considerations
+
+5.1.  The Well-Known URI Registry
+
+   This document establishes the well-known URI registry.
+
+   Well-known URIs are registered on the advice of one or more
+   Designated Experts (appointed by the IESG or their delegate), with a
+   Specification Required (using terminology from [RFC5226]).  However,
+   to allow for the allocation of values prior to publication, the
+   Designated Expert(s) may approve registration once they are satisfied
+   that such a specification will be published.
+
+   Registration requests should be sent to the
+   wellknown-uri-review@ietf.org mailing list for review and comment,
+   with an appropriate subject (e.g., "Request for well-known URI:
+   example").
+
+   Before a period of 14 days has passed, the Designated Expert(s) will
+   either approve or deny the registration request, communicating this
+   decision both to the review list and to IANA.  Denials should include
+   an explanation and, if applicable, suggestions as to how to make the
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 4]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+   request successful.  Registration requests that are undetermined for
+   a period longer than 21 days can be brought to the IESG's attention
+   (using the iesg@iesg.org mailing list) for resolution.
+
+5.1.1.  Registration Template
+
+   URI suffix:  The name requested for the well-known URI, relative to
+      "/.well-known/"; e.g., "example".
+
+   Change controller:  For Standards-Track RFCs, state "IETF".  For
+      others, give the name of the responsible party.  Other details
+      (e.g., postal address, e-mail address, home page URI) may also be
+      included.
+
+   Specification document(s):  Reference to the document that specifies
+      the field, preferably including a URI that can be used to retrieve
+      a copy of the document.  An indication of the relevant sections
+      may also be included, but is not required.
+
+   Related information:  Optionally, citations to additional documents
+      containing further relevant information.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3986] Berners-Lee, T., Fielding, R., and L.  Masinter, "Uniform
+             Resource Identifier (URI): Generic Syntax", STD 66,
+             RFC 3986, January 2005.
+
+   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+             May 2008.
+
+6.2.  Informative References
+
+   [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.
+
+   [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
+             Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 5]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+   [W3C.REC-P3P-20020416]
+             Marchiori, M., "The Platform for Privacy Preferences 1.0
+             (P3P1.0) Specification", World Wide Web Consortium
+             Recommendation REC-P3P-20020416, April 2002,
+             <http://www.w3.org/TR/2002/ REC-P3P-20020416>.
+
+   [W3C.REC-webarch-20041215]
+             Jacobs, I. and N. Walsh, "Architecture of the World Wide
+             Web, Volume One", World Wide Web Consortium
+             Recommendation REC- webarch-20041215, December 2004,
+             <http:// www.w3.org/TR/2004/REC-webarch-20041215>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 6]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+Appendix A.  Acknowledgements
+
+   We would like to acknowledge the contributions of everyone who
+   provided feedback and use cases for this document; in particular,
+   Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
+   Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
+   Breno de Medeiros, John Panzer, and Drummond Reed.  However, they are
+   not responsible for errors and omissions.
+
+Appendix B.  Frequently Asked Questions
+
+   1. Aren't well-known locations bad for the Web?
+
+      They are, but for various reasons -- both technical and social --
+      they are commonly used and their use is increasing.  This memo
+      defines a "sandbox" for them, to reduce the risks of collision and
+      to minimise the impact upon pre-existing URIs on sites.
+
+   2. Why /.well-known?
+
+      It's short, descriptive, and according to search indices, not
+      widely used.
+
+   3. What impact does this have on existing mechanisms, such as P3P and
+      robots.txt?
+
+      None, until they choose to use this mechanism.
+
+   4. Why aren't per-directory well-known locations defined?
+
+      Allowing every URI path segment to have a well-known location
+      (e.g., "/images/.well-known/") would increase the risks of
+      colliding with a pre-existing URI on a site, and generally these
+      solutions are found not to scale well, because they're too
+      "chatty".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 7]
+
+RFC 5785                Defining Well-Known URIs              April 2010
+
+
+Authors' Addresses
+
+   Mark Nottingham
+
+   EMail: mnot@mnot.net
+   URI:   http://www.mnot.net/
+
+
+   Eran Hammer-Lahav
+
+   EMail: eran@hueniverse.com
+   URI:   http://hueniverse.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav    Standards Track                    [Page 8]
+

doc/rfc6764-caldav-carddav-service-discovery.txt

@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          C. Daboo
+Request for Comments: 6764                                    Apple Inc.
+Updates: 4791, 6352                                        February 2013
+Category: Standards Track
+ISSN: 2070-1721
+
+
+            Locating Services for Calendaring Extensions to
+        WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
+
+Abstract
+
+   This specification describes how DNS SRV records, DNS TXT records,
+   and well-known URIs can be used together or separately to locate
+   CalDAV (Calendaring Extensions to Web Distributed Authoring and
+   Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV)
+   services.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6764.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Daboo                        Standards Track                    [Page 1]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. CalDAV SRV Service Labels .......................................3
+   4. CalDAV and CardDAV Service TXT Records ..........................4
+   5. CalDAV and CardDAV Service Well-Known URI .......................4
+      5.1. Example: Well-Known URI Redirects to Actual
+           "Context Path" .............................................5
+   6. Client "Bootstrapping" Procedures ...............................5
+   7. Guidance for Service Providers ..................................8
+   8. Security Considerations .........................................9
+   9. IANA Considerations .............................................9
+      9.1. Well-Known URI Registrations ...............................9
+           9.1.1. caldav Well-Known URI Registration .................10
+           9.1.2. carddav Well-Known URI Registration ................10
+      9.2. Service Name Registrations ................................10
+           9.2.1. caldav Service Name Registration ...................10
+           9.2.2. caldavs Service Name Registration ..................11
+           9.2.3. carddav Service Name Registration ..................11
+           9.2.4. carddavs Service Name Registration .................12
+   10. Acknowledgments ...............................................12
+   11. References ....................................................12
+      11.1. Normative References .....................................12
+      11.2. Informative References ...................................14
+
+1.  Introduction
+
+   [RFC4791] defines the CalDAV calendar access protocol, based on HTTP
+   [RFC2616], for accessing calendar data stored on a server.  CalDAV
+   clients need to be able to discover appropriate CalDAV servers within
+   their local area network and at other domains, e.g., to minimize the
+   need for end users to know specific details such as the fully
+   qualified domain name (FQDN) and port number for their servers.
+
+   [RFC6352] defines the CardDAV address book access protocol based on
+   HTTP [RFC2616], for accessing contact data stored on a server.  As
+   with CalDAV, clients also need to be able to discover CardDAV
+   servers.
+
+   [RFC2782] defines a DNS-based service discovery protocol that has
+   been widely adopted as a means of locating particular services within
+   a local area network and beyond, using DNS SRV Resource Records
+   (RRs).  This has been enhanced to provide additional service meta-
+   data by use of DNS TXT RRs as per [RFC6763].
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 2]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   This specification defines new SRV service types for the CalDAV
+   protocol and gives an example of how clients can use this together
+   with other protocol features to enable simple client configuration.
+   SRV service types for CardDAV are already defined in Section 11 of
+   [RFC6352].
+
+   Another issue with CalDAV or CardDAV service discovery is that the
+   service might not be located at the "root" URI of the HTTP server
+   hosting it.  Thus, a client needs to be able to determine the
+   complete path component of the Request-URI to use in HTTP requests:
+   the "context path".  For example, if CalDAV is implemented as a
+   "servlet" in a web server "container", the servlet "context path"
+   might be "/caldav/".  So the URI for the CalDAV service would be,
+   e.g., "http://caldav.example.com/caldav/" rather than
+   "http://caldav.example.com/".  SRV RRs by themselves only provide an
+   FQDN and port number for the service, not a path.  Since the client
+   "bootstrapping" process requires initial access to the "context path"
+   of the service, there needs to be a simple way for clients to also
+   discover what that path is.
+
+   This specification makes use of the "well-known URI" feature
+   [RFC5785] of HTTP servers to provide a well-known URI for CalDAV or
+   CardDAV services that clients can use.  The well-known URI will point
+   to a resource on the server that is simply a "stub" resource that
+   provides a redirect to the actual "context path" resource
+   representing the service endpoint.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  CalDAV SRV Service Labels
+
+   This specification adds two SRV service labels for use with CalDAV:
+
+   _caldav:   Identifies a CalDAV server that uses HTTP without
+      Transport Layer Security (TLS) [RFC2818].
+
+   _caldavs:  Identifies a CalDAV server that uses HTTP with TLS
+      [RFC2818].
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 3]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   Clients MUST honor Priority and Weight values in the SRV RRs, as
+   described by [RFC2782].
+
+   Example: service record for server without TLS
+
+       _caldav._tcp     SRV 0 1 80 calendar.example.com.
+
+   Example: service record for server with TLS
+
+       _caldavs._tcp    SRV 0 1 443 calendar.example.com.
+
+4.  CalDAV and CardDAV Service TXT Records
+
+   When SRV RRs are used to advertise CalDAV and CardDAV services, it is
+   also convenient to be able to specify a "context path" in the DNS to
+   be retrieved at the same time.  To enable that, this specification
+   uses a TXT RR that follows the syntax defined in Section 6 of
+   [RFC6763] and defines a "path" key for use in that record.  The value
+   of the key MUST be the actual "context path" to the corresponding
+   service on the server.
+
+   A site might provide TXT records in addition to SRV records for each
+   service.  When present, clients MUST use the "path" value as the
+   "context path" for the service in HTTP requests.  When not present,
+   clients use the ".well-known" URI approach described next.
+
+   Example: text record for service with TLS
+
+       _caldavs._tcp    TXT path=/caldav
+
+5.  CalDAV and CardDAV Service Well-Known URI
+
+   Two ".well-known" URIs are registered by this specification for
+   CalDAV and CardDAV services, "caldav" and "carddav" respectively (see
+   Section 9).  These URIs point to a resource that the client can use
+   as the initial "context path" for the service they are trying to
+   connect to.  The server MUST redirect HTTP requests for that resource
+   to the actual "context path" using one of the available mechanisms
+   provided by HTTP (e.g., using a 301, 303, or 307 response).  Clients
+   MUST handle HTTP redirects on the ".well-known" URI.  Servers MUST
+   NOT locate the actual CalDAV or CardDAV service endpoint at the
+   ".well-known" URI as per Section 1.1 of [RFC5785].
+
+   Servers SHOULD set an appropriate Cache-Control header value (as per
+   Section 14.9 of [RFC2616]) in the redirect response to ensure caching
+   occurs or does not occur as needed or as required by the type of
+   response generated.  For example, if it is anticipated that the
+
+
+
+
+Daboo                        Standards Track                    [Page 4]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   location of the redirect might change over time, then a "no-cache"
+   value would be used.
+
+   To facilitate "context paths" that might differ from user to user,
+   the server MAY require authentication when a client tries to access
+   the ".well-known" URI (i.e., the server would return a 401 status
+   response to the unauthenticated request from the client, then return
+   the redirect response only after a successful authentication by the
+   client).
+
+5.1.  Example: Well-Known URI Redirects to Actual "Context Path"
+
+   A CalDAV server has a "context path" that is "/servlet/caldav".  The
+   client will use "/.well-known/caldav" as the path for its
+   "bootstrapping" process after it has first found the FQDN and port
+   number via an SRV lookup or via manual entry of information by the
+   user, from which the client can parse suitable information.  When the
+   client makes an HTTP request against "/.well-known/caldav", the
+   server would issue an HTTP redirect response with a Location response
+   header using the path "/servlet/caldav".  The client would then
+   "follow" this redirect to the new resource and continue making HTTP
+   requests there to complete its "bootstrapping" process.
+
+6.  Client "Bootstrapping" Procedures
+
+   This section describes a procedure that CalDAV or CardDAV clients
+   SHOULD use to do their initial configuration based on minimal user
+   input.  The goal is to determine an http: or https: URI that
+   describes the full path to the user's principal-URL [RFC3744].
+
+   1.  Processing user input:
+
+       *  For a CalDAV server:
+
+          +  Minimal input from a user would consist of a calendar user
+             address and a password.  A calendar user address is defined
+             by iCalendar [RFC5545] to be a URI [RFC3986].  Provided a
+             user identifier and a domain name can be extracted from the
+             URI, this simple "bootstrapping" configuration can be done.
+
+          +  If the calendar user address is a "mailto:" [RFC6068] URI,
+             the "mailbox" portion of the URI is examined, and the
+             "local-part" and "domain" portions are extracted.
+
+          +  If the calendar user address is an "http:" [RFC2616] or
+             "https:" [RFC2818] URI, the "userinfo" and "host" portion
+             of the URI [RFC3986] is extracted.
+
+
+
+
+Daboo                        Standards Track                    [Page 5]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+       *  For a CardDAV server:
+
+          +  Minimal input from a user would consist of their email
+             address [RFC5322] for the domain where the CardDAV service
+             is hosted, and a password.  The "mailbox" portion of the
+             email address is examined, and the "local-part" and
+             "domain" portions are extracted.
+
+   2.  Determination of service FQDN and port number:
+
+       *  An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp
+          (for CardDAV) is done with the extracted "domain" as the
+          service domain.
+
+       *  If no result is found, the client can try _caldav._tcp (for
+          CalDAV) or _carddav._tcp (for CardDAV) provided non-TLS
+          connections are appropriate.
+
+       *  If an SRV record is returned, the client extracts the target
+          FQDN and port number.  If multiple SRV records are returned,
+          the client MUST use the Priority and Weight fields in the
+          record to determine which one to pick (as per [RFC2782]).
+
+       *  If an SRV record is not found, the client will need to prompt
+          the user to enter the FQDN and port number information
+          directly or use some other heuristic, for example, using the
+          extracted "domain" as the FQDN and default HTTPS or HTTP port
+          numbers.  In this situation, clients MUST first attempt an
+          HTTP connection with TLS.
+
+   3.  Determination of initial "context path":
+
+       *  When an SRV lookup is done and a valid SRV record returned,
+          the client MUST also query for a corresponding TXT record and
+          check for the presence of a "path" key in its response.  If
+          present, the value of the "path" key is used for the initial
+          "context path".
+
+       *  When an initial "context path" has not been determined from a
+          TXT record, the initial "context path" is taken to be
+          "/.well-known/caldav" (for CalDAV) or "/.well-known/carddav"
+          (for CardDAV).
+
+       *  If the initial "context path" derived from a TXT record
+          generates HTTP errors when targeted by requests, the client
+          SHOULD repeat its "bootstrapping" procedure using the
+          appropriate ".well-known" URI instead.
+
+
+
+
+Daboo                        Standards Track                    [Page 6]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   4.  Determination of user identifier:
+
+       *  The client will need to make authenticated HTTP requests to
+          the service.  Typically, a "user identifier" is required for
+          some form of user/password authentication.  When a user
+          identifier is required, clients MUST first use the "mailbox"
+          portion of the calendar user address provided by the user in
+          the case of a "mailto:" address and, if that results in an
+          authentication failure, SHOULD fall back to using the "local-
+          part" extracted from the "mailto:" address.  For an "http:" or
+          "https:" calendar user address, the "userinfo" portion is used
+          as the user identifier for authentication.  This is in line
+          with the guidance outlined in Section 7.  If these user
+          identifiers result in authentication failure, the client
+          SHOULD prompt the user for a valid identifier.
+
+   5.  Connecting to the service:
+
+       *  Subsequent to configuration, the client will make HTTP
+          requests to the service.  When using "_caldavs" or "_carddavs"
+          services, a TLS negotiation is done immediately upon
+          connection.  The client MUST do certificate verification using
+          the procedure outlined in Section 6 of [RFC6125] in regard to
+          verification with an SRV RR as the starting point.
+
+       *  The client does a "PROPFIND" [RFC4918] request with the
+          request URI set to the initial "context path".  The body of
+          the request SHOULD include the DAV:current-user-principal
+          [RFC5397] property as one of the properties to return.  Note
+          that clients MUST properly handle HTTP redirect responses for
+          the request.  The server will use the HTTP authentication
+          procedure outlined in [RFC2617] or use some other appropriate
+          authentication schemes to authenticate the user.
+
+       *  If the server returns a 404 ("Not Found") HTTP status response
+          to the request on the initial "context path", clients MAY try
+          repeating the request on the "root" URI "/" or prompt the user
+          for a suitable path.
+
+       *  If the DAV:current-user-principal property is returned on the
+          request, the client uses that value for the principal-URL of
+          the authenticated user.  With that, it can execute a
+          "PROPFIND" request on the principal-URL and discover
+          additional properties for configuration (e.g., calendar or
+          address book "home" collections).
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 7]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+       *  If the DAV:current-user-principal property is not returned,
+          then the client will need to request the principal-URL path
+          from the user in order to continue with configuration.
+
+   Once a successful account discovery step has been done, clients
+   SHOULD cache the service details that were successfully used (user
+   identity, principal-URL with full scheme/host/port details) and reuse
+   those when connecting again at a later time.
+
+   If a subsequent connection attempt fails, or authentication fails
+   persistently, clients SHOULD retry the SRV lookup and account
+   discovery to "refresh" the cached data.
+
+7.  Guidance for Service Providers
+
+   Service providers wanting to offer CalDAV or CardDAV services that
+   can be configured by clients using SRV records need to follow certain
+   procedures to ensure proper operation.
+
+   o  CalDAV or CardDAV servers SHOULD be configured to allow
+      authentication with calendar user addresses (just taking the
+      "mailbox" portion of any "mailto:" URI) or email addresses
+      respectively, or with "user identifiers" extracted from them.  In
+      the former case, the addresses MUST NOT conflict with other forms
+      of a permitted user login name.  In the latter case, the extracted
+      "user identifiers" need to be unique across the server and MUST
+      NOT conflict with any login name on the server.
+
+   o  Servers MUST force authentication for "PROPFIND" requests that
+      retrieve the DAV:current-user-principal property to ensure that
+      the value of the DAV:current-user-principal property returned
+      corresponds to the principal-URL of the user making the request.
+
+   o  If the service provider uses TLS, the service provider MUST ensure
+      a certificate is installed that can be verified by clients using
+      the procedure outlined in Section 6 of [RFC6125] in regard to
+      verification with an SRV RR as the starting point.  In particular,
+      certificates SHOULD include SRV-ID and DNS-ID identifiers as
+      appropriate, as described in Section 8.
+
+   o  Service providers should install the appropriate SRV records for
+      the offered services and optionally include TXT records.
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 8]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+8.  Security Considerations
+
+   Clients that support TLS as defined by [RFC2818] SHOULD try the
+   "_caldavs" or "_carddavs" services first before trying the "_caldav"
+   or "_carddav" services respectively.  If a user has explicitly
+   requested a connection with TLS, the client MUST NOT use any service
+   information returned for the "_caldav" or "_carddav" services.
+   Clients MUST follow the certificate-verification process specified in
+   [RFC6125].
+
+   A malicious attacker with access to the DNS server data, or that is
+   able to get spoofed answers cached in a recursive resolver, can
+   potentially cause clients to connect to any server chosen by the
+   attacker.  In the absence of a secure DNS option, clients SHOULD
+   check that the target FQDN returned in the SRV record matches the
+   original service domain that was queried.  If the target FQDN is not
+   in the queried domain, clients SHOULD verify with the user that the
+   SRV target FQDN is suitable for use before executing any connections
+   to the host.  Alternatively, if TLS is being used for the service,
+   clients MUST use the procedure outlined in Section 6 of [RFC6125] to
+   verify the service.  When the target FQDN does not match the original
+   service domain that was queried, clients MUST check the SRV-ID
+   identifier in the server's certificate.  If the FQDN does match,
+   clients MUST check any SRV-ID identifiers in the server's certificate
+   or, if no SRV-ID identifiers are present, MUST check the DNS-ID
+   identifiers in the server's certificate.
+
+   Implementations of TLS [RFC5246], used as the basis for TLS
+   ([RFC2818]), typically support multiple versions of the protocol as
+   well as the older SSL (Secure Sockets Layer) protocol.  Because of
+   known security vulnerabilities, clients and servers MUST NOT request,
+   offer, or use SSL 2.0.  See Appendix E.2 of [RFC5246] for further
+   details.
+
+9.  IANA Considerations
+
+9.1.  Well-Known URI Registrations
+
+   This document defines two ".well-known" URIs using the registration
+   procedure and template from Section 5.1 of [RFC5785].
+
+
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                    [Page 9]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+9.1.1.  caldav Well-Known URI Registration
+
+   URI suffix:  caldav
+
+   Change controller:  IETF
+
+   Specification document(s):  This RFC
+
+   Related information:  See also [RFC4791].
+
+9.1.2.  carddav Well-Known URI Registration
+
+   URI suffix:  carddav
+
+   Change controller:  IETF
+
+   Specification document(s):  This RFC
+
+   Related information:  See also [RFC6352].
+
+9.2.  Service Name Registrations
+
+   This document registers four new service names as per [RFC6335].  Two
+   are defined in this document, and two are defined in [RFC6352],
+   Section 11.
+
+9.2.1.  caldav Service Name Registration
+
+   Service Name:  caldav
+
+   Transport Protocol(s):  TCP
+
+   Assignee:  IESG <iesg@ietf.org>
+
+   Contact:  IETF Chair <chair@ietf.org>
+
+   Description:  Calendaring Extensions to WebDAV (CalDAV) - non-TLS
+
+   Reference:  [RFC6764]
+
+   Assignment Note:  This is an extension of the http service.  Defined
+      TXT keys: path=<context path>
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                   [Page 10]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+9.2.2.  caldavs Service Name Registration
+
+   Service Name:  caldavs
+
+   Transport Protocol(s):  TCP
+
+   Assignee:  IESG <iesg@ietf.org>
+
+   Contact:  IETF Chair <chair@ietf.org>
+
+   Description:  Calendaring Extensions to WebDAV (CalDAV) - over TLS
+
+   Reference:  [RFC6764]
+
+   Assignment Note:  This is an extension of the https service.  Defined
+      TXT keys: path=<context path>
+
+9.2.3.  carddav Service Name Registration
+
+   Service Name:  carddav
+
+   Transport Protocol(s):  TCP
+
+   Assignee:  IESG <iesg@ietf.org>
+
+   Contact:  IETF Chair <chair@ietf.org>
+
+   Description:  vCard Extensions to WebDAV (CardDAV) - non-TLS
+
+   Reference:  [RFC6352]
+
+   Assignment Note:  This is an extension of the http service.  Defined
+      TXT keys: path=<context path>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                   [Page 11]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+9.2.4.  carddavs Service Name Registration
+
+   Service Name:  carddavs
+
+   Transport Protocol(s):  TCP
+
+   Assignee:  IESG <iesg@ietf.org>
+
+   Contact:  IETF Chair <chair@ietf.org>
+
+   Description:  vCard Extensions to WebDAV (CardDAV) - over TLS
+
+   Reference:  [RFC6352]
+
+   Assignment Note:  This is an extension of the https service.  Defined
+      TXT keys: path=<context path>
+
+10.  Acknowledgments
+
+   This specification was suggested by discussion that took place within
+   the Calendaring and Scheduling Consortium's CalDAV Technical
+   Committee.  The author thanks the following for their contributions:
+   Stuart Cheshire, Bernard Desruisseaux, Eran Hammer-Lahav, Helge Hess,
+   Arnaud Quillaud, Wilfredo Sanchez, and Joe Touch.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+              Leach, P., Luotonen, A., and L. Stewart, "HTTP
+              Authentication: Basic and Digest Access Authentication",
+              RFC 2617, June 1999.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+
+
+
+
+Daboo                        Standards Track                   [Page 12]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+              Distributed Authoring and Versioning (WebDAV)
+              Access Control Protocol", RFC 3744, May 2004.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
+              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+              March 2007.
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [RFC5397]  Sanchez, W. and C. Daboo, "WebDAV Current Principal
+              Extension", RFC 5397, December 2008.
+
+   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+              Uniform Resource Identifiers (URIs)", RFC 5785,
+              April 2010.
+
+   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
+              URI Scheme", RFC 6068, October 2010.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+              Cheshire, "Internet Assigned Numbers Authority (IANA)
+              Procedures for the Management of the Service Name and
+              Transport Protocol Port Number Registry", BCP 165,
+              RFC 6335, August 2011.
+
+   [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 6352, August 2011.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, February 2013.
+
+
+
+Daboo                        Standards Track                   [Page 13]
+
+RFC 6764                SRV for CalDAV & CardDAV           February 2013
+
+
+11.2.  Informative References
+
+   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
+              Core Object Specification (iCalendar)", RFC 5545,
+              September 2009.
+
+Author's Address
+
+   Cyrus Daboo
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   EMail: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                        Standards Track                   [Page 14]
+

res/layout/login_email.xml

@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="utf-8"?>
+<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
+    android:layout_width="match_parent"
+    android:layout_height="match_parent" >
+
+    <GridLayout
+        android:layout_width="fill_parent"
+        android:layout_height="wrap_content"
+        android:layout_gravity="center_horizontal"
+        android:columnCount="2"
+        android:padding="10dp"
+        android:useDefaultMargins="true" >
+        
+        <TextView
+            android:layout_columnSpan="2"
+            android:layout_gravity="left"
+            android:textAppearance="?android:attr/textAppearanceMedium"
+            android:text="@string/login_email_description" />
+        
+        <TextView
+            android:textAppearance="?android:attr/textAppearanceMedium"
+            android:text="@string/login_email_address" />
+        <EditText
+            android:id="@+id/email_address"
+            android:layout_gravity="fill_horizontal"
+            android:inputType="textNoSuggestions|textEmailAddress"
+            android:imeOptions="actionNext"
+            android:layout_width="0dp"
+            android:scrollHorizontally="true"
+            android:scrollbars="horizontal"
+            android:hint="myaccount@icloud.com" />
+
+        <TextView
+            android:textAppearance="?android:attr/textAppearanceMedium"
+            android:text="@string/login_password" />
+        <EditText
+            android:id="@+id/password"
+            android:layout_gravity="fill_horizontal"
+            android:inputType="textPassword"
+            android:imeOptions="actionGo"
+            android:layout_width="0dp"
+            android:scrollHorizontally="true"
+            android:scrollbars="horizontal"
+            android:text="" />
+        
+    </GridLayout>    
+
+</ScrollView>

res/layout/login_type.xml

@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="utf-8"?>
+<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
+    android:layout_width="match_parent"
+    android:layout_height="match_parent"
+    android:padding="10dp"
+    android:useDefaultMargins="true" >
+
+    <RadioGroup
+        android:layout_width="match_parent"
+        android:layout_height="wrap_content"
+        android:orientation="vertical" >
+
+        <RadioButton
+            android:id="@+id/login_type_email"
+            android:layout_width="match_parent"
+            android:layout_height="wrap_content"
+            android:checked="true"
+            android:text="@string/login_type_email" />
+
+        <TextView
+            android:layout_width="match_parent"
+            android:layout_height="wrap_content"
+            android:layout_marginBottom="10dp"
+            android:text="@string/login_type_email_description" />
+
+        <RadioButton
+            android:id="@+id/login_type_url"
+            android:layout_width="match_parent"
+            android:layout_height="wrap_content"
+            android:text="@string/login_type_url" />
+
+        <TextView
+            android:layout_width="match_parent"
+            android:layout_height="wrap_content"
+            android:text="@string/login_type_url_description" />
+    </RadioGroup>
+
+</ScrollView>

res/layout/login_url.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="utf-8"?>
 <ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
-    android:layout_width="fill_parent"
-    android:layout_height="fill_parent" >
+    android:layout_width="match_parent"
+    android:layout_height="match_parent" >
 
     <GridLayout
         android:layout_width="fill_parent"
@@ -15,23 +15,23 @@
             android:layout_columnSpan="2"
             android:layout_gravity="left"
             android:textAppearance="?android:attr/textAppearanceMedium"
-            android:text="@string/root_url" />
+            android:text="@string/login_base_url" />
 
         <Spinner
             android:id="@+id/login_scheme"
             android:layout_width="wrap_content"
             android:layout_gravity="left"
-            android:entries="@array/uri_scheme" />
+            android:entries="@array/login_url_scheme" />
 
         <EditText
-            android:id="@+id/login_authority_path"
+            android:id="@+id/login_host_path"
             android:layout_gravity="fill_horizontal"
             android:imeOptions="flagForceAscii|actionNext"
             android:inputType="textUri"
             android:layout_width="0dp"
             android:scrollHorizontally="true"
             android:scrollbars="horizontal"
-            android:text="" />
+            android:hint="my.webhost.com" />
 
         <TextView
             android:id="@+id/http_warning"
@@ -42,11 +42,11 @@
             android:drawableLeft="@drawable/alerts_and_states_warning"
             android:drawablePadding="10dp"
             android:padding="10dp"
-            android:text="@string/http_warning" />
+            android:text="@string/login_http_warning" />
 
         <TextView
             android:textAppearance="?android:attr/textAppearanceMedium"
-            android:text="@string/user_name" />
+            android:text="@string/login_user_name" />
 
         <EditText
             android:id="@+id/userName"
@@ -60,7 +60,7 @@
 
         <TextView
             android:textAppearance="?android:attr/textAppearanceMedium"
-            android:text="@string/password" />
+            android:text="@string/login_password" />
 
         <EditText
             android:id="@+id/password"

res/menu/select_collections.xml

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<menu xmlns:android="http://schemas.android.com/apk/res/android" >
-
-    <item
-        android:id="@+id/next"
-        android:icon="@drawable/navigation_forward"
-        android:showAsAction="always|withText"
-        android:title="@string/next">
-    </item>
-
-</menu>

res/values-ca/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">"Si no feu servir cap encriptació (HTTPS), altres usuaris poden interceptar fàcilment les vostres credencials, contactes i events."</string>
-    <string name="user_name">Nom d\'usuari:</string>
-    <string name="password">Contrasenya:</string>
-    <string name="root_url">URL Arrel (les coleccions es detecten automàticament):</string>
+    <string name="login_http_warning">"Si no feu servir cap encriptació (HTTPS), altres usuaris poden interceptar fàcilment les vostres credencials, contactes i events."</string>
+    <string name="login_user_name">Nom d\'usuari:</string>
+    <string name="login_password">Contrasenya:</string>
+    <string name="login_base_url">URL Arrel (les coleccions es detecten automàticament):</string>
     <string name="next">Següent</string>
     <string name="help">Ajuda</string>
-    <string name="invalid_base_url">URL base invàlida: </string>
-    <string name="title_select_collections">DAVdroid: Seleccioneu col·leccions</string>
-    <string name="exception_io">Error de E/S: %s</string>
+    <string name="login_invalid_base_url">URL base invàlida: </string>
+    <string name="select_collections">DAVdroid: Seleccioneu col·leccions</string>
+    <string name="login_exception_io">Error de E/S: %s</string>
     <string name="exception_uri_syntax">URI invàlida: %s</string>
     <string name="exception_incapable_resource">Missing capabilities: %s</string>
     <string name="neither_caldav_nor_carddav">Ni CalDAV ni CardDAV estan disponibles</string>

res/values-cs/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">"Pokud nepoužijete šifrované připojení (HTTPS), ostatní budou moci lehce získat vaše přihlašovací údaje, kontakty a události."</string>
-    <string name="user_name">Uživatelské jméno:</string>
-    <string name="password">Heslo:</string>
-    <string name="root_url">Kořenová URL (sbírky budou detekovány automaticky):</string>
+    <string name="login_http_warning">"Pokud nepoužijete šifrované připojení (HTTPS), ostatní budou moci lehce získat vaše přihlašovací údaje, kontakty a události."</string>
+    <string name="login_user_name">Uživatelské jméno:</string>
+    <string name="login_password">Heslo:</string>
+    <string name="login_base_url">Kořenová URL (sbírky budou detekovány automaticky):</string>
     <string name="next">Další</string>
     <string name="help">Pomoc</string>
-    <string name="invalid_base_url">Neplatná základní URL: </string>
-    <string name="title_select_collections">DAVdroid: Vybrat sbírky</string>
-    <string name="exception_io">I/O chyba: %s</string>
+    <string name="login_invalid_base_url">Neplatná základní URL: </string>
+    <string name="select_collections">DAVdroid: Vybrat sbírky</string>
+    <string name="login_exception_io">I/O chyba: %s</string>
     <string name="exception_uri_syntax">Neplatné URI: %s</string>
     <string name="exception_incapable_resource">Chybějící možnosti: %s</string>
     <string name="neither_caldav_nor_carddav">V tomto umístění není CalDAV-/CardDAV služba dostupná.</string>

res/values-de/strings.xml

@@ -1,15 +1,15 @@
 <?xml version="1.0" encoding="utf-8"?>
 <resources>
 
-    <string name="http_warning">Ohne Verschlüsselung (HTTPS) können Ihre Zugangsdaten, Kontakte und Termine leicht abgefangen werden.</string>
-    <string name="user_name">Benutzername:</string>
-    <string name="password">Passwort:</string>
-    <string name="root_url">Basis-URL (Ordner werden automatisch gefunden):</string>
+    <string name="login_http_warning">Ohne Verschlüsselung (HTTPS) können Ihre Zugangsdaten, Kontakte und Termine leicht abgefangen werden.</string>
+    <string name="login_user_name">Benutzername:</string>
+    <string name="login_password">Passwort:</string>
+    <string name="login_base_url">Basis-URL (Ordner werden automatisch gefunden):</string>
     <string name="next">Weiter</string>
     <string name="help">Hilfe</string>
-    <string name="title_select_collections">DAVdroid: Ordner auswählen</string>
-    <string name="invalid_base_url">Ungültiger Basis-URL: </string>
-    <string name="exception_io">E/A-Fehler: %s</string>
+    <string name="select_collections">DAVdroid: Ordner auswählen</string>
+    <string name="login_invalid_base_url">Ungültiger Basis-URL: </string>
+    <string name="login_exception_io">E/A-Fehler: %s</string>
     <string name="exception_uri_syntax">Ungültiger URI: %s</string>
     <string name="exception_incapable_resource">Fehlende Server-Unterstützung: %s</string>
     <string name="neither_caldav_nor_carddav">An dieser Adresse konnte kein CalDAV- oder CardDAV-Dienst gefunden werden.</string>

res/values-es/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">"Si no usas encriptación (HTTPS), otras personas pueden interceptar fácilmente tus datos de ingreso, contactos y eventos."</string>
-    <string name="user_name">Nombre de usuario:</string>
-    <string name="password">Contraseña:</string>
-    <string name="root_url">URL raiz (colecciones autodetectadas):</string>
+    <string name="login_http_warning">"Si no usas encriptación (HTTPS), otras personas pueden interceptar fácilmente tus datos de ingreso, contactos y eventos."</string>
+    <string name="login_user_name">Nombre de usuario:</string>
+    <string name="login_password">Contraseña:</string>
+    <string name="login_base_url">URL raiz (colecciones autodetectadas):</string>
     <string name="next">Siguiente</string>
     <string name="help">Ayuda</string>
-    <string name="invalid_base_url">URL base no válida: </string>
-    <string name="title_select_collections">DAVdroid: Selecciona las colecciones</string>
-    <string name="exception_io">I/O error: %s</string>
+    <string name="login_invalid_base_url">URL base no válida: </string>
+    <string name="select_collections">DAVdroid: Selecciona las colecciones</string>
+    <string name="login_exception_io">I/O error: %s</string>
     <string name="exception_uri_syntax">URI no válida: %s</string>
     <string name="exception_incapable_resource">Se han perdido capacidades: %s</string>
     <string name="neither_caldav_nor_carddav">Ni CalDAV ni CardDAV están disponibles</string>

res/values-fr/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">Si vous n\'utilisez pas de chiffrement(HTTPS), d\'autres personnes peuvent facilement intercepter vos informations de connexion, contacts et événements.</string>
-    <string name="user_name">Utilisateur:</string>
-    <string name="password">Mot de passe:</string>
-    <string name="root_url">URL racine(les collections seront autodétectées):</string>
+    <string name="login_http_warning">Si vous n\'utilisez pas de chiffrement(HTTPS), d\'autres personnes peuvent facilement intercepter vos informations de connexion, contacts et événements.</string>
+    <string name="login_user_name">Utilisateur:</string>
+    <string name="login_password">Mot de passe:</string>
+    <string name="login_base_url">URL racine(les collections seront autodétectées):</string>
     <string name="next">Suivant</string>
     <string name="help">Aide</string>
-    <string name="invalid_base_url">Racine de l\'URL incorrecte:</string>
-    <string name="title_select_collections">DAVdroid: Sélectionnez les collections</string>
-    <string name="exception_io">Erreur I/O: %s</string>
+    <string name="login_invalid_base_url">Racine de l\'URL incorrecte:</string>
+    <string name="select_collections">DAVdroid: Sélectionnez les collections</string>
+    <string name="login_exception_io">Erreur I/O: %s</string>
     <string name="exception_uri_syntax">URI incorrecte: %s</string>
     <string name="exception_incapable_resource">Capacités manquantes: %s</string>
     <string name="neither_caldav_nor_carddav">Aucun CalDAV ou CardDAV disponible</string>

res/values-hu/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">"Titkosítás (HTTPS) nélkül a bejelentkezési azonosítókat, névjegyeket és eseményeket könnyen megismerhetik mások is."</string>
-    <string name="user_name">Felhasználónév:</string>
-    <string name="password">Jelszó:</string>
-    <string name="root_url">Fiók URL (a gyűjtemények detektálása automatikus):</string>
+    <string name="login_http_warning">"Titkosítás (HTTPS) nélkül a bejelentkezési azonosítókat, névjegyeket és eseményeket könnyen megismerhetik mások is."</string>
+    <string name="login_user_name">Felhasználónév:</string>
+    <string name="login_password">Jelszó:</string>
+    <string name="login_base_url">Fiók URL (a gyűjtemények detektálása automatikus):</string>
     <string name="next">Tovább</string>
     <string name="help">Súgó</string>
-    <string name="invalid_base_url">A fiók URL hibás: </string>
-    <string name="title_select_collections">DAVdroid: Gyűjtemény kiválasztása</string>
-    <string name="exception_io">I/O hiba: %s</string>
+    <string name="login_invalid_base_url">A fiók URL hibás: </string>
+    <string name="select_collections">DAVdroid: Gyűjtemény kiválasztása</string>
+    <string name="login_exception_io">I/O hiba: %s</string>
     <string name="exception_uri_syntax">Érvénytelen URI: %s</string>
     <string name="exception_incapable_resource">Hiányzó képesség: %s</string>
     <string name="neither_caldav_nor_carddav">Nincs CalDAV-/CardDAV szolgáltatás a megadott helyen.</string>

res/values-sr/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">"Ако не користите шифровање (ХТТПС), други људи вам лако могу пресрести детаље пријаве, контакте и догађаје."</string>
-    <string name="user_name">Корисничко име:</string>
-    <string name="password">Лозинка:</string>
-    <string name="root_url">Корени УРЛ (збирке ће бити аутоматски откривене):</string>
+    <string name="login_http_warning">"Ако не користите шифровање (ХТТПС), други људи вам лако могу пресрести детаље пријаве, контакте и догађаје."</string>
+    <string name="login_user_name">Корисничко име:</string>
+    <string name="login_password">Лозинка:</string>
+    <string name="login_base_url">Корени УРЛ (збирке ће бити аутоматски откривене):</string>
     <string name="next">Следеће</string>
     <string name="help">Помоћ</string>
-    <string name="invalid_base_url">Неисправан основни УРИ: </string>
-    <string name="title_select_collections">ДАВдроид: Изаберите збирке</string>
-    <string name="exception_io">И/О грешка: %s</string>
+    <string name="login_invalid_base_url">Неисправан основни УРИ: </string>
+    <string name="select_collections">ДАВдроид: Изаберите збирке</string>
+    <string name="login_exception_io">И/О грешка: %s</string>
     <string name="exception_uri_syntax">Неисправан УРИ: %s</string>
     <string name="exception_incapable_resource">Недостају могућности: %s</string>
     <string name="neither_caldav_nor_carddav">Нема доступног КалДАВ/КардДАВ сервиса на овој локацији.</string>

res/values-zh-rcn/strings.xml

@@ -9,15 +9,15 @@
         <item>https://</item>
     </string-array>
 
-    <string name="http_warning">"如果不使用加密连接 (HTTPS)，其他人能很容易获取到你的登录信息、通讯录和日程。"</string>
-    <string name="user_name">用户名：</string>
-    <string name="password">密码：</string>
-    <string name="root_url">服务器根地址（集合会自动检测）：</string>
+    <string name="login_http_warning">"如果不使用加密连接 (HTTPS)，其他人能很容易获取到你的登录信息、通讯录和日程。"</string>
+    <string name="login_user_name">用户名：</string>
+    <string name="login_password">密码：</string>
+    <string name="login_base_url">服务器根地址（集合会自动检测）：</string>
     <string name="next">继续</string>
     <string name="help">帮助</string>
-    <string name="invalid_base_url">基准地址无效: </string>
-    <string name="title_select_collections">DAVdroid: 选择同步项</string>
-    <string name="exception_io">I/O error: %s</string>
+    <string name="login_invalid_base_url">基准地址无效: </string>
+    <string name="select_collections">DAVdroid: 选择同步项</string>
+    <string name="login_exception_io">I/O error: %s</string>
     <string name="exception_uri_syntax">URI 无效: %s</string>
     <string name="exception_incapable_resource">服务器缺少功能: %s</string>
     <string name="neither_caldav_nor_carddav">此服务器地址上没有可用的 CalDAV-/CardDAV 服务。</string>

res/values/strings.xml

@@ -1,40 +1,18 @@
 <?xml version="1.0" encoding="utf-8"?>
 <resources>
 
+    <!-- common strings -->
     <string name="app_name">DAVdroid</string>
-    <string name="menu_settings">Settings</string>
-
-    <string-array name="uri_scheme">
-        <item>http://</item>
-        <item>https://</item>
-        <item>mailto:</item>
-    </string-array>
-
-    <string name="http_warning">"If you don't use encryption (HTTPS), other people may easily intercept your login details, contacts and events."</string>
-    <string name="user_name">User name:</string>
-    <string name="password">Password:</string>
-    <string name="root_url">Root URL (collections will be auto-detected):</string>
+    
     <string name="next">Next</string>
     <string name="help">Help</string>
-    <string name="invalid_base_url">Invalid base URL: </string>
-    <string name="title_select_collections">DAVdroid: Select collections</string>
+    
+    <string name="exception_http">HTTP error: %s</string>
+    <string name="exception_incapable_resource">Missing capabilities: %s</string>
     <string name="exception_io">I/O error: %s</string>
     <string name="exception_uri_syntax">Invalid URI: %s</string>
-    <string name="exception_incapable_resource">Missing capabilities: %s</string>
-    <string name="neither_caldav_nor_carddav">No CalDAV-/CardDAV service is available at this location.</string>
-    <string name="add_account">Add account</string>
-    <string name="querying_server">Querying server. Please wait…</string>
-    <string name="exception_http">HTTP error: %s</string>
-    <string name="what_to_sync">Which collections shall be synchronized?</string>
-    <string name="address_books">Address books</string>
-    <string name="calendars">Calendars</string>
-    <string name="select_address_book">Select up to one address book (tap again to unselect):</string>
-    <string name="select_calendars">Select your calendars:</string>
-    <string name="auth_preemptive">Preemptive authentication (recommended, but incompatible with Digest auth)</string>
     
-    <string name="davdroid_help">DAVdroid Help</string>
-    <string name="show_sync_settings">Manage sync accounts</string>
-    <string name="show_website">DAVdroid Web site</string>
+    <!-- MainActivity -->
     <string name="html_main_workaround"><![CDATA[
 		<p>Thank you for buying DAVdroid via Google Play and thus supporting the project. Unfortunately, there are two issues with Google Play:</p>
 		
@@ -108,6 +86,41 @@
 	   	* <a href="http://simple.sourceforge.net/">Simple XML Serialization</a> – <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a><br/>
 	   	* <a href="http://projectlombok.org/">Project Lombok</a> – <a href="http://opensource.org/licenses/mit-license.php">MIT License</a></p>
     ]]></string>
+
+    <!-- AddAccountActivity -->
+    <string name="login_type_email">Login with email address</string>
+    <string name="login_type_email_description">Service details will be auto-detected by domain name. Example: myaccount@icloud.com</string>
+    <string name="login_type_url">Login with URL and user name</string>
+    <string name="login_type_url_description">Service details will be auto-detected by initial URL and user name. Mostly used for self-hosted services.</string>
+    
+    <string name="login_password">Password:</string>
+    
+    <string name="login_email_description">Please enter your email address. Its domain name will be used to auto-detect service settings.</string>
+    <string name="login_email_address">Email:</string>
+    
+    <string-array name="login_url_scheme">
+        <item>http://</item>
+        <item>https://</item>
+    </string-array>
+    <string name="login_http_warning">"If you don't use encryption (HTTPS), other people may easily intercept your login details, contacts and events."</string>
+    <string name="login_user_name">User name:</string>
+    <string name="login_base_url">Base URL (collections will be auto-detected):</string>
+    <string name="login_invalid_base_url">Invalid base URL: </string>
+    
+    <string name="select_collections">DAVdroid: Select collections</string>
+    <string name="neither_caldav_nor_carddav">No CalDAV-/CardDAV service is available at this location.</string>
+    <string name="add_account">Add account</string>
+    <string name="querying_server">Querying server. Please wait…</string>
+    <string name="what_to_sync">Which collections shall be synchronized?</string>
+    <string name="address_books">Address books</string>
+    <string name="calendars">Calendars</string>
+    <string name="select_address_book">Select up to one address book (tap again to unselect):</string>
+    <string name="select_calendars">Select your calendars:</string>
+    <string name="auth_preemptive">Preemptive authentication (recommended, but incompatible with Digest auth)</string>
+    
+    <string name="davdroid_help">DAVdroid Help</string>
+    <string name="show_sync_settings">Manage sync accounts</string>
+    <string name="show_website">DAVdroid Web site</string>
     
     <string name="account_details">Account details</string>
     <string name="account_name">Account name:</string>
@@ -117,6 +130,7 @@
     <string name="account_name_info">"Use your email address as account name because Android will use the account name as ORGANIZER field for events you create. You can't have two accounts with the same name.</string>
     <string name="read_only">read-only</string>
     
+    <string name="menu_settings">Settings</string>
     <string name="general_settings">General settings</string>
     <string name="debug_settings">Debug settings</string>
     <string name="disable_http_compression">Disable HTTP compression</string>
@@ -126,5 +140,5 @@
     <string name="network_logging_enabled">All network traffic is being logged verbosely (debug mode)</string>
     <string name="network_logging_disabled">Network traffic is not being logged</string>
     <string name="report_an_issue">Report an issue</string>
-
+    
 </resources>

src/at/bitfire/davdroid/resource/DavResourceFinder.java

@@ -151,7 +151,7 @@ public class DavResourceFinder implements Closeable {
 	 * @throws MalformedURLException when the user-given URI is invalid
 	 * @throws UnknownServiceURLException when no intial service URL could be determined
 	 */
-	URL getInitialURL(ServerInfo serverInfo, String serviceName) throws URISyntaxException, MalformedURLException {
+	public URL getInitialContextURL(ServerInfo serverInfo, String serviceName) throws URISyntaxException, MalformedURLException {
 		String	scheme = null,
 				domain = null;
 		int		port = -1;
@@ -220,7 +220,7 @@ public class DavResourceFinder implements Closeable {
 	 * @return	WebDavResource of current-user-principal for the given service, or null if it can't be found
 	 */
 	WebDavResource getCurrentUserPrincipal(ServerInfo serverInfo, String serviceName) throws URISyntaxException, IOException, NotAuthorizedException {
-		URL initialURL = getInitialURL(serverInfo, serviceName);
+		URL initialURL = getInitialContextURL(serverInfo, serviceName);
 		
 		// determine base URL (host name and initial context path)
 		WebDavResource base = new WebDavResource(httpClient,
@@ -235,12 +235,14 @@ public class DavResourceFinder implements Closeable {
 			if (wellKnown.getCurrentUserPrincipal() != null)
 				return new WebDavResource(wellKnown, wellKnown.getCurrentUserPrincipal());
 		} catch (NotAuthorizedException e) {
-			Log.d(TAG, "Well-known " + serviceName + " service detection not authorized", e);
+			Log.w(TAG, "Not authorized for well-known " + serviceName + " service detection", e);
 			throw e;
+		} catch (URISyntaxException e) {
+			Log.w(TAG, "Well-known" + serviceName + " service detection failed because of invalid URIs", e);
 		} catch (HttpException e) {
 			Log.d(TAG, "Well-known " + serviceName + " service detection failed with HTTP error", e);
 		} catch (DavException e) {
-			Log.d(TAG, "Well-known " + serviceName + " service detection failed at DAV level", e);
+			Log.w(TAG, "Well-known " + serviceName + " service detection failed with unexpected DAV response", e);
 		}
 
 		// fall back to user-given initial context path
@@ -249,18 +251,18 @@ public class DavResourceFinder implements Closeable {
 			if (base.getCurrentUserPrincipal() != null)
 				return new WebDavResource(base, base.getCurrentUserPrincipal());
 		} catch (NotAuthorizedException e) {
-			Log.d(TAG, "Not authorized for querying principal for " + serviceName + " service", e);
+			Log.e(TAG, "Not authorized for querying principal", e);
 			throw e;
 		} catch (HttpException e) {
-			Log.d(TAG, "HTTP error when querying principal for " + serviceName + " service", e);
+			Log.e(TAG, "HTTP error when querying principal", e);
 		} catch (DavException e) {
-			Log.d(TAG, "DAV error when querying principal for " + serviceName + " service", e);
+			Log.e(TAG, "DAV error when querying principal", e);
 		}
 		Log.i(TAG, "Couldn't find current-user-principal for service " + serviceName);
 		return null;
 	}
 	
-	private static boolean checkHomesetCapabilities(WebDavResource resource, String davCapability) throws URISyntaxException, IOException {
+	public static boolean checkHomesetCapabilities(WebDavResource resource, String davCapability) throws URISyntaxException, IOException {
 		// check for necessary capabilities
 		try {
 			resource.options();

src/at/bitfire/davdroid/syncadapter/AddAccountActivity.java

@@ -27,7 +27,7 @@ public class AddAccountActivity extends Activity {
 		
 		if (savedInstanceState == null) {	// first call
 			getFragmentManager().beginTransaction()
-				.add(R.id.fragment_container, new EnterCredentialsFragment(), "enter_credentials")
+				.add(R.id.fragment_container, new LoginTypeFragment(), "login_type")
 				.commit();
 		}
 	}

src/at/bitfire/davdroid/syncadapter/GeneralSettingsActivity.java

@@ -19,7 +19,7 @@ import android.view.MenuItem;
 import at.bitfire.davdroid.R;
 
 public class GeneralSettingsActivity extends Activity {
-	final static String URL_REPORT_ISSUE = "https://github.com/rfc2822/davdroid/blob/master/CONTRIBUTING.md"; 
+	final static String URL_REPORT_ISSUE = "https://github.com/bitfireAT/davdroid/blob/master/CONTRIBUTING.md#reporting-issues"; 
 	
 	@Override
 	public void onCreate(Bundle savedInstanceState) {

src/at/bitfire/davdroid/syncadapter/LoginEmailFragment.java

@@ -0,0 +1,103 @@
+package at.bitfire.davdroid.syncadapter;
+
+import java.net.URI;
+import java.net.URISyntaxException;
+
+import android.app.DialogFragment;
+import android.app.Fragment;
+import android.app.FragmentTransaction;
+import android.os.Bundle;
+import android.text.Editable;
+import android.text.TextWatcher;
+import android.view.LayoutInflater;
+import android.view.Menu;
+import android.view.MenuInflater;
+import android.view.MenuItem;
+import android.view.View;
+import android.view.ViewGroup;
+import android.widget.EditText;
+import at.bitfire.davdroid.R;
+
+public class LoginEmailFragment extends Fragment implements TextWatcher {
+	
+	protected EditText editEmail, editPassword; 
+	
+
+	@Override
+	public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
+		View v = inflater.inflate(R.layout.login_email, container, false);
+
+		editEmail = (EditText)v.findViewById(R.id.email_address);
+		editEmail.addTextChangedListener(this);
+		editPassword = (EditText)v.findViewById(R.id.password);
+		editPassword.addTextChangedListener(this);
+		
+		setHasOptionsMenu(true);
+		return v;
+	}
+
+	@Override
+	public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
+	    inflater.inflate(R.menu.only_next, menu);
+	}
+	
+	@Override
+	public boolean onOptionsItemSelected(MenuItem item) {
+		switch (item.getItemId()) {
+		case R.id.next:
+			FragmentTransaction ft = getFragmentManager().beginTransaction();
+			
+			Bundle args = new Bundle();
+			String email = editEmail.getText().toString();
+			args.putString(QueryServerDialogFragment.EXTRA_BASE_URI, "mailto:" + email);
+			args.putString(QueryServerDialogFragment.EXTRA_USER_NAME, email);
+			args.putString(QueryServerDialogFragment.EXTRA_PASSWORD, editPassword.getText().toString());
+			args.putBoolean(QueryServerDialogFragment.EXTRA_AUTH_PREEMPTIVE, true);
+			
+			DialogFragment dialog = new QueryServerDialogFragment();
+			dialog.setArguments(args);
+		    dialog.show(ft, QueryServerDialogFragment.class.getName());
+			break;
+		default:
+			return false;
+		}
+		return true;
+	}
+
+	
+	// input validation
+	
+	@Override
+	public void onPrepareOptionsMenu(Menu menu) {
+		boolean passwordOk = editPassword.getText().length() > 0,
+				emailOk = false;
+
+		String email = editEmail.getText().toString();
+		try {
+			URI uri = new URI("mailto:" + email);
+			if (uri.isOpaque()) {
+				int pos = email.lastIndexOf("@");
+				emailOk = pos != -1;
+			}
+		} catch (URISyntaxException e) {
+			// invalid mailto: URI
+		}
+		
+		MenuItem item = menu.findItem(R.id.next);
+		item.setEnabled(emailOk && passwordOk);
+	}
+	
+	@Override
+	public void beforeTextChanged(CharSequence s, int start, int count, int after) {
+	}
+
+	@Override
+	public void onTextChanged(CharSequence s, int start, int before, int count) {
+		getActivity().invalidateOptionsMenu();
+	}
+
+	@Override
+	public void afterTextChanged(Editable s) {
+	}
+
+}

src/at/bitfire/davdroid/syncadapter/LoginTypeFragment.java

@@ -0,0 +1,50 @@
+package at.bitfire.davdroid.syncadapter;
+
+import android.app.Fragment;
+import android.os.Bundle;
+import android.view.LayoutInflater;
+import android.view.Menu;
+import android.view.MenuInflater;
+import android.view.MenuItem;
+import android.view.View;
+import android.view.ViewGroup;
+import android.widget.RadioButton;
+import at.bitfire.davdroid.R;
+
+public class LoginTypeFragment extends Fragment {
+	
+	protected RadioButton btnTypeEmail, btnTypeURL;
+	
+
+	@Override
+	public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
+		View v = inflater.inflate(R.layout.login_type, container, false);
+		
+		btnTypeEmail = (RadioButton)v.findViewById(R.id.login_type_email);
+		btnTypeURL = (RadioButton)v.findViewById(R.id.login_type_url);
+		
+		setHasOptionsMenu(true);
+		
+		return v;
+	}
+	
+	@Override
+	public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
+	    inflater.inflate(R.menu.only_next, menu);
+	}
+	
+	@Override
+	public boolean onOptionsItemSelected(MenuItem item) {
+		switch (item.getItemId()) {
+		case R.id.next:
+			Fragment loginFragment = btnTypeEmail.isChecked() ? new LoginEmailFragment() : new LoginURLFragment();
+			getFragmentManager().beginTransaction()
+				.replace(R.id.fragment_container, loginFragment)
+				.addToBackStack(null)
+				.commitAllowingStateLoss();
+			return true;
+		default:
+			return false;
+		}
+	}
+}

src/at/bitfire/davdroid/syncadapter/LoginURLFragment.java

@@ -7,6 +7,11 @@
  ******************************************************************************/
 package at.bitfire.davdroid.syncadapter;
 
+import java.net.URI;
+import java.net.URISyntaxException;
+
+import org.apache.commons.lang.StringUtils;
+
 import android.app.DialogFragment;
 import android.app.Fragment;
 import android.app.FragmentTransaction;
@@ -27,19 +32,20 @@ import android.widget.EditText;
 import android.widget.Spinner;
 import android.widget.TextView;
 import at.bitfire.davdroid.R;
+import at.bitfire.davdroid.URLUtils;
 
-public class EnterCredentialsFragment extends Fragment implements TextWatcher {
-	String scheme;
+public class LoginURLFragment extends Fragment implements TextWatcher {
+	protected String scheme;
 	
-	TextView textHttpWarning;
-	EditText editBaseURI, editUserName, editPassword;
-	CheckBox checkboxPreemptive;
-	Button btnNext;
+	protected TextView textHttpWarning;
+	protected EditText editBaseURI, editUserName, editPassword;
+	protected CheckBox checkboxPreemptive;
+	protected Button btnNext;
 	
 
 	@Override
 	public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
-		View v = inflater.inflate(R.layout.enter_credentials, container, false);
+		View v = inflater.inflate(R.layout.login_url, container, false);
 		
 		// protocol selection spinner
 		textHttpWarning = (TextView) v.findViewById(R.id.http_warning);
@@ -60,7 +66,7 @@ public class EnterCredentialsFragment extends Fragment implements TextWatcher {
 		spnrScheme.setSelection(1);	// HTTPS
 
 		// other input fields
-		editBaseURI = (EditText) v.findViewById(R.id.login_authority_path);
+		editBaseURI = (EditText) v.findViewById(R.id.login_host_path);
 		editBaseURI.addTextChangedListener(this);
 		
 		editUserName = (EditText) v.findViewById(R.id.userName);
@@ -79,14 +85,25 @@ public class EnterCredentialsFragment extends Fragment implements TextWatcher {
 
 	@Override
 	public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
-	    inflater.inflate(R.menu.enter_credentials, menu);
+	    inflater.inflate(R.menu.only_next, menu);
 	}
 	
 	@Override
 	public boolean onOptionsItemSelected(MenuItem item) {
 		switch (item.getItemId()) {
 		case R.id.next:
-			queryServer();
+			FragmentTransaction ft = getFragmentManager().beginTransaction();
+			
+			Bundle args = new Bundle();
+			String host_path = editBaseURI.getText().toString();
+			args.putString(QueryServerDialogFragment.EXTRA_BASE_URI, URLUtils.sanitize(scheme + host_path));
+			args.putString(QueryServerDialogFragment.EXTRA_USER_NAME, editUserName.getText().toString());
+			args.putString(QueryServerDialogFragment.EXTRA_PASSWORD, editPassword.getText().toString());
+			args.putBoolean(QueryServerDialogFragment.EXTRA_AUTH_PREEMPTIVE, checkboxPreemptive.isChecked());
+			
+			DialogFragment dialog = new QueryServerDialogFragment();
+			dialog.setArguments(args);
+		    dialog.show(ft, QueryServerDialogFragment.class.getName());
 			break;
 		default:
 			return false;
@@ -94,23 +111,6 @@ public class EnterCredentialsFragment extends Fragment implements TextWatcher {
 		return true;
 	}
 
-	void queryServer() {
-		FragmentTransaction ft = getFragmentManager().beginTransaction();
-		
-		Bundle args = new Bundle();
-		
-		String authority_path = editBaseURI.getText().toString();
-		//args.putString(QueryServerDialogFragment.EXTRA_BASE_URI, URIUtils.sanitize(scheme + host_path));
-		args.putString(QueryServerDialogFragment.EXTRA_BASE_URI, scheme + authority_path);
-		args.putString(QueryServerDialogFragment.EXTRA_USER_NAME, editUserName.getText().toString());
-		args.putString(QueryServerDialogFragment.EXTRA_PASSWORD, editPassword.getText().toString());
-		args.putBoolean(QueryServerDialogFragment.EXTRA_AUTH_PREEMPTIVE, checkboxPreemptive.isChecked());
-		
-		DialogFragment dialog = new QueryServerDialogFragment();
-		dialog.setArguments(args);
-	    dialog.show(ft, QueryServerDialogFragment.class.getName());
-	}
-
 	
 	// input validation
 	
@@ -120,15 +120,15 @@ public class EnterCredentialsFragment extends Fragment implements TextWatcher {
 			editUserName.getText().length() > 0 &&
 			editPassword.getText().length() > 0;
 
-		/*if (ok)
+		if (ok)
 			// check host name
 			try {
-				URI uri = new URI(URIUtils.sanitize(scheme + editBaseURI.getText().toString()));
+				URI uri = new URI(URLUtils.sanitize(scheme + editBaseURI.getText().toString()));
 				if (StringUtils.isBlank(uri.getHost()))
 					ok = false;
 			} catch (URISyntaxException e) {
 				ok = false;
-			}*/
+			}
 			
 		MenuItem item = menu.findItem(R.id.next);
 		item.setEnabled(ok);

src/at/bitfire/davdroid/syncadapter/QueryServerDialogFragment.java

@@ -113,7 +113,7 @@ public class QueryServerDialogFragment extends DialogFragment implements LoaderC
 			} catch (URISyntaxException e) {
 				serverInfo.setErrorMessage(getContext().getString(R.string.exception_uri_syntax, e.getMessage()));
 			}  catch (IOException e) {
-				serverInfo.setErrorMessage(getContext().getString(R.string.exception_io, e.getLocalizedMessage()));
+				serverInfo.setErrorMessage(getContext().getString(R.string.login_exception_io, e.getLocalizedMessage()));
 			} catch (HttpException e) {
 				Log.e(TAG, "HTTP error while querying server info", e);
 				serverInfo.setErrorMessage(getContext().getString(R.string.exception_http, e.getLocalizedMessage()));

src/at/bitfire/davdroid/syncadapter/SelectCollectionsFragment.java

@@ -71,7 +71,7 @@ public class SelectCollectionsFragment extends ListFragment {
 	
 	@Override
 	public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
-	    inflater.inflate(R.menu.select_collections, menu);
+	    inflater.inflate(R.menu.only_next, menu);
 	}
 	
 	@Override

test/src/at/bitfire/davdroid/syncadapter/DavResourceFinderTest.java

@@ -2,6 +2,7 @@ package at.bitfire.davdroid.syncadapter;
 
 import java.io.IOException;
 import java.net.URI;
+import java.net.URL;
 import java.util.List;
 
 import android.test.InstrumentationTestCase;
@@ -52,5 +53,18 @@ public class DavResourceFinderTest extends InstrumentationTestCase {
 		assertEquals("Work Calendar", resource.getTitle());
 		assertTrue(resource.isReadOnly());
 	}
+	
+	
+	public void testGetInitialContextURL() throws Exception {
+		// without SRV records, but with well-known paths
+		ServerInfo roboHydra = new ServerInfo(new URI(Constants.ROBOHYDRA_BASE), "test", "test", true);
+		assertEquals(new URL(Constants.roboHydra, "/"), finder.getInitialContextURL(roboHydra, "caldav"));
+		assertEquals(new URL(Constants.roboHydra, "/"), finder.getInitialContextURL(roboHydra, "carddav"));
+		
+		// with SRV records and well-known paths
+		ServerInfo iCloud = new ServerInfo(new URI("mailto:test@icloud.com"), "", "", true);
+		assertEquals(new URL("https://contacts.icloud.com/"), finder.getInitialContextURL(iCloud, "carddav"));
+		assertEquals(new URL("https://caldav.icloud.com/"), finder.getInitialContextURL(iCloud, "caldav"));
+	}
 
 }