W3C home > Mailing lists > Public > uri@w3.org > February 2010

Re: fb: URIs?

From: Claus Färber <gmane2010@cfaerber.name>
Date: 17 Feb 2010 12:47:00 +0100
To: uri@w3.org
Message-ID: <BJ3KylpRt6D@mid.cfaerber.name>
Julian Reschke <julian.reschke@gmx.de> schrieb/wrote:
> On 17.02.2010 02:13, Ira McDonald wrote:
>> Apparently, the 'fb:' pseudo-URI scheme has escaped seriously into
>> the visible user environment - the replacement of real 'http:' URIs
>> with equivalent (???) 'fb:' URIs described below by Thomas is a
>> spectacular bug. ...

> This is what happens when a platform starts to use URIs for things they
> weren't designed for. If I recall correctly, this issue has been
> discussed on the TAG mailing list a long time ago (once the iPhone SDK
> came out?).

> Apple is well known for using URIs for things they arent't designed for,
> *and* then (consequently?) not registering them (itms and ical come to
> mind).

> The real question here is: what can we do to educate them?

What is needed is an alternative to (ab)using URIs. Just insisting that
URIs "weren't desgined for" this, does not help.

The "correct" alternative to "fb" URIs would be: register a URN scheme;
they don't indicate a location, after all. However, this approach has
two problems:

- Operating systems (not only the iPhone OS but also Windows comes to
  mind) are desinged to route URIs to applications based on the URI
  scheme. This is "urn" for all URNs.

- Registering a URN scheme requires an RFC and IESG approval.

The "tag" URI scheme does not solve the first problem, either.
Registering a new URI scheme does not solve the second problem.

What's needed is an ad-hoc namespace for URI schemes. For example, all
names containing an underscore could be reserved for domain-based
schemes. Then, one could simply create URIs like this:

  facebook_com:profile/4

Further, extending URIs to specify what to do with URIs (view, play,
edit, ..., route to application named "example_org") -- let's call these
"URI dispositions" -- would often help, too.

An iTunes URI, for example, could read:

  itunes_com+http://example.com/rss_podcast

or even:

  itunes_com+subscribe+http://example.net/xml_podcast

(Potential meaning: use the "itunes_com" app/verb/protocol with the
"subscribe" app/verb/protocol for the ressource located with the "http"
protocol. If "itunes_com" is an application and "subscribe" is a generic  
verb, that means: tell "itunes_com" to "subscribe" to the URL.)

But you could also do:

  subscribe+http://example.net/xml_podcast

(Potential meaning: use the "subscribe" app/verb/protocol for the
ressource located with the "http" protocol. If "subscribe" is a generic  
verb, that means: tell any application to "subscribe" to the URL.)

Other potential uses:

  rsync+ssh://example.net/path/to/dir
  git+ssh://example.com/%2fsrv/git/repo.git

  edit+http://example.com/path
  emacs_gnu_org+edit+http://example.net/path

  play+http://example.com/video.mp4
  edit+http://example.com/video.mp4

  download+http://example.org/path/to/file.zip

  fax+tel:+1.555.555-1234       (short form: fax)
  sms+tel:+1.555.555-9876       (short form: sms)

  http+tls://example.com        (short form: https)

Claus
Received on Thursday, 18 February 2010 12:58:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC