[ietf-caldav] SRV lookup for CalDAV
helge.hess at opengroupware.org
Sun May 24 12:29:55 PDT 2009
On 22.05.2009, at 04:51, Cyrus Daboo wrote:
> I have just submitted
> This draft defines new SRV service types for use with CalDAV to
> allow clients to discover CalDAV servers.
> Comments welcome...
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,
- 4.2: the client resends the PROPFIND with authentication
Something like that. It should be more than "The client does an
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
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)
More information about the ietf-caldav