[Ietf-caldav] Going from browser to application
lisa at osafoundation.org
Wed May 17 17:20:23 PDT 2006
I don't quite make sense of your scenario as an application of the
davmount scheme. What I meant to convey, was that calendars might
also usefully be advertised in Web pages and other content that
contains links. That's where the HTML comes in.
If I were to follow Julian's example for calendaring but start from
scratch (leaving aside the alternative of actually extending
davmount), here's what I might propose, combining workflow and
examples with mechanics:
1. An HTTP URL for a "calendar info file" would appear online on my
Web page (or in an email, or in a Web page listing several peoples'
E.g. <a href="http://example.com/users/lisa/calendars/work-calendar-
2. The "calendar info file" would be a *new* resource beyond those
already described in CalDAV. It might be a sibling resource of a
CalDAV calendar collection (though it could live anywhere, even a
different server modulo security considerations). It would have a
MIME type something like application/caldav-calendar+xml (assuming
XML) so that the browser would be caused to dispatch the whole file
to an application registered as handling that MIME type.
3. Inside it would be at a minimum, the URL of the calendar that was
advertised -- because when this file is downloaded by a browser, the
browser sends the file to a calendar application that doesn't know
the URL where the file came from! We might also think of additional
helpful information that could go in that file, e.g. even before the
calendar application does an OPTIONS or a PROPFIND on the href given,
the calendar application might want to prompt the user depending on
"Opening: calendar for 'Lisa Dusseault'. Do you want to view,
subscribe or import?"
thus the insides of the file might look like this (omitting
namespaces and other niceties, and inventing capabilities out of thin
On May 17, 2006, at 11:11 AM, Wilfredo Sánchez Vega wrote:
> I'm leaning with Mike at the moment, but maybe I don't understand
> how the davmount scheme would help me here. Specifically, I don't
> know what the client/server exchange would look like given that we
> aren't starting at a hypertext document as in the section 4 example
> in the mount draft. In the calendar case, you start with iCalendar
> text, not HTML:
> 1- Client retrieves representation of CalDAV resource "/calendars/
> GET /user42/inbox/ HTTP/1.1
> Host: www.example.com
> 2- Server returns representation.
> HTTP/1.1 200 OK
> Content-Type: text/iCalendar
> Content-Length: xxx
> 3- What happens here?
> There is no link for the use to click on here. In your example,
> the server sent back some HTML. The user is shows that document,
> and has to then click on a link to make the desired action happen.
> In our case, the browser got some iCalendar data, and there's
> really no good place for the server to shove in a link, nor would
> it really want to if it could.
> Now as an alternate example, the client might start with the
> calendar collection resource, rather than with one of the iCalendar
> resources contained in it. The server is free to send back any
> data it wants to on a GET response in that case, so it could send
> back HTML. But a server might want to instead send back monolithic
> iCalendar data for the entire calendar so that existing calendar
> clients (eg. Apple's iCal) can use that URL.
> So that leaves a server having to choose between supporting a
> legacy calendar client, or supporting a generic (HTML-centric) web
> browser. Or doing a bunch of user-agent matching, because iCal
> wasn't smart enough to send an Accept: header and web browsers
> don't send useful Accept: headers.
> Am I misunderstanding how the mount scheme would fit in here?
> Ietf-caldav mailing list -- Ietf-caldav at osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ietf-caldav