Skip to main content

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

Yes

(Alexey Melnikov)

No Objection

(Dan Romascanu)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Tim Polk)

Note: This ballot was opened for revision 10 and is now closed.

Alexey Melnikov Former IESG member
Yes
Yes () Unknown

                            
Peter Saint-Andre Former IESG member
Yes
Yes (2010-09-08) Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection (2010-09-08) Unknown
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"?
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2010-09-08) Unknown
Section 1., paragraph 3:
>    (RRs).  This has been enhanced to provide addition al service meta-

  Nit: s/addition al/additional/
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (2010-09-09) Unknown
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?
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown