- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 12 Jan 2007 10:46:06 +0100
- To: werner.donne@re.be
- CC: Jay Daley <jay@nominet.org.uk>, w3c-dist-auth@w3.org
Werner Donné schrieb: > > Hi, > > Implementing an efficient client is a challenge if you have to > discover the capabilities at run-time. Either you end up with Where exactly would a "webdav" scheme help here? Can you give a definition what information it would provide? Would I be allowed to use it for resources that just support PROPFIND, for instance? -> Granularity problem, for once. > a lot of OPTIONS method calls or a lot of state to avoid them. > Another alternative is recovery code for failures all over the > place, because you can't just fail without telling the user > in a proper way what the problem is, which depends on the > scenario he is in. "Not implemented" is not good enough when That's why the newer WebDAV specs provide DAV:error. And again, how would a different URI scheme help here? > it is about something deep inside some logic that the user has > triggered, because he will not be able to related it to what > he did. > > Why exactly what Apple did was a mistake? For once, because they forced new identifiers on the web, without taking care of specifying what they mean (or did I miss a scheme registration?). As far as I can tell, the only way they differ from HTTP URLs is that Apple's software uses them to invoke a different user agent. You don't need an URI scheme for that, a MIME type works just fine (see, for instance, <http://greenbytes.de/tech/webdav/rfc4709.html#rfc.section.A.2>). Best regards, Julian
Received on Friday, 12 January 2007 09:52:53 UTC