[ietf-caldav] SRV lookup for CalDAV
cyrus at daboo.name
Sun May 24 13:03:50 PDT 2009
--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,
> - 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
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)
More information about the ietf-caldav