Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
draft-daboo-srv-caldav-10

[Ballot comment]
1) Using redirection to actual data (rather than metadata) for the well-known mechanism surprised me. I don't think that concept was captured at all in rfc5785 (draft-nottingham-site-meta).

2) Mandating a 301 for redirection might have unintended consequences (with caching and with clients remembering the redirection forever). Consider adding advice on controlling caches. I understand that in normal expected behavior, this lookup will only be done once, but if an account is deleted/re-added and the lookup needs to be run again, do you want the earlier redirect (which might have occurred years earlier) to be honored?

[Ballot comment]
1. In Section 6, Step 2 says: "In this situation clients MUST first attempt an HTTP connection with transport layer security." However, the document does not specify what is meant by "transport layer security" (e.g., does this mean either SSL or TLS?). See also the first paragraph of Section 8.

2. There was some discussion on the apps-discuss@ietf.org list about the fact that this specification does not use a technology that enables discovery of URIs, such as U-NATPR or the (proposed) URI RR. It might be reasonable to discuss the design decisions that led to the current approach.

[Ballot comment]
In Section 6, Step 2 says: "In this situation clients MUST first attempt an HTTP connection with transport layer security." However, the document does not specify what is meant by "transport layer security" (e.g., does this mean either SSL or TLS?). See also the first paragraph of Section 8.

[Ballot discuss]
INTRODUCTION, paragraph 1:
> Updates: 4791,XXXX-CardDAV

  DISCUSS: What's XXXX-CardDAV? (Is there a Note to the RFC Editor
  missing? Is there a reference missing?)

[Ballot comment]
Section 1

  Another issue with CalDAV or CardDAV service discovery is that the
  service may not be located at the "root" URI of the HTTP server
  hosting it.

Is that "may not" or "might not"?

