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

Re: fb: URIs?

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 23 Feb 2010 18:59:46 -0500
To: Thomas Fruin <thomasfruin@mac.com>
Cc: Dan Brickley <danbri@danbri.org>, David Recordon <davidrecordon@facebook.com>, uri@w3.org
Message-ID: <OF596E3E8A.6921A37B-ON852576D3.0082FED7-852576D3.00837E52@lotus.com>
Thomas Fruin writes:

> 4. In this case, the action the Facebook web site can take is 
> redirect the iPhone browser to a fb://profile/4 psuedo URI.

Let's say this proposal is adopted, and at some point in the future 
someone decides to invent an fb scheme for some (presumably) good purpose, 
let's say to reference fruit baskets.  URIs with the new fb scheme are 
deployed on the Web.  Am I right that iPhones will be incapable of 
properly dereferencing these URIs to access the fruit baskets?

The point is, even using schemes like this internally can, indirectly, 
divide the Web.  There's the Web of software that believes fb is first 
unregistered, and then for fruitbaskets, and there is the web of software 
that directs fb references to Facebook applications.  I don't think you 
can have it both ways.  If fb is to be deployed, it should be registered, 
I think.  If very many systems like iPhone follow this model, we're going 
to have a big mess with tens or hundreds of thousands of schemes 
registered for very limited purposes.

Using a somewhat tortured analogy, we could just assign each telephone 
user his/her own country code.  It one level, the system would continue to 
work (you could in principle assign a number to every phone, and those 
phones could be dialed), but at another it would be unnecessarily unweildy 
in practice.  Generally, in systems like this, the top level in the 
hierarchy is the last robust in terms of scaling (because, by definition, 
it has no substructure), and extensions at that level should typically be 
done only for good reason and with care.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Thomas Fruin <thomasfruin@mac.com>
Sent by: uri-request@w3.org
02/23/2010 11:49 AM
 
        To:     uri@w3.org
        cc:     David Recordon <davidrecordon@facebook.com>, Dan Brickley 
<danbri@danbri.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: fb: URIs?


> Specifically, we hear that
> 
> http://www.facebook.com/profile.php?id=4
>    and
> fb://profile/4
> 
> are semantically the same.  If the systems everywhere could dispatch
> on "http://www.facebook.com/profile.php?id=" as easily as they dispatch
> on "fb:", it seems like the technical side of this problem might go
> away.

Actually, it is not necessary that _everybody_ know how to distinguish 
between the two types of URI's. It is only necessary that the web site of 
the party that introduces the pseudo URI know the difference. Let me 
explain.

In this particular case, Facebook invented the fb:// pseudo URI and linked 
it to its iPhone app, so that these URI's would always open in the iPhone 
Facebook app. (A regular http://www.facebook.com/ URI would only get 
opened in the iPhone browser.)

The relatively simple standards-compliant solution would be the following:

1. Facebook URI's should always be stored in their generic and 
standards-compliant form: http://www.facebook.com/profile.php?id=4
2. When a user opens such a link, it will be accessed in the standard way, 
through a web browser and the http protocol.
3. In the specific case that the web client is an iPhone, the Facebook web 
site can determine this and take appropriate action.
4. In this case, the action the Facebook web site can take is redirect the 
iPhone browser to a fb://profile/4 psuedo URI.
5. The effect of this redirection on an iPhone is that the Facebook app 
opens the desired link.

You can substitute "Facebook" and "www.facebook.com" for any other party 
that wishes to implement pseudo URI's for particular device-specific 
redirection. As long as they do it on their own web site and know what 
effect the pseudo URI will have on a user's device, things should be fine.

This is somewhat similar to Apple's handling of URI's that point to the 
iTunes store. These URI's start out as standard http: style URI's, but 
then get redirected to itunes:// pseudo URI's that open the iTunes Store 
application (either on computers or iPhone's).

My 2c worth...

-- Thomas Fruin
Received on Tuesday, 23 February 2010 23:57:28 UTC

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