[ietf-caldav] SRV lookup for CalDAV

[Helge Hess]

On 22.05.2009, at 04:51, Cyrus Daboo wrote:
> I have just submitted
> <http://www.ietf.org/internet-drafts/draft-daboo-srv-caldav-00.txt>.  
> This draft defines new SRV service types for use with CalDAV to  
> allow clients to  discover CalDAV servers.
>
> Comments welcome...

Two things:

a) since the SRV is defined for root URLs only, it (IMHO) makes it
    useless in a lot of setups/scenarios
    [as discussed before, DNS does not really allow for more in
     that specific setup]

the bigger (standards) flaw IMHO is this:

b) 4, point 4: "The client does an authenticated "PROPFIND"

This is not how HTTP works. In HTTP the server *may* trigger  
authentication, not the client. The client only responds with  
'authentication' if the server requested that.

This affects point 5. Since a client can't enforce authentication (in  
a standard way) a server might respond 207 to the PROPFIND w/o  
authentication. Giving back an current-user-principal which represents  
the anonymous/'public' user (which makes a lot of sense, eg check the  
Zope security system).

IMHO point 4 should be at least split into those points to make it  
clear for implementors:
- 4.0: the client sends a PROPFIND
- 4.1: the server MUST responds with 401 to trigger authentication,
        unless the PROPFIND already contained suitable, NON-PUBLIC,
        authentication
- 4.2: the client resends the PROPFIND with authentication
...
Something like that. It should be more than "The client does an  
authenticated "PROPFIND".


Personally I'm not sure whether its worth putting the draft into a RFC.
a) does not make it suitable for a lot of real world setups (for
    plenty of reasons, including software ones, and web hosting
    scenarios)
b) is not exactly perfect from an HTTP perspective, not a particulary
    good HTTP way to bootstrap (IMHO)

I would prefer a draft which solves a) (DNS NAME records or something,  
don't remember ;-). I think I would be OK with b), though it is a bit  
fishy wrt HTTP.

(Both things can be made working if the admin has full access to the  
system, but this is getting less and less common)

Greets,
   Helge
-- 
Helge Hess
http://helgehess.eu/