Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents

[James Hawkins-4]

We, the designers of the Web Intents draft API, have always seen Web
Intents as a superset of the functionality provided by
registerProtocolHandler (RPH) and registerContentHandler (RCH).  To
follow this to the logical conclusion, we should be able to provide
functionally equivalent counterparts to RPH/RCH in Web Intents.  This
proposal provides a means of deprecating RPH/RCH, replacing this
functionality with equivalent functionality from Web Intents.

For reference RPH/RCH are documented at [1].  The current draft of the
Web Intents API is at [2].


registerProtocolHandler
===================

The registerProtocolHandler() method allows Web sites to register
themselves as possible handlers for particular schemes.

 void registerProtocolHandler(DOMString scheme, DOMString url, DOMString title);

We propose the addition of a 'scheme' attribute to the Web Intents
service registration to handle this use case.

 <intent scheme="mailto">

* |scheme| is the same as specified for RPH.
* If |scheme| is specified, |action| *should* (must?) be ignored.

Thus, with this proposal, when the user clicks a "mailto:" link, the
UA will internally create a new intent containing the scheme and the
URL parameters as the data in the payload.  This payload will be
delivered to the service the user picks.  Note we’re considering
specifying the UA may optionally decode the parameters into the
|extras| object.

Given the following anchor on mypage.com:

<a href="mailto:me@...?bcc=support@...&subject=testing">

the UA will deliver the following payload to the selected service:

{
  type: “text/plain”,
  scheme: “mailto”,
  data: “mailto:me@...?bcc=support@...&subject=testing”,
  extras: {
    bcc: “support@...”,
    subject: “testing” }
}

Open question: should we use the same whitelist of schemes used by RPH?


registerContentHandler
===================

The registerContentHandler() method allows Web sites to register
themselves as possible handlers for content in a particular MIME type.

 void registerContentHandler(DOMString mimeType, DOMString url,
DOMString title);

We propose modifying the relationship between the |action| and |type|
attributes to specify that if |action| is not specified and |type| is
specified, the action is implicitly 'view' and the service must be
shown in the picker when the UA encounters content of matching MIME
type.

 <intent type="image/png">

The above registration would register the service to handle content of
MIME type "image/png".

When the UA loads a resource of type "image/png", it sends the type
and content to the service in the payload.

{
  data: pngImageContent,
  type: “image/png”
}


isProtocolHandlerRegistered / isContentHandlerRegistered
=============================================

There are serious fingerprinting issues with these methods, and when
contemplating analogous methods for Web Intents, we thought long and
hard about the fingerprinting issue.

As spec'ed a site could call registerProtocolHandler('web+uniqueID',
...) where uniqueID is unique to a user.  The site could then call
isProtocolHandlerRegistered with that matching 'web+uniqueID' to
verify who the user is.

One of the use cases for these methods is to allow a client site the
ability to show alternative UI for protocols/content that are not
capable of being handled by any service.  Web Intents also requires a
solution for this use case, as showing an empty picker* is a
non-starter.

* The picker refers to the UI in the UA that shows registered services
for a given intent, allowing the user to pick which service to
activate.

Instead of creating analogous functionality of these methods for Web
Intents, we decided to tackle the problem state of an empty picker.
The proposed solution is to allow a client site to suggest a service
(URL) that is displayed by the UA in the picker.  The
|suggestedService| parameter is optional.

 startActivity(..., suggestedService);

In addition declarative registration removes the need to fashion
registration as:

if (!isProtocolHandlerRegistered(x))
  registerProtocolHandler(x);

The work of maintaining that state is displaced to the UA.


unregisterProtocolHandler / unregisterContentHandler
===========================================

The analogous functionality for these methods in Web Intents already
exists and is the same as the removal of any type of service: remove
the declarative registration from the content, and the UA will
unregister the service as a handler.


