[ietf-caldav] SRV lookup for CalDAV

Cyrus Daboo cyrus at daboo.name
Sun May 24 13:03:50 PDT 2009

Hi Helge,

--On May 24, 2009 9:29:55 PM +0200 Helge Hess 
<helge.hess at opengroupware.org> wrote:

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

A limit that would be solved eventually by the URI RR scheme. But for now 
it can work via virtual domains and redirects.

> 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".

I think what I want to do is update the current-user-principal spec to 
require the server to always challenge the client if a PROPFIND for 
current-user-principal is detected, even on a resource that normally allows 
anonymous access. Maybe that could go in this spec too. With that a client 
doing the PROPFIND would be challenged and things would then work as 

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

It won't cover 100% of situations, but it will help in a lot of them.

> b) is not exactly perfect from an HTTP perspective, not a particulary
>     good HTTP way to bootstrap (IMHO)

In the longer term I think the URI RR is a better bet - but realistically 
it will take a long time for a new RR scheme to deploy to the point where 
it can be used.

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

Cyrus Daboo

More information about the ietf-caldav mailing list