Subject: iphone urls

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Oct 2008 10:02:59 +0200

Gentlemen,

load your guns. application uri schemes and posts on GET on the iPhone:

http://furbo.org/2008/10/01/redacted/

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Oct 2008 19:04:57 +1000

Interesting. It would be useful to educate users as to why using URI  
schemes like this isn't a good idea, and illustrate the alternatives  
(namely, media types). I.e.,

If only we had some sort of technical architecture... board or panel  
(or even group!) to help document these things for the Web...

Seriously, though. Looking through the TAGs findings, I think most of  
the relevant documents are too dense to be useful to developers like  
this.

How about a "So You Want to Create a URI Scheme" guide, with practical  
advice about when it's a good idea and when it's not, examples, trade- 
offs, caveats, and details of what this means in *existing* code?

Cheers,

--
Mark Nottingham       [email-masked]

---

From: "Alan Ruttenberg" <[email-masked]>
Date: Thu, 2 Oct 2008 05:35:13 -0400

The alternative in this case would be better IPC on the iphone. My read is
that the twitterific "scheme" isn't something one would use to publish on
the web. Rather it's a way to hook things on the iphone so that one
application can easily call a service that another application publishes.
The "other" application creates an openURL handler, part of it's own
application, which apparently makes the "scheme"  globally accessible.
-Alan

On Thu, Oct 2, 2008 at 5:04 AM, Mark Nottingham <[email-masked]> wrote:

> If only we had some sort of technical architecture... board or panel (or
> even group!) to help document these things for the Web...
>
> Seriously, though. Looking through the TAGs findings, I think most of the
> relevant documents are too dense to be useful to developers like this.
>
> advice about when it's a good idea and when it's not, examples, trade-offs,
> caveats, and details of what this means in *existing* code?
>
> Cheers,
>
>

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Oct 2008 12:33:44 +0200

Am 02.10.2008 um 11:35 schrieb Alan Ruttenberg:

> The alternative in this case would be better IPC on the iphone. My  
> read is that the twitterific "scheme" isn't something one would use  
> to publish on the web. Rather it's a way to hook things on the  
> iphone so that one application can easily call a service that  
> another application publishes. The "other" application creates an  
> openURL handler, part of it's own application, which apparently  
> makes the "scheme"  globally accessible.

That is the current use there, yes. But with things like ical: and  
itunes: uri schemes in OSX already, I hold any bet that we will soon  
see app uri schemes spreading from the iPhone apps to the OSX apps.  
And then someone will build support into FF?

I think application uri schemes result from something lacking in URI  
dispatching and maybe web arch. Taking the simple "ical:" uri scheme  
on OS X, designers of web pages wanted something to say "click here  
to add this to your calendar". While that is a fair use case, the  
design with ical: uri schemes is a poor approach.

Instead imagine the web page to offer additionally "click here to  
remove this from your calendar". Clearly, neither the ical: uri  
scheme, nor the w3c endorsed content-type based dispatching can  
perform the task. Would something like

   <a href="http://example.org/event.ics" rel="calendar.add">Add this  
event to your calendar</a>
   <a href="http://example.org/event.ics"  
rel="calendar.remove">Remove this event to your calendar</a>

be desirable? Of course this needs some browser infrastructure.

The alternative approach is to embedd

   <a href="http://example.org/event.ics" type="text/calendar">An  
interesting event for you!</a>

in a page and let the user choose actions from a context menu. But  
that makes a very poor user interface.

//Stefan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Oct 2008 14:55:47 +0200

Stefan Eissing wrote:
> itunes: uri schemes in OSX already, I hold any bet that we will soon see 
> app uri schemes spreading from the iPhone apps to the OSX apps. And then 
> someone will build support into FF?
> 
> dispatching and maybe web arch. Taking the simple "ical:" uri scheme on 
> OS X, designers of web pages wanted something to say "click here to add 
> this to your calendar". While that is a fair use case, the design with 
> ical: uri schemes is a poor approach.
> 
> Instead imagine the web page to offer additionally "click here to remove 
> this from your calendar". Clearly, neither the ical: uri scheme, nor the 
> w3c endorsed content-type based dispatching can perform the task. Would 
> something like
> 
>   <a href="http://example.org/event.ics" rel="calendar.remove">Remove 
> this event to your calendar</a>
> 

I don't think this is what the HTML anchor element and the rel attribute 
are for.

> in a page and let the user choose actions from a context menu. But that 
> makes a very poor user interface.

If the resource is served with the proper Content-Type, following this 
link will cause the system's calendar application to open (if configured 
properly). At least on my system, this causes the application to offer 
to add that event to the calendar.

What's missing though (and here we're walking into vcarddav/calsify 
territory) is the ability for the calendar application not to add the 
event, but to *subscribe* to the remote calendar (that's what Apple does 
with Ical). The only thing currently stopping calendar applications from 
doing it is the fact that when the user agent passes the calendar object 
to the calendar application, the information about the origin of the 
object (the HTTP URL) is lost.