Shepherd write-up for: draft-daboo-srv-caldav-08
Intended status: Proposed

  (1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this version
      is ready for forwarding to the IESG for publication?

      Bernard Desruisseaux  is
      shepherding this document. The document is ready for forwarding
      to the IESG.

  (1.b)  Has the document had adequate review both from key members of
      the interested community and others?  Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews
      that have been performed?

      This document has been discussed and reviewed on the WebDAV
      (w3c-dist-auth@w3c.org), CalDAV (ietf-caldav@osafoundation.org)
      and VCardDAV (vcarddav@ietf.org) mailing lists.

  (1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

      No concerns.

  (1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document,
      or has concerns whether there really is a need for it.  In any
      event, if the interested community has discussed those issues
      and has indicated that it still wishes to advance the document,
      detail those concerns here.

      No concerns.

  (1.e)  How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a
      few individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

      The document has been specifically reviewed by a few
      individuals. There has been open discussion on the mailing
      lists. IETF last call brought a flurry of comments related to
      general issues with DNS-based service discovery, though most
      agreed that this specification should continue as-is and not
      be blocked on potential future work. Some changes based on last
      call feedback were applied to the draft.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict
      in separate email messages to the Responsible Area Director.
      (It should be in a separate email because this questionnaire
      is entered into the ID Tracker.)

      No discontent.

  (1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

      Yes.

  (1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents
      that are not ready for advancement or are otherwise in an
      unclear state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If so,
      list these downward references to support the Area Director in
      the Last Call procedure for them [RFC3967].

      Yes. Three normative references are to drafts. One of those
      has been approved by the IESG (CardDAV), one (dnsext-dns-sd)
      has been reviewed by the IESG and is waiting for an update,
      the other (tls-server-id-check) is still being worked on.

  (1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document?  If the document specifies protocol extensions,
      are reservations requested in appropriate IANA registries?
      Are the IANA registries clearly identified?  If the document
      creates a new registry, does it define the proposed initial
      contents of the registry and an allocation procedure for future
      registrations?  Does it suggested a reasonable name for the
      new registry?  See [I-D.narten-iana-considerations-rfc2434bis].
      If the document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

      IANA actions to register two new well-known URIs are described.

  (1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

      Yes.

  (1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary

      This draft defines how SRV records and TXT records can be used
      to discover CalDAV and CardDAV services on the internet. It
      also describes how those can be used to "bootstrap" clients
      during accounts setup using well-known URIs and other
      standards features of WebDAV.

      Discussion Summary

      Discussion has taken place on various mailing lists since
      the -00 draft was published a year ago.

      Document Quality

      This document is designed to address a clear need for
      standardized client account auto-discovery based on
      interoperability problems in current client/server solutions
      for CalDAV and CardDAV. Many of the existing CalDAV and
      CardDAV client and server developers have indicated strong
      interest in supporting this, and several have already
      implemented this draft.

IANA questions/comments:

IANA has a question about action #2.

ACTION 1:

First, in the Well-Known URIs registry located at
http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
two new Well-Known URIs will be added:

URI suffix: caldav
Change controller: IETF.
Specification document(s):
Related information: See also [RFC4791].

URI suffix: carddav
Change controller: IETF.
Specification document(s):
Related information: See also [I-D.ietf-vcarddav-carddav].


ACTION 2:

The document says, "IANA is requested to add 'caldav' and 'caldavs'
service labels as aliases for 'http' and 'https' respectively."
IANA's question is: in what registry are these service labels to be
added? If they should be added at
http://www.iana.org/assignments/service-names, what's the description
for each name? And should anything be added in the port numbers registry?

All AD review comments but one (see below) were addressed in -05.

5.  Client "Bootstrapping" Guidelines

  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.

Is SHOULD too strong here?

Cyrus replied that if SHOULD is changed to MAY, then the Email SRV document needs to be updated to match. I tend to agree.
Still deciding if this change should be made.

AD review of the document:

I think the document should include "Updates: RFC XXXX, YYYY" where XXXX and YYYY are CardDav and CalDav respectively. This is similar to what we did with the Email SRV document.

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]).

These service names need to be registered in the IANA Considerations. They should be aliases to "http", the same way we've done for CardDav.

  Clients SHOULD honor "Priority" and "Weight" values in the SRV RRs,
  as described by [RFC2782].

Why is this a SHOULD and not a MUST?

5.  Client "Bootstrapping" Guidelines

  If the calendar user address is an "http:" [RFC2616] or "https:"
  [RFC2818] URI, the "userinfo" and "host" portion of the URI is
  extracted.

I think a pointer to RFC 3986 is going to be good here, because "userinfo" and "host" are defined in RFC 3986 and not in RFC 2616.

o  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.  Certificate verification MUST use the procedure
    outlined in Section 4.3

I think this should point to Section 3.

    of [I-D.saintandre-tls-server-id-check] in
    regard to verification with an SRV RR as the starting point.

  o  The client does an initial "PROPFIND" [RFC4918] request with a
    request URI of "/.well-known/caldav" (for CalDAV) or "/.well-
    known/carddav" (for CardDAV).  The body of the request should
    include the DAV:current-user-principal [RFC5397] property as one
    of the properties to return.

In the last sentence: s/should/SHOULD? If you agree, then RFC 5397 becomes Normative.

  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.

Is SHOULD too strong here?


6.  Guidance for Service Providers

  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.3 of

As above, this should be section 3.

    [I-D.saintandre-tls-server-id-check] in regard to verification
    with an SRV RR as the starting point.

7.  Security Considerations

  Alternatively, if transport layer security is being used for the
  service, clients MUST use the procedure outlined in Section 4.3 of
  [I-D.saintandre-tls-server-id-check] to verify the service.

As above, this should be section 3.

10.2.  Informative References

  [RFC3744]                            Clemm, G., Reschke, J., Sedlar,
                                        E., and J. Whitehead, "Web
                                        Distributed Authoring and
                                        Versioning (WebDAV)
                                        Access Control Protocol",
                                        RFC 3744, May 2004.

  [RFC5322]                            Resnick, P., Ed., "Internet
                                        Message Format", RFC 5322,
                                        October 2008.

I think these 2 references are Normative.