Re: [whatwg] Calendar subscription as a feed?

[Mikko Rantalainen]

Dan Mosedale wrote:
 Dan Mosedale wrote:
 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.

 I just skimmed the slightly (2006) Link header draft after noticing Ian 
 mentioning it in a recent thread here, and if that were to make it back 
 into HTTP, it would seem to solve this information loss bit nicely.

Could you elaborate how one could use Link header to prevent information
loss?

In cases where one user sends a http://...; URI to another user in e.g.
plain text email message how can a Link header prevent loss of
information when compared to webcal: URI?

We already have +xml suffix for mimetypes, perhaps we should also have
+subscription or +feed? Or did you mean that similar information
would be encoded as Link header?

-- 
Mikko



signature.asc
Description: OpenPGP digital signature

Re: [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.icsSubscribe 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/calendarCalendar 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

Re: [whatwg] Calendar subscription as a feed?

[Dan Mosedale]

Dan Mosedale wrote:
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.
I just skimmed the slightly (2006) Link header draft after noticing Ian 
mentioning it in a recent thread here, and if that were to make it back 
into HTTP, it would seem to solve this information loss bit nicely.


Dan