Re: HTML5 proposes introduction of new family of URI schemes

Martin,

There's something about your example that confuses me. Let's say I author a 
Web page, and to make it easy for you to email me, I include a link to 
mailto:nrm@arcanedomain.com.  You read my page, and click on the link, and 
you've explained why as a (hypothetical) Webmail user you'd want your new, 
smart HTML5 Web browser to invoke the Webmail Web app to compose the 
e-mail. If someone else clicks the link, then they might want that same 
link to open Outlook or Thunderbird. So far, no problem. We've got an 
existing scheme, it's in the whitelist, and each client can be configured 
to do what its user needs.

What strikes me as important, though, is that I in composing the Web page 
don't want to know how you want your particular client to handle the links. 
I want to use a URI that's independent of the implementation technology of, 
in this case, the e-mail reader, which may in some cases be Web-based and 
in others a native client app.

So my question is: why would the story be any different for other links? 
Don't we want to continue to use URI schemes that are independent of the 
implementation technology of the application? Don't we want it to be 
possible that the same link will sometimes invoke a Web-based version of an 
application and sometimes a native? That suggests to me that, rather than 
minting new URI schemes, we need to enable the use of something in the 
spirit of URI templates in the client, so that links using existing URI 
schemes can be directed to Web or native apps as appropriate. Why do we 
need or want web+ for this?

Noah



On 1/18/2012 9:59 PM, "Martin J. Dürst" wrote:
> Hello Jonathan, Julian,
>
> On 2012/01/19 0:31, Jonathan A Rees wrote:
>> On Sat, Jan 14, 2012 at 5:56 PM, Julian Reschke<julian.reschke@gmx.de>
>> wrote:
>
>>> It seem<http://dev.w3.org/html5/spec/Overview.html#custom-handlers>
>>> contains the rest of the information.
>>
>> Maybe it does, but it doesn't answer my question - to what problem is
>> this a solution? Also how is it expected to play out in practice? What
>> will the new security dialogs look like and will they baffle users
>> like all the others do? Has anyone already implemented it?
>>
>> The list of 'legacy schemes' is a red flag for me. By what criteria is
>> inclusion in the list determined? Suppose the list needs to be
>> changed, does that require a change to the HTML specification? What is
>> it about 'mailto', really, that causes it to be treated differently
>> from 'http'? The word 'core' doesn't explain much to me.
>
> Actually, it's not too difficult to explain. And 'mailto' is really at the
> core of it. If you use a 'traditional' email client, and you click on a
> 'mailto' link on a Web page, then the browser makes sure this 'mailto'
> URI/IRI is handed off to your email client, and the email client creates a
> new mail message for you and lets you edit it.
>
> These days however, webmail is being used more and more. What web mail
> users would like to have is the same facility: You click on a 'mailto'
> link, and a new email message is created by your webmail. It's easy for a
> webmail service to provide an URI/IRI where the 'mailto' URI/IRI can be
> added and the result creates the new email message that you were hoping
> for. But there's a missing piece: How to get the 'mailto' into that URI/IRI
> automatically.
>
> I have to admit that personally, I'm not using webmail. But at least to me,
> the above scenario, and the need for some additional facility, is quite
> evident. And we probably don't want to restrict this to 'mailto' only,
> because we don't know how technology will evolve.
>
> I think once we can agree that there's a need, we can look at the issues in
> more detail. Would you agree with what I wrote above as a starting point?
> Also, Julian, you seems to be very clearly opposed to the specific proposed
> solution, with some serious arguments, but do you actually agree that there
> is a need to be able to activate webmail with a 'mailto' link, and that
> there may be similar needs for other URI/IRI schemes?
>
> As you are asking for a distinction with 'http', that's easy: Because http
> is already handled by the browser, there's at least currently no need for
> such a thing as 'webhttp' (i.e. a single web site handling all of your
> browsing activity). But that also may not be set in stone, it may be
> possible that in the future, some users will view all their pages through
> facebook, and others through tor :-(.
>
> Regards, Martin.
>
>
>> A more conservative design would be to have a single new web: URI
>> scheme with a subscheme registry (sort of link urn:), rather than lots
>> of new URI schemes. This wouldn't allow registering behavior for
>> mailto:, but might mean fewer surprises and less standards innovation.
>>
>> Not opposed, just confused. Someone has thought about this a lot, and
>> I don't know what they've thought.
>>
>>> Best regards, Julian
>>
>>
>

Received on Thursday, 19 January 2012 03:10:57 UTC