[whatwg] Calendar subscription as a feed?
dmose at mozilla.org
Fri Feb 8 19:12:05 PST 2008
Mikko Rantalainen wrote:
> Currently it seems that there are two practical ways to link to a
> iCalendar file; one may distribute the .ics file via HTTP or with
> "webcal" protocol (which, if I've understood correctly, is just HTTP
> with different protocol name to help with binding with correct program).
> So I can write
> <a href="webcal://example.com/feed.ics">Subscribe events</a>
> <a href="http://example.com/feed.ics">Download events</a>
> However, both of these URLs could really be used for subscriptions.
From what I've seen, the semantic that's generally used in the wild is
(http:, text/calendar) means "download/import", and using webcal: means
> Should I mark up those as feeds? Should calendar feeds have different
> "rel" type than "feed"? Is it okay to write something like
> <a href="http://example.com/feed.ics" rel="feed"
> type="text/calendar">Calendar feed</a>?
> The "feed" keyword is defined as "the feed keyword indicates that the
> referenced document is a syndication feed" at
> http://www.whatwg.org/specs/web-apps/current-work/#link-type5 - is a
> calendar feed a "syndication feed"?
If this issue were only interesting around calendars, one could argue
that the existing setup is sufficient. However, it seems complex and
error-prone to require that every content-type for which a "subscribe"
semantic would be useful should get its own URI scheme. Allowing
rel="feed" to apply to any content type as you suggest seems like a
fairly reasonable idea to me.
One nice property of the webcal: URI scheme is that any user-agent can
reasonably infer the intended use (which is likely to carry the semantic
that the URI will be around for a longer period of time) simply from the
URI. So this URI can simply be included in any sort document (mail
message, text file) without losing that bit of information. By itself,
rel="feed" doesn't provide this.
One way to address this problem might be generalizing "webcal:" to a
"subscribe:" URI scheme. Another possibility might be to add an HTTP
header, or maybe a parameter to Content-Disposition.
At some level, this last option seems the most elegant. And it could
certainly be done in concert with allowing rel="feed" with any content-type.
More information about the whatwg