Subject: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis)

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Aug 2008 10:11:44 +0200

Hi,

I've got a quick question about the iCalendar format, or actually an idea.

If I serve an iCalendar resource through HTTP, what I really want is to 
allow the client not only to read it (display it in a calendar 
application), but also to *subscribe* to it, for which I obviously need 
the URI.

Apple, years ago, "solved" this (and potentially some other use cases) 
with their custom "webcal" URI scheme. (I note that this URI scheme 
hasn't been registered with IANA.)

The Atom WG was smarter, by allowing the format to carry a "self" URI, 
for subscription (see 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2>).

Bernard already pointed me to the URL property 
(<http://tools.ietf.org/html/rfc2445#section-4.8.4.6>), but what I'm 
looking for is a Calendar property, not a Component property (I think).

Is something like that possible in iCalendar? If not, could/should it be 
added? (Separate document?)

BR, Julian

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Helge Hess <[email-masked]>
Date: Fri, 22 Aug 2008 10:24:43 +0200

Julian,

I'm not sure what you mean by 'subscribe' in the context. Do you want  
some kind of feed which is based on the iCal format? That is,  
subsequent GETs on that feed URL only return changed items?

Subscribe in the iCal-over-HTTP context is just using that URL, cache  
it and do proper if-none-match: etag requests to keep it up to date.  
Thats no different to the subscription of regular RSS feeds.

I don't think that adding such URLs to the content format is good. It  
blurs the boundaries between protocol (HTTP) and the payload (iCal).

Greets,
   Helge

PS: I never understood why Apple needed the 'webcal' URI scheme. I  
guess it was just a quick hack. It was probably easier to activate an  
OSX application by URL than by the content-type of the URL entity.

On 22.08.2008, at 10:11, Julian Reschke wrote:
> If I serve an iCalendar resource through HTTP, what I really want is  
> to allow the client not only to read it (display it in a calendar  
> application), but also to *subscribe* to it, for which I obviously  
> need the URI.
>
> Apple, years ago, "solved" this (and potentially some other use  
> cases) with their custom "webcal" URI scheme. (I note that this URI  
> scheme hasn't been registered with IANA.)
>
> The Atom WG was smarter, by allowing the format to carry a "self"  
> URI, for subscription (see <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2 
> >).
>
> Bernard already pointed me to the URL property (<http://tools.ietf.org/html/rfc2445#section-4.8.4.6 
> >), but what I'm looking for is a Calendar property, not a Component  
> property (I think).
>
> Is something like that possible in iCalendar? If not, could/should  
> it be added? (Separate document?)

-- 
Helge Hess
http://helgehess.eu/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Aug 2008 10:46:44 +0200

Helge Hess wrote:
> some kind of feed which is based on the iCal format? That is, subsequent 
> GETs on that feed URL only return changed items?

No, not a feed. Just the current state of the calendar. Exactly what you 
get when you subscribe (for instance) to a Google Calendar in 
Thunderbird, using "http" (not caldav).

> Subscribe in the iCal-over-HTTP context is just using that URL, cache it 
> and do proper if-none-match: etag requests to keep it up to date. Thats 
> no different to the subscription of regular RSS feeds.
> 

But it's the only way of opening the calendar in an application other 
than the browser *and* giving that application the original URL (at 
least in the operating systems I'm aware of).

> Greets,
>   Helge
> 
> PS: I never understood why Apple needed the 'webcal' URI scheme. I guess 
> it was just a quick hack. It was probably easier to activate an OSX 
> application by URL than by the content-type of the URL entity.

It addresses exactly this problem. If the iCalendar object doesn't 
contain the URL it came from, the calendar application lacks that 
essential piece of information.

BR, Julian

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 22 Aug 2008 08:06:31 -0400

If you want a subscription experience, you could embed the URL of the .ics
file in an Atom feed, couldn't you, and take advantage of the "self"
property for the feed?

As an aside, there's a TC-XML at Calconnect.org which is discussing XML
representation of iCalendar; this sort of thing might be of interest to
them.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Friday, August 22, 2008 4:47 AM
To: Helge Hess
Cc: IETF-iCalendar
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal
related to 2445bis)

> subsequent GETs on that feed URL only return changed items?

No, not a feed. Just the current state of the calendar. Exactly what you get
when you subscribe (for instance) to a Google Calendar in Thunderbird, using
"http" (not caldav).

> blurs the boundaries between protocol (HTTP) and the payload (iCal).

But it's the only way of opening the calendar in an application other than
the browser *and* giving that application the original URL (at least in the
operating systems I'm aware of).

> OSX application by URL than by the content-type of the URL entity.

It addresses exactly this problem. If the iCalendar object doesn't contain
the URL it came from, the calendar application lacks that essential piece of
information.

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Fri, 22 Aug 2008 18:27:47 +0200

On 22.08.2008, at 10:46, Julian Reschke wrote:
> No, not a feed. Just the current state of the calendar. Exactly what  
> you get when you subscribe (for instance) to a Google Calendar in  

OK.

>>
> But it's the only way of opening the calendar in an application  
> other than the browser *and* giving that application the original  
> URL (at least in the operating systems I'm aware of).

I still don't get it. Can't you configure the browser to open your  
calendaring application for the text/calendar content type? The  
browser can invoke the application with the URL?
(I'm pretty sure that Mozilla allows that, and IE definitely does open  
by URL when you invoke a Word document for example, so it should also  
work there, somehow)

> essential piece of information.

Yes, but in what case would you download a calendar via URL and then  
use the same URL again to re-download the same entity. That just  
doesn't make a lot sense? :-)
Its really just a hack around an improper configuration of the URL/app  
activation system.

Well, maybe the hack is worth it. But in this case I would prefer a webcal:// 
  scheme over an iCal embedded URL, to preserve the layering between  
content and transport.

Thanks,
   Helge

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Aug 2008 18:51:35 +0200

Helge Hess wrote:
> calendaring application for the text/calendar content type? The browser 
> can invoke the application with the URL?

The default is that the browser stores the content into a local 
temporary file, and then invokes the application with the file name.

I do recall that MS IE has a way to actually pass the URL instead of the 
document, but when I researched this a long time ago, I couldn't figure 
out how that works.

So let me know if you can convince one of these UAs to pass the URL, 
that would be an interesting outcome of this discussion as well.

> Yes, but in what case would you download a calendar via URL and then use 
> the same URL again to re-download the same entity. That just doesn't 
> make a lot sense? :-)

Well, it would only happen once: you GET the calendar resource with your 
browser, which passes it to the calendar application. That application 
can then discover the "self" link, and offer to subscribe to the 
calendar. From there on, you would always use the calendar application 
to access the calendar.

> Its really just a hack around an improper configuration of the URL/app 

It's a workaround for a missing feature in current UAs.

> Well, maybe the hack is worth it. But in this case I would prefer a 
> webcal:// scheme over an iCal embedded URL, to preserve the layering 
> between content and transport.

<http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-scheme>:

"Good practice: Reuse URI schemes

A specification SHOULD reuse an existing URI scheme (rather than create 
a new one) when it provides the desired properties of identifiers and 
their relation to resources."

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 22 Aug 2008 13:03:05 -0400

Hi Julian,

--On August 22, 2008 6:51:35 PM +0200 Julian Reschke 
<[email-masked]> wrote:

> calendar. From there on, you would always use the calendar application to
> access the calendar.

By this argument then, any data handed off from a browser to another 
application should include the original URL embedded in it because the 
other app may want to re-fetch. So I think this is more an issue for the 
OS/Application URL hand-off process. The URL where the data originally came 
from ought to be attached to the file, or data stream, as meta-data.

-- 
Cyrus Daboo

---

From: Helge Hess <[email-masked]>
Date: Fri, 22 Aug 2008 19:07:38 +0200

On 22.08.2008, at 18:51, Julian Reschke wrote:
> I do recall that MS IE has a way to actually pass the URL instead of  
> the document, but when I researched this a long time ago, I couldn't  
> figure out how that works.

I couldn't find it in a quick search either, but I'm pretty sure its  
supposed to work. But then maybe not :-):

   http://bitworking.org/news/Atom_Auto_Sub_How_To

OK. Another way would be to deliver a different content-type which  
contains the iCal URL. Something like this:
--snip--
Content-type: application/x-url-to-open

http://site/file.ics
--snap--
Could be a generic 'URL reference' MIME type, or something text/ 
calendar specific.

> A specification SHOULD reuse an existing URI scheme (rather than  
> create a new one) when it provides the desired properties of  
> identifiers and their relation to resources."

Its also good practice not to mix transport with content :-)

OK, what about my special-reference entity suggestion then?

Thanks,
   Helge

PS: hey! you are supposed to do CalDAV anyways! and download of full  
vcals via HTTP ;-)
-- 
Helge Hess
http://helgehess.eu/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Aug 2008 19:14:08 +0200

Cyrus Daboo wrote:
> OS/Application URL hand-off process. The URL where the data originally 
> came from ought to be attached to the file, or data stream, as meta-data.

I agree that it would be totally cool if it worked that way. But as far 
as I can tell, it doesn't.

I'd love to learn how to configure IE/FF/Safari to do this. Maybe this 
is something for the (gasp) HTML5 WG to consider?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Aug 2008 19:20:27 +0200

>   http://bitworking.org/news/Atom_Auto_Sub_How_To

Yes. That one inspired me to do RFC 4709.

> Could be a generic 'URL reference' MIME type, or something text/calendar 
> specific.

It would need to be specific, otherwise you can't dispatch to the right 
application. See RFC 4709 :-).

> OK, what about my special-reference entity suggestion then?

That would work as well, and this is what I've been using for launching 
WebDAV clients (successfully).

The "embed-the-source" approach works as well if content is being 
transferred anyway, and this is what Atom (RFC4287) uses.

> PS: hey! you are supposed to do CalDAV anyways! and download of full 

But, as far as I can tell, this has the same problem. How do you send a 
URL to a CalDAV calendar in an email? How does a Web server implement 
the "subscribe this with Caldav" functionality?

As a matter of fact, my original proposal would work in that case as well.

A CalDAV-aware client could do OPTIONS on the URI first, and check for 
CalDAV support, and then do "the right thing".

BR, Julian