Log in

No account? Create an account

Thu, Dec. 13th, 2007, 12:20 pm
What Shall We Do Now?

You've probably noticed, because you're a bright and observant lot with more than a large streak of geekiness, that there's been a proliferation of custom url protocol schema such as webcal://. Apple is especially guilty of this in much the way that they're often especially guilty of muddying the technical waters. They tend to get away with it because even usually sensible, standards oriented people think they're so gosh darn pretty.

I'm going to stick my neck out here and say


The protocol part of the schema is for the protocol, ffs. I don't actually care whether the .ics file you're serving me comes via HTTP, FTP or Gopher but I at least need to know what protocol to use. You might argue that I should default to HTTP but it's not exactly a huge stretch to imagine that, one day, HTTP might be replaced as the great circle of life continues. Hakuna Matata. Especially if we start having more mobile orientated protocols.

If only we had some way of saying what type the file was. Oh wait! We ALREADY FUCKING DO. It's called MIME types and they work just fine, thank you very much.

There are two objections to MIME types as far as I can tell:

  1. It's hard to configure handlers for them
    I concede this may be true but a) that's a UI problem, not a protocol problem and b) it's no more difficult than having to configure a handler for a new pseudo protocol, especially since most browsers don't have UIs to configure protocol handlers and even if they did now we have to have two (2) different UIs (or one confusing UI) to handle MIME type and protocol handler set up).[*].

  2. Configuring MIME types is a server problem and sometimes I don't have access to my server config or don't know how to set things up. Waaah waaah waaah.

That's not to say that there isn't room for improvement - for example you can't paste a link into an email and then specify the mime type (although perhaps some pseudo protocol like http+text/calendar:// ought to be defined) however that said I wish people would stick to the standards - they're there for a reason and "because the URLs look prettier this way" isn't a valid reason to ignore them.

(I am fully expecting now someone to come and point out that this is all allowed under some RFC and that I'm wrong in which case I will concede gracefully and commit seppuku)

[*]Although I'm aware that browser have ways of configuring what mail client to use with mail://
(Deleted comment)

Fri, Dec. 14th, 2007 12:46 am (UTC)
deflatermouse: Re: Wild Speculation

It's a good point but I'd argue that I'm still right and that the problem you describe is entirely work-aroundable. Although I might just be arguing because I'm jetlagged and irritable at the moment :)

Worst case scenario you serve a file with a single url in that the app can understand so, theoretically, for serving something like iCalendar where the app needs to know the url you serve (for later editing) you serve a file using a text/icalendar+wrapper mime type (or similar - perhaps message/external-body+icalendar?) and then have file with the URL in that (a la ASF redirection container files).

To quote the original draft of RFC 2717 "Registration Procedures for URL Scheme Names":

"Because URI schemes constitute a single, global namespace, the unbounded registration of new schemes is harmful to the Internet community.".

Even if there are flaws to the present system then the solution is not for companies to just start popularising new schemas without registering them anywhere - it's not a scaleable solution and it's storing up problems for the future.

(Deleted comment)

Fri, Dec. 14th, 2007 01:23 am (UTC)
deflatermouse: Re: Wild Speculation

*nod* Understood.

As for why they're doing it - the grumpy cynic in me would guess that it's because they're lazy. That's probably a bit harsh though. If I'm being more charitable I'd say that they're doing it because it's easier (and it's easier because it's simpler, always a good thing in software development) and they don't see it doing any long term harm.

FWIW, I've just thought of another place where a pseudo schema works better - I can write a GreaseMonkey script that rewrites webcal://example.com/calendar links as http://mycalendar.com/add?url=http://example.com/calendar very easily. Writing something that parses html looking for <a href="http://example.com/calendar" type="text/calendar"> isn't much harder but for links that don't have that a type attribute it'd have to go and do a HEAD on every single link which would be ... sub-optimal.

It's a little bit contrived and the counter argument is that they should just add a type wherever they'd use webcal:// but it's still a point.

Edited at 2007-12-14 01:27 am (UTC)

Fri, Dec. 14th, 2007 03:06 am (UTC)

On my geeky business card, I listed my website with http://... and email address with smtp://...

If it weren't for the fact that I then listed my cell phone with cell://..., I'd be even more standards compliant than if I'd started with a mailto:... ;-)

Fri, Dec. 14th, 2007 03:15 am (UTC)

RFC 1738 be damned. No, wait, I mean... RFC 3986...

Heh, compare:


(NNTP is only referenced in 1738, and was dropped from later RFC's, indicating the immense popularity of NNTP.)

Edited at 2007-12-14 03:15 am (UTC)

Fri, Dec. 14th, 2007 11:24 am (UTC)

ITYM nntp://news.example.com/comp.infosystems.www.servers.unix

Different uses -- one specifies an NNTP (well, NNRP actually IIRC) server explicitly, the other doesn't.

Mon, Dec. 24th, 2007 01:23 pm (UTC)

If it weren't for the fact that I then listed my cell phone with cell://...


Mon, Dec. 24th, 2007 05:23 pm (UTC)

Nice. It's high time to start marking websites with "web:sitename". Down with direct protocol references!

Sat, Dec. 15th, 2007 03:13 pm (UTC)

is this a reference to virgin prunes?