[whatwg] Calendar subscription as a feed?

[Dan Mosedale]

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>
> or
> <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 
"subscribe".
> 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.

Thoughts?

Dan