[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
[2] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html

Thanks,
James

[Bjartur Thorlacius]

Þann mið 15.feb 2012 23:39, skrifaði James Hawkins:
> * If |scheme| is specified, |action| *should*  (must?) be ignored.
Why would you forbid distinguishing between actions on URIs? Postal and
retrieval of mail, for example, are quite distinct actions. As are
modification and retrieval of documents.

[James Hawkins-4]

Thanks for your feedback, Bjartur.

On Tue, Feb 21, 2012 at 9:30 AM, Bjartur Thorlacius <svartman95@...>wrote:

> Þann mið 15.feb 2012 23:39, skrifaði James Hawkins:
>
>  * If |scheme| is specified, |action| *should*  (must?) be ignored.
>>
> Why would you forbid distinguishing between actions on URIs? Postal and
> retrieval of mail, for example, are quite distinct actions. As are
> modification and retrieval of documents.
>

I'm not sure if the proposal was explicit enough, but for the RPH-esque
functionality in Web Intents, we activate WI in the same circumstances RPH
is activated, which is when links are activated in a page.  Can you
elucidate how the scenarios you listed could be handled?  Note these
scenarios are above and beyond RPH, but we're not trying to make the API
self-limiting.

Thanks,
James

[Bjartur Thorlacius]

Þann þri 21.feb 2012 18:44, skrifaði James Hawkins:
> I'm not sure if the proposal was explicit enough, but for the RPH-esque
> functionality in Web Intents, we activate WI in the same circumstances
> RPH is activated, which is when links are activated in a page.  Can you
> elucidate how the scenarios you listed could be handled?  Note these
> scenarios are above and beyond RPH, but we're not trying to make the API
> self-limiting.
Windows Explorer (the file manager) does for example offer users to edit
images upon right-click. I worry that if URI scheme handlers need not
only take care of fetching but also of presentation, other actions than
view will be unnecessarily hard to implement. Thus I figure retrieval
and presentation must be separated.

(view (fetch uniform:resource/locator))
or
(edit (fetch uniform:resource/locator))

instead of
(fetch-and-view uniform:resource/locator)

[James Hawkins-4]

On Tue, Feb 21, 2012 at 11:31 AM, Bjartur Thorlacius
<svartman95@...> wrote:

> Þann þri 21.feb 2012 18:44, skrifaði James Hawkins:
>
>> I'm not sure if the proposal was explicit enough, but for the RPH-esque
>> functionality in Web Intents, we activate WI in the same circumstances
>> RPH is activated, which is when links are activated in a page.  Can you
>> elucidate how the scenarios you listed could be handled?  Note these
>> scenarios are above and beyond RPH, but we're not trying to make the API
>> self-limiting.
>
> Windows Explorer (the file manager) does for example offer users to edit
> images upon right-click. I worry that if URI scheme handlers need not only
> take care of fetching but also of presentation, other actions than view will
> be unnecessarily hard to implement. Thus I figure retrieval and presentation
> must be separated.
>
> (view (fetch uniform:resource/locator))
> or
> (edit (fetch uniform:resource/locator))
>
> instead of
> (fetch-and-view uniform:resource/locator)

Is this use case not fully handled by the UA specifying the
appropriate action when building the intent, e.g., the user
right-clicks on an image in a page and the UA constructs context menu
items for edit/share/etc. action?

[Bjartur Thorlacius]

Þann þri 21.feb 2012 19:41, skrifaði James Hawkins:
> Is this use case not fully handled by the UA specifying the
> appropriate action when building the intent, e.g., the user
> right-clicks on an image in a page and the UA constructs context menu
> items for edit/share/etc. action?
Not if the image is both fetched and drawn by a single plugin. By plugin
I mean an extra-UA piece of software that is allocated a window to draw to.

I hope you meant that an Intent API could be used to pass URIs to
fetchers to pass back retrieved resources, without converting them to
HTML or bitmaps, rather than to pass URIs of resources to be drawn to
users' screens or speakers.

[brettz9]

On 2/16/2012 7:39 AM, James Hawkins wrote:

> We, the designers of the Web Intents draft API, have always seen Web
> Intents as a superset of the functionality provided by
> registerProtocolHandler (RPH) and registerContentHandler (RCH).  To
> follow this to the logical conclusion, we should be able to provide
> functionally equivalent counterparts to RPH/RCH in Web Intents.  This
> proposal provides a means of deprecating RPH/RCH, replacing this
> functionality with equivalent functionality from Web Intents.
>
> For reference RPH/RCH are documented at [1].  The current draft of the
> Web Intents API is at [2].
>
>
> registerProtocolHandler
> ===================
>
> The registerProtocolHandler() method allows Web sites to register
> themselves as possible handlers for particular schemes.
>
>   void registerProtocolHandler(DOMString scheme, DOMString url, DOMString title);
>
> We propose the addition of a 'scheme' attribute to the Web Intents
> service registration to handle this use case.
>
>   <intent scheme="mailto">
>
> * |scheme| is the same as specified for RPH.
> * If |scheme| is specified, |action| *should* (must?) be ignored.
>
> Thus, with this proposal, when the user clicks a "mailto:" link, the
> UA will internally create a new intent containing the scheme and the
> URL parameters as the data in the payload.  This payload will be
> delivered to the service the user picks.  Note we’re considering
> specifying the UA may optionally decode the parameters into the
> |extras| object.
>
> Given the following anchor on mypage.com:
>
> <a href="mailto:me@...?bcc=support@...&subject=testing">
>
> the UA will deliver the following payload to the selected service:
>
> {
>    type: “text/plain”,
>    scheme: “mailto”,
>    data: “mailto:me@...?bcc=support@...&subject=testing”,
>    extras: {
>      bcc: “support@...”,
>      subject: “testing” }
> }
>
> Open question: should we use the same whitelist of schemes used by RPH?
>
>
> registerContentHandler
> ===================
>
> The registerContentHandler() method allows Web sites to register
> themselves as possible handlers for content in a particular MIME type.
>
>   void registerContentHandler(DOMString mimeType, DOMString url,
> DOMString title);
>
> We propose modifying the relationship between the |action| and |type|
> attributes to specify that if |action| is not specified and |type| is
> specified, the action is implicitly 'view' and the service must be
> shown in the picker when the UA encounters content of matching MIME
> type.
>
>   <intent type="image/png">
>
> The above registration would register the service to handle content of
> MIME type "image/png".
>
> When the UA loads a resource of type "image/png", it sends the type
> and content to the service in the payload.
>
> {
>    data: pngImageContent,
>    type: “image/png”
> }
>
>
> isProtocolHandlerRegistered / isContentHandlerRegistered
> =============================================
>
> There are serious fingerprinting issues with these methods, and when
> contemplating analogous methods for Web Intents, we thought long and
> hard about the fingerprinting issue.
>
> As spec'ed a site could call registerProtocolHandler('web+uniqueID',
> ...) where uniqueID is unique to a user.  The site could then call
> isProtocolHandlerRegistered with that matching 'web+uniqueID' to
> verify who the user is.
>
> One of the use cases for these methods is to allow a client site the
> ability to show alternative UI for protocols/content that are not
> capable of being handled by any service.  Web Intents also requires a
> solution for this use case, as showing an empty picker* is a
> non-starter.
>
> * The picker refers to the UI in the UA that shows registered services
> for a given intent, allowing the user to pick which service to
> activate.
>
> Instead of creating analogous functionality of these methods for Web
> Intents, we decided to tackle the problem state of an empty picker.
> The proposed solution is to allow a client site to suggest a service
> (URL) that is displayed by the UA in the picker.  The
> |suggestedService| parameter is optional.
>
>   startActivity(..., suggestedService);
>
> In addition declarative registration removes the need to fashion
> registration as:
>
> if (!isProtocolHandlerRegistered(x))
>    registerProtocolHandler(x);
>
> The work of maintaining that state is displaced to the UA.
>
>
> unregisterProtocolHandler / unregisterContentHandler
> ===========================================
>
> The analogous functionality for these methods in Web Intents already
> exists and is the same as the removal of any type of service: remove
> the declarative registration from the content, and the UA will
> unregister the service as a handler.
>
>
> [1]http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
> [2]http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
>
> Thanks,
> James
>

