[Cosmo-dev] Cosmo and Scooby URLs

[Lisa Dusseault]

On Jun 16, 2006, at 5:16 PM, Mikeal Rogers wrote:

> Ok, I thought of another way to do this that will satisfy everyone.
>
> Since it's so lost in the thread here is what bobby initially  
> suggested:
>
> <link rel="alternate" type="application/atom+xml" title="Home  
> Calendar (Atom 0.3)" href="http://cosmo-demo.osaf.org/atom/bobby/ 
> HomeCalendar" />
> <link rel="alternate" type="application/rss+xml" title="Home  
> Calendar (RSS)" href="http://cosmo-demo.osaf.org/rss/bobby/ 
> HomeCalendar" />
> <link rel="alternate" type="application/caldav" title="Home  
> Calendar (CalDAV)" href="http://cosmo-demo.osaf.org/dav/bobby/ 
> HomeCalendar" />
> <link rel="alternate" type="application/webcal" title="Home  
> Calendar (Webcal)" href="http://cosmo-demo.osaf.org/webcal/bobby/ 
> HomeCalendar" />
>
> Instead of forwarding requests from one app to another, or merging  
> them, let's just create another link in cosmo.
>
> <link rel="alternate" type="application/magic" title="Home Calendar  
> (Magic)" href="http://cosmo-demo.osaf.org/magic/bobby/HomeCalendar" />
>
> In this space we can implement, to the best of our ability, interop  
> with all clients via one URL. We can do a mix of Accept and User- 
> Agent headers to interop with as many clients as possible and  
> implement them on a client by client basis. Then the url still  
> states what it's purpose is, and we get out of this multi-protocol  
> interop scenario for the 'default' behavior of a root cosmo url.

Using User-Agent headers for the HTTP server to discriminate between  
clients has a sad history.  This was done in the 90s with Web sites  
and regular browsers, which caused some browsers to try to pretend to  
be other browsers by mimicking their User-Agent strings.  (Some Web  
browsers even let you configure exactly what text goes in the User- 
Agent string!).   Thus the approach taken by servers was quickly made  
useless by clients.

It's just too broad a brush, anyway.  It seems simple to start out:  
"If the client is Netscape, use this tag; if it's IE use that tag".   
But when one browser version changes and adds a feature that the  
other had before, that approach is mal-adaptable.  It's prone to bugs  
-- even if the developer catches all the different cases (not just  
Netscape and IE; what about Opera), the "else" case is typically a  
mishmash of things that don't really behave the same.  Keeping a  
server up-to-date with User-Agent changes is hard.  Handling cases  
where the client upgrades it's functionality and FORGETS to change  
the User-Agent is impossible.

We've been having lots of discussion on some IETF lists about what  
are the feasible ways to shift users from plain web browsing to some  
more advanced set of features.  There are two and a half ways that  
work in practice:
  - A new scheme, like webcal, makes the browser look up a scheme  
handler application.  This approach is discouraged by the Technical  
Architecture Group of the W3C (with certain caveats that don't apply  
here) and I agree with that position.  It suffers from all the  
problems of the other approaches and additionally with scheme  
collision risks and interoperability problems.
  - A new MIME type, like text/icalendar, makes the browser look up  
an appropriate document handler application.  For a brand new MIME  
type, the user often has to figure out, the first time they see that  
MIME type, which application to launch.  So this still requires the  
user to know what application to launch.  See for example <http:// 
www.ietf.org/internet-drafts/draft-reschke-webdav-mount-04.txt>.
  - Microformats sometimes works: the HTML markup contains not only a  
link, but also a machine-readable annotation on the link saying what  
kind of link it is.  This requires browser extensions to handle,  
today.  It may be possible, in the future, to have a general  
microformat approach for "link type" that would allow creation of new  
types by developers of new applications without requiring browser  
upgrade/extension.  But even so, it would still require user  
intervention, at first sight of a new link type, to say what  
application was capable of handling the new link type.

There are other ways that were designed to work for this purpose but  
don't due to Web browser extensibility paradigm limitaitons:
  - The "Allow" header was for the server to advertise in an OPTIONS  
response, what methods worked on a resource. E.g. seeing PROPFIND  
there means that the client can then PROPFIND the 'resourcetype'  
property.  The problem: Browsers don't investigate the OPTIONS  of a  
resource, and if they do, don't interpret the results in a way that  
would shift the user to the new functionality.
  - The "Accept" header was for the client to advertise what MIME  
types it could handle.  Presumably if a new "application/caldav" type  
were invented and advertised, the client could advertise it, the  
server could notice it and realize that the user could be shifted to  
the higher functionality by returning the appropriate MIME type,  
yay.  But browsers don't offer an extension point for new  
applications to say "please, go ahead and offer this in the Accept  
header".  You'd have to write a FireFox extension to do that (not to  
mention the other browsers)
  - Any other response header!  The server can send any response  
header it likes, in OPTIONS or any other response.  E.g. every GET  
response to a calendar URL could have a "PLEASE-USE-CALDAV: T"  
header.  The browser would ignore it.  Only a plugin would allow the  
browser to notice it.
  - Any other request header!  The client could add any number of  
request headers to any method request.  Again, today, this would  
require the browser to be upgraded.

There is more prior art on this kind of problem than you can imagine,  
and no usable and robust solution has emerged.  Until OSAF gains the  
ability to seriously change browser extensibility paradigms, we're  
limited to the same kind of hacks other people have used.  We can  
offer a list of URLs somewhere (in email or on a Web page) and some  
annotations on those URLs.  A user-readable annotation for each URL  
is required (e.g. "this URL is for CalDAV applications").  A machine- 
readable annotation on each URL is a nice gesture of hope for  
improvement but mostly useless today.

Lisa