Of course that's the same problem we had with Atom feeds, and the simple 
fix for this is to add the URL to the payload, as in in Atom self 
relation link.

I proposed the equivalent for ICS in 
<http://lists.osafoundation.org/pipermail/ietf-calsify/2008-August/002027.html>.

BR, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Oct 2008 07:34:01 -0700

Pownce, a similar application to Twitter, uses the pownce:// scheme on the iphone to move back and forth between their application and their web site. This is particularly useful in their login flow which uses OAuth. OAuth requires sending users (using a browse) to their service provider for authorization (it's a delegation protocol) and are then redirected back to the calling site (to notify it can continue). In case of an desktop or mobile application, normal http callbacks would require opening a listening socket (and potentially a firewall configuration). Instead, the Pownce application asks the service provider to redirect the user back to a pownce:// url which on the iphone brings up the Pownce application. The result is a seamless integration of the application and browser.

The technical problem with this flow is that many service providers will block such urls from being used for callbacks because they have no way to verify where they will lead and if they hold security risks for the user. Since it is the remote service provider who is redirecting the user, and since the user usually have a higher trust relationship with the service provider, the user is more likely to allow that redirect to go through. Yahoo's OAuth implementation does not allow such url schemes used, or even any unverified http urls (something people have complained about).

The key is how the browser handles launching applications from a security standpoint. Content types do not offer sufficient control over the user flow, and make it more difficult to share a common content type (like an XML config schema) without opening another dialog for the user to select from. One suggestion I have seen was to use an application scheme like application://pownce/some_path. It doesn't solve any of the above concerns but at least indicates to the service provider what the intention really is.

Either way, there is a real need here and without any better (and complete) solution, people are happy to use what works.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Eissing
> Sent: Thursday, October 02, 2008 3:34 AM
> To: Alan Ruttenberg
> Cc: Mark Nottingham; W3C TAG; HTTP Group Working
> Subject: Re: iphone urls
>
>
>
> on OS X, designers of web pages wanted something to say "click here to
> add this to your calendar". While that is a fair use case, the design
> with ical: uri schemes is a poor approach.
>
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht
> Münster: HRB5782
>
>
>
>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Eissing
> Sent: Thursday, October 02, 2008 3:34 AM
> To: Alan Ruttenberg
> Cc: Mark Nottingham; W3C TAG; HTTP Group Working
> Subject: Re: iphone urls
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Oct 2008 10:33:07 +1000

[ setting reply-to to the TAG, as I didn't mean to start cross- 
posting; mea culpa ]

On 02/10/2008, at 10:55 PM, Julian Reschke wrote:

>> itunes: uri schemes in OSX already, I hold any bet that we will  
>> soon see app uri schemes spreading from the iPhone apps to the OSX  
>> apps. And then someone will build support into FF?
>> I think application uri schemes result from something lacking in  
>> URI dispatching and maybe web arch. Taking the simple "ical:" uri  
>> scheme on OS X, designers of web pages wanted something to say  
>> "click here to add this to your calendar". While that is a fair use  
>> case, the design with ical: uri schemes is a poor approach.
> I don't think this is what the HTML anchor element and the rel  
> attribute are for.

It's an interesting point, though. From the amount of interest that  
the Link header draft has received, I wouldn't be surprised if we soon  
have three things that could be used for such dispatch. If there isn't  
clear guidance about when and where to use them, they'll all be misused.

> If the resource is served with the proper Content-Type, following  
> this link will cause the system's calendar application to open (if  
> configured properly). At least on my system, this causes the  
> application to offer to add that event to the calendar.
>
> territory) is the ability for the calendar application not to add  
> the event, but to *subscribe* to the remote calendar (that's what  
> Apple does with Ical). The only thing currently stopping calendar  
> applications from doing it is the fact that when the user agent  
> passes the calendar object to the calendar application, the  
> information about the origin of the object (the HTTP URL) is lost.
>
> Of course that's the same problem we had with Atom feeds, and the  
> simple fix for this is to add the URL to the payload, as in in Atom  
> self relation link.
>
> I proposed the equivalent for ICS in <http://lists.osafoundation.org/pipermail/ietf-calsify/2008-August/002027.html 
> >.

There are other aspects that motivate people, though. For example,  
media types have a well-known limitation in that they need to be  
implemented server-side, which often requires coordination between the  
author and a server administrator. URI schemes, from the author  
standpoint, "just work", and arguably there are many many more authors  
than client application developers in the world, so it's appropriate  
to push the pain onto the smaller and more capable party.

Just playing devil's advocate, you understand. If we don't pay  
attention to these kinds of trade-offs, we'll find the architecture  
roundly ignored, perhaps rightfully so.