I like this very much, especially since it seems it ought to allow for
type-awareness with protocols (e.g., handling only part of the urn:
protocol). I am also glad the current spec seems to allow for
specification of multiple defaults.

One aspect I do not find made explicit here is whether the invocation of
another application is to occur asynchronously within the client app (as
appears to me to be the case with other (non-scheme) Web Intents) or, as
would seem more likely, whether the use of the "scheme" attribute will
always prompt the opening of a new window/tab. I do strongly support the
ability to open in a new page since it allows for bookmarkability.

I would also like to reiterate two requests I made earlier here,
especially given the potential for the deprecation you mention, that
<a/> be given:
1) An attribute of higher precedence than "href", to allow user agents
to still have a fallback if they do not support this attribute or if the
user opts not to utilize any of the protocol handlers and wishes to
visit a simple hard-coded non-protocol-aware website provided by the web
author. One should not need JavaScript enabled to take advantage of
links, even while experimenting with new protocols.
2) An attribute of lower precedence than "href" which allows listing of
additional hard-coded non-protocol-aware websites as right-click options
for this URL. Perhaps the "contextmenu" attribute would be sufficient
for this, however, if it can detect the link being right-clicked
(ideally as part of the event), though I think a simple non-JavaScript
option ought to be helpful.

Best wishes,
Brett