--- a/spec/Overview-respec.html Tue Jan 31 13:57:04 2012 -0800
+++ b/spec/Overview-respec.html Tue Jan 31 14:49:31 2012 -0800
@@ -110,7 +110,7 @@
<p>
An Intent is a user-initiated action delegated to be performed by a service.
It consists of an "action" string which tells the service what kind of activity
- the user expects to be performed (i.e. "share" or "edit"), a "type" string which
+ the user expects to be performed (e.g. "share" or "edit"), a "type" string which
specifies the data payload the service should expect, and the data payload
itself.
</p>
@@ -214,7 +214,7 @@
};
document.getElementById('save-button').onclick = function() {
- window.intent.postReply(getImageDataURI(...));
+ window.intent.postResult(getImageDataURI(...));
};
</script>
</pre>
@@ -224,6 +224,15 @@
image into a canvas and taking it back out again as a data URI. Or
producing the public URI of the image on the site.
</p>
+ </section>
+
+ <section>
+ <h3>Normative parts</h3>
+ <p>
+ The normative parts of this specification are the API Description and the
+ User Agent Behavior section. All other parts are informative.
+ </p>
+ </section>
</section>
<section>
@@ -236,11 +245,17 @@
<h3>Actors</h3>
<p>
A <dfn>Client</dfn> is a web page which creates an Intent and invokes
- it.
+ it. The User Agent may also allow non-web-page sources invoke Intents
+ to be delivered. For instance, the User Agent may have UI which
+ effectively triggers Intents delivery, or may register for external OS
+ hooks to trigger Intents.
</p>
<p>
A <dfn>Service</dfn> is a web page which can handle an Intent,
- possibly returning a piece of data to the calling Client page.
+ possibly returning a piece of data to the calling Client page. Again,
+ the User Agent may have ways to deliver Intents to Services which are
+ not web pages. These may be extension APIs, plug-in helpers, external OS
+ handlers, etc.
</p>
</section>
<section>
@@ -348,21 +363,26 @@
<section>
<h3>Delivery and Response API</h3>
<p>
- When the user agent loads a Service page to handle an intent invocation, it
+ When the User Agent loads a Service page to handle an Intent invocation, it
will place a <code>window.intent</code> object in the scope of the page.
</p>
<dl title='[NoInterfaceObject] interface IntentProvider' class='idl'>
<dt>readonly attribute Intent intent</dt>
- <dd>The intent object as delivered to the service page.</dd>
+ <dd>The intent object as delivered to the service page (includes
+ postResult and postFailure methods).</dd>
</dl>
<dl title='DOMWindow implements IntentProvider' class='idl'></dl>
<p>
- This object will only be made available to service pages when they are
- loaded in the context of an intent invocation. In other situations, the User
- Agent MUST NOT make <code>DOMWindow</code> implement
- <code>IntentProvider</code>.
+ This object will only be made available to Service pages when they are
+ loaded in the context of an intent invocation. Even if the same URL is
+ loaded in other situations, the User Agent MUST NOT make
+ <code>DOMWindow</code> implement <code>IntentProvider</code>. Similarly, if
+ a Service page is registered, but the User Agent loads it and it does not
+ contain the declarative markup marking it as expecting to handle the Intent
+ the User Agent is delivering, the User Agent MUST NOT make
+ <code>DOMWindow</code> implement <code>IntentProvider</code>.
</p>
<p>
The <code>window.intent</code> object MUST be made available across
@@ -387,10 +407,20 @@
http://login.example.com
</p>
<p>
- In other words, in the browsing context in which the intent is originally
- delivered, the intent data MUST be available to pages in a redirect sequence
- when they are in the same origin as that to which it was originally
- delivered, but MUST NOT be available to any other pages.
+ The <code>window.intent</code> object MUST be made available to a page on
+ the same-origin as the originally-delivered page if the user initiates a
+ navigation on the browsing context in which that Service page is displayed,
+ AND the new page has declarative syntax marking it as a handler for the
+ Intent type the User Agent is delivering.
+ </p>
+ <p>
+ In other words, in the browsing context in which the Intent is originally
+ delivered, the intent data MUST be available to pages in a redirect or
+ navigation sequence when they are in the same origin as that to which it was originally
+ delivered, but MUST NOT be available to any other pages. This allows Service
+ pages to delegate handling, to redirect to login screens, and so forth, but
+ does not make the Intent data available to any such pages encountered which
+ are not in the same origin.
</p>
</section>
@@ -399,18 +429,22 @@
<p>
Service pages declaratively mark themselves as providing handling
functionality for particular intent actions and types. A User Agent MUST NOT
- deliver an intent to a page which is not described in its metadata
- describing what intents it can handle. The algorithm for matching intents is
- that the action string provided in invocation and registration must match
- exactly, and the type strings must match exactly except for possible [[!RFC2046]]
- MIME subtype wildcards.
+ deliver an Intent to a page which does not include markup describing what
+ intents it can handle which matches the intent being delivered. The algorithm
+ for matching intents is that the action string provided in invocation and
+ registration must match exactly, and the type strings must match exactly
+ except for possible [[!RFC2046]] MIME subtype wildcards. MIME parameters
+ specified in the Service page markup will be checked and must match exactly,
+ except for MIME-formatted strings with MIME subtype wildcards. MIME
+ parameters which are included in the intent and which are not specified do
+ not impact delivery.
<pre>
<!ENTITY % Disposition "{window|inline}">
<!ELEMENT INTENT - O EMPTY -- a Web Intents registration →
<!ATTLIST INTENT
action %URI; #IMPLIED -- URI specifying action --
- type %ContentTypes,%URI; #IMPLIED -- advisory content type --
+ type %ContentTypes #IMPLIED -- advisory content type --
href %URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition "window" -- where the service is created --
@@ -419,7 +453,7 @@
</p>
<p>
The <code>disposition</code> attribute allows a service to choose which
- context to be opened in. The User Agent MUST NOT allow the client any
+ context to be opened in. The User Agent MUST NOT allow the Client page any
ability to change the disposition. The <code>window</code> disposition means
that the service is opened in a new tab or window context. The
<code>inline</code> disposition means that the User Agent SHOULD open the
@@ -447,8 +481,11 @@
assumed to be registered specifically for a <code>text/plain</code> type.
</p>
<p>
- The User Agent SHOULD not obey any registration markup which has both
- <code>action</code> and <code>type</code> attributes missing.
+ The User Agent SHOULD treat any registration markup which has both
+ <code>action</code> and <code>type</code> attributes missing as if the
+ markup specified no intent capability on the page. That is, a page may
+ unregister itself quietly by removing the tag altogether, or explicitly
+ by keeping the tag present, but empty.
</p>
</section>
@@ -461,11 +498,11 @@
the user to configure that page as a web intents service. The details of
this process is left up to the User Agent. The model is that the page
advises of the ability to handle intents, and the User Agent may remember
- that, but
+ that.
</p>
<p>
The User Agent MUST NOT allow web pages the ability to discover passively
- which services the user has configured to handler particular intents,
+ which services the user has configured to handle particular intents,
or any intents, whether by enumeration or exact query. There may be
mechanisms for the user to actively grant this information to web pages,
but it MUST NOT be made available passively.
@@ -504,7 +541,13 @@
declaring themselves as intent handlers. This means that any use of
<code>window.intent</code> in pages which do not explicitly declare
themselves as web intents handlers MUST NOT be overwritten by the User
- Agent.
+ Agent. It also means that Service pages cannot access
+ <code>window.intent</code> in scripts which occur before the page parses
+ the intents registration markup. If such scripts are simply declaring
+ functions to be called later, that will work, but scripts which run before
+ the registration markup is parsed won't find <code>window.intent</code>
+ set, even though it may be made available later in the page load, and so are
+ likely broken.
</p>
<p>
When a new context is opened for the service page, the User Agent MUST
@@ -520,14 +563,15 @@
if any.
</p>
<p>
- The User Agent SHOULD allow any serializable object to be passed between
- client to service and back from service to client. This includes Blobs [[!BLOB]],
- MessagePorts, etc. The User Agent MAY inspect the payload of intents and
- present specialized UI corresponding to well-known intent types. The User
- Agent MUST NOT categorically prohibit dispatch of unknown intent types.
- This is not meant to prohibit the User Agent from performing filtering
- functions on intents, such as suppressing unwanted intent invocations,
- intents as used as an attack vector, and other mis-use.
+ The User Agent SHOULD allow any serializable and/or Transferable object
+ to be passed between client to service and back from service to client.
+ This includes Blobs [[!BLOB]], MessagePorts, etc. The User Agent MAY inspect
+ the payload of intents and present specialized UI corresponding to
+ well-known intent types. The User Agent MUST NOT categorically prohibit
+ dispatch of unknown intent types. This is not meant to prohibit the User
+ Agent from performing filtering functions on intents, such as suppressing
+ unwanted intent invocations, intents as used as an attack vector, and
+ other mis-use.
</p>
<p>
In the same way User Agents MAY dispatch intents caused by non-web
@@ -535,19 +579,19 @@
web applications to handlers which are not web applications. In those
cases, the User Agent SHOULD provide a public API mechanism for external
connection to the intent dispatch mechanism selected. For example, the
- User Agent may be able to run an Operating System level command in
+ User Agent may be able to run an Operating System command in
response to an intent. The User Agent could provide a configuration
interface such that the user can install handler applications, and a
documented format in which intent payload data is translated to that
- application. In these cases, the requirement that User Agents SHOULD pass
- any serializable object may need to be relaxed for some kinds of handlers.
+ application. In these cases, the requirement that User Agents pass
+ any serializable object is relaxed for some kinds of handlers.
</p>
<p>
- User Agents MAY also dispatch intents based on data-specific controls
- derived from microdata in pages. For instance, if the user has services
- registered which handle text/vcard, then the User Agent may provide the
- user with a way to invoke particular intents that consume such data as it
- detects it in web pages.
+ User Agents MAY also dispatch intents directly based on data-specific controls
+ derived from microdata in pages, or based on other User Agent-level
+ features. For instance, if the user has services registered which handle
+ text/vcard, then the User Agent may provide the user with a way to invoke
+ particular intents that consume such data as it detects it in web pages.
</p>
<p>
If the user has no services registered for a particular type of intent,
@@ -562,7 +606,7 @@
<section>
<h3>Sharing</h3>
<p>
- Web Intents should be useful to enable to share content as they
+ Web Intents should be useful to enable users to share content as they
encounter it on web pages. Whether by implicit controls made available
by the User Agent or explicit controls placed in web pages, Web Intents
should handle the use case of a user wishing to share a page as a whole,
--- a/spec/Overview.html Tue Jan 31 13:57:04 2012 -0800
+++ b/spec/Overview.html Tue Jan 31 14:49:31 2012 -0800
@@ -477,7 +477,7 @@
pre.sh_sourceCode .sh_attribute { color: #006400; }
</style><link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8"></head>
- <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Web Intents</h1><h2 id="w3c-editor-s-draft-30-january-2012"><acronym title="World Wide Web Consortium">W3C</acronym> Editor's Draft 30 January 2012</h2><dl><dt>This version:</dt><dd><a href="http://dev.w3.org/2011/webapps/TODO.html">http://dev.w3.org/2011/webapps/TODO.html</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/web-intents/">http://www.w3.org/TR/web-intents/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2011/webapps/TODO.html">http://dev.w3.org/2011/webapps/TODO.html</a></dd><dt>Previous version:</dt><dd>none</dd><dt>Editors:</dt><dd><span>Greg Billock</span>, <a href="http://google.com/">Google</a></dd>
+ <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Web Intents</h1><h2 id="w3c-editor-s-draft-31-january-2012"><acronym title="World Wide Web Consortium">W3C</acronym> Editor's Draft 31 January 2012</h2><dl><dt>This version:</dt><dd><a href="http://dev.w3.org/2011/webapps/TODO.html">http://dev.w3.org/2011/webapps/TODO.html</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/web-intents/">http://www.w3.org/TR/web-intents/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2011/webapps/TODO.html">http://dev.w3.org/2011/webapps/TODO.html</a></dd><dt>Previous version:</dt><dd>none</dd><dt>Editors:</dt><dd><span>Greg Billock</span>, <a href="http://google.com/">Google</a></dd>
<dd><span>James Hawkins</span>, <a href="http://google.com/">Google</a></dd>
<dd><span>Paul Kinlan</span>, <a href="http://google.com/">Google</a></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2012 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
@@ -491,7 +491,7 @@
pages to create, receive, and reply to Web Intents messages, and the
procedures the User Agent carries out to facilitate that process.
</p>
- </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document was published by the <a href="http://www.w3.org/2008/webapps/">Web Applications (WebApps) Working Group</a> as an Editor's Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-web-intents@w3.org">public-web-intents@w3.org</a> (<a href="mailto:public-web-intents-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-web-intents/">archives</a>). All feedback is welcome.</p><p>Publication as an Editor's Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="TODO" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#example" class="tocxref"><span class="secno">1.1 </span>Example</a></li></ul></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#actors" class="tocxref"><span class="secno">2.1 </span>Actors</a></li><li class="tocline"><a href="#life-cycle-of-intents" class="tocxref"><span class="secno">2.2 </span>Life cycle of intents</a></li></ul></li><li class="tocline"><a href="#api-description" class="tocxref"><span class="secno">3. </span>API Description</a><ul class="toc"><li class="tocline"><a href="#intent-object" class="tocxref"><span class="secno">3.1 </span>Intent object</a><ul class="toc"><li class="tocline"><a href="#attributes" class="tocxref"><span class="secno">3.1.1 </span>Attributes</a></li><li class="tocline"><a href="#methods" class="tocxref"><span class="secno">3.1.2 </span>Methods</a></li></ul></li><li class="tocline"><a href="#invocation-api" class="tocxref"><span class="secno">3.2 </span>Invocation API</a><ul class="toc"><li class="tocline"><a href="#methods-1" class="tocxref"><span class="secno">3.2.1 </span>Methods</a></li></ul></li><li class="tocline"><a href="#delivery-and-response-api" class="tocxref"><span class="secno">3.3 </span>Delivery and Response API</a><ul class="toc"><li class="tocline"><a href="#attributes-1" class="tocxref"><span class="secno">3.3.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#registration-markup" class="tocxref"><span class="secno">3.4 </span>Registration Markup</a></li></ul></li><li class="tocline"><a href="#user-agent-behavior" class="tocxref"><span class="secno">4. </span>User Agent Behavior</a></li><li class="tocline"><a href="#use-cases-and-requirements" class="tocxref"><span class="secno">5. </span>Use Cases and Requirements</a><ul class="toc"><li class="tocline"><a href="#sharing" class="tocxref"><span class="secno">5.1 </span>Sharing</a></li><li class="tocline"><a href="#integration-with-local-web-apps" class="tocxref"><span class="secno">5.2 </span>Integration with local web apps</a></li><li class="tocline"><a href="#persistent-connections" class="tocxref"><span class="secno">5.3 </span>Persistent connections</a></li><li class="tocline"><a href="#integration-with-external-applications" class="tocxref"><span class="secno">5.4 </span>Integration with external applications</a></li><li class="tocline"><a href="#translating-existing-web-platform-features-to-intents" class="tocxref"><span class="secno">5.5 </span>Translating existing web platform features to intents</a></li><li class="tocline"><a href="#authentication" class="tocxref"><span class="secno">5.6 </span>Authentication</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div>
+ </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document was published by the <a href="http://www.w3.org/2008/webapps/">Web Applications (WebApps) Working Group</a> as an Editor's Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-web-intents@w3.org">public-web-intents@w3.org</a> (<a href="mailto:public-web-intents-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-web-intents/">archives</a>). All feedback is welcome.</p><p>Publication as an Editor's Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="TODO" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#example" class="tocxref"><span class="secno">1.1 </span>Example</a></li><li class="tocline"><a href="#normative-parts" class="tocxref"><span class="secno">1.2 </span>Normative parts</a></li></ul></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#actors" class="tocxref"><span class="secno">2.1 </span>Actors</a></li><li class="tocline"><a href="#life-cycle-of-intents" class="tocxref"><span class="secno">2.2 </span>Life cycle of Intents</a></li></ul></li><li class="tocline"><a href="#api-description" class="tocxref"><span class="secno">3. </span>API Description</a><ul class="toc"><li class="tocline"><a href="#intent-object" class="tocxref"><span class="secno">3.1 </span>Intent object</a><ul class="toc"><li class="tocline"><a href="#attributes" class="tocxref"><span class="secno">3.1.1 </span>Attributes</a></li><li class="tocline"><a href="#methods" class="tocxref"><span class="secno">3.1.2 </span>Methods</a></li></ul></li><li class="tocline"><a href="#invocation-api" class="tocxref"><span class="secno">3.2 </span>Invocation API</a><ul class="toc"><li class="tocline"><a href="#methods-1" class="tocxref"><span class="secno">3.2.1 </span>Methods</a></li></ul></li><li class="tocline"><a href="#delivery-and-response-api" class="tocxref"><span class="secno">3.3 </span>Delivery and Response API</a><ul class="toc"><li class="tocline"><a href="#attributes-1" class="tocxref"><span class="secno">3.3.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#registration-markup" class="tocxref"><span class="secno">3.4 </span>Registration Markup</a></li></ul></li><li class="tocline"><a href="#user-agent-behavior" class="tocxref"><span class="secno">4. </span>User Agent Behavior</a></li><li class="tocline"><a href="#use-cases-and-requirements" class="tocxref"><span class="secno">5. </span>Use Cases and Requirements</a><ul class="toc"><li class="tocline"><a href="#sharing" class="tocxref"><span class="secno">5.1 </span>Sharing</a></li><li class="tocline"><a href="#integration-with-local-web-apps" class="tocxref"><span class="secno">5.2 </span>Integration with local web apps</a></li><li class="tocline"><a href="#persistent-connections" class="tocxref"><span class="secno">5.3 </span>Persistent connections</a></li><li class="tocline"><a href="#integration-with-external-applications" class="tocxref"><span class="secno">5.4 </span>Integration with external applications</a></li><li class="tocline"><a href="#translating-existing-web-platform-features-to-intents" class="tocxref"><span class="secno">5.5 </span>Translating existing web platform features to intents</a></li><li class="tocline"><a href="#authentication" class="tocxref"><span class="secno">5.6 </span>Authentication</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div>
<div id="introduction" class="section">
<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
@@ -506,22 +506,24 @@
exchanged data.
</p>
<p>
- An Intent is an action to be performed by a service. It consists of an
- "action" string which tells the service what kind of activity the user
- expects to be performed (e.g., "share" or "edit"), a "type" string which
+ An Intent is a user-initiated action delegated to be performed by a service.
+ It consists of an "action" string which tells the service what kind of activity
+ the user expects to be performed (e.g. "share" or "edit"), a "type" string which
specifies the data payload the service should expect, and the data payload
itself.
</p>
<p>
- A client requests an Intent be handled, the User Agent allows the
- user to select which service to use, and the service performs the action
- of the Intent, possibly using data passed as input in the Intent.
- The service may return data as output to the client.
+ The lifecycle of an Intent is that first, a client requests an Intent be
+ handled. This Intent data is then passed to the User Agent, which allows the
+ user to select which of potentially many possible services to use. Then
+ the service is passed the Intent data and is provided a UI by the User
+ Agent in which to perform the action specified in the Intent. Finally,
+ the service may also return data as output back to the client.
</p>
<p>
Web Intents provides a declarative syntax that allows
- services to list the Intents they handle. Using this method, pages mark
- up what actions they can handle what data types they expect.
+ services to list the Intents they handle. Using this method, services mark
+ up what actions they can handle and which data types they expect.
</p>
<div id="example" class="section">
<h3><span class="secno">1.1 </span>Example</h3>
@@ -538,44 +540,56 @@
"text/uri-list;type=image/jpeg",
getImageDataURI(...));
navigator.startActivity(intent, imageEdited);
-});
+};
function imageEdited(data) {
document.getElementById('image').src = data;
}</pre>
<p>
- This assumes an image editor exists which can consume images specified as
- URIs (including data URIs), and produces a result in the same format. For
- instance, one such editor might be a meme-maker—an application allowing
- the user to place humorous messages on top of pictures they take.
+ This code delegates image editing to third-party applications which can
+ consume images specified as URIs (including data URIs), and produce
+ results in the same format. For instance, one such editor might be
+ a meme-maker—an application allowing the user to place humorous
+ messages on pictures they take.
</p>
<p>
- Now that a picture has been selected and meme text added, the user
- undoubtedly wants to share the result with friends. Again, the photo
- hosting application may not have built-in sharing capabilities, but by
- adding a "share" button near images, and with this kind of accompany code,
- it can accomplish this integration:
+ Now that a picture has been edited in the selected service, and meme text
+ added, the user undoubtedly wants to share the result with friends. Again,
+ the photo hosting application may not have built-in sharing capabilities,
+ but by adding a <b>Share</b> button near images, and with this kind of
+ accompanying code, it can accomplish this integration:
</p>
<pre class="example">document.getElementById('share-photo').onclick = function() {
var intent = new Intent("http://webintents.org/share",
"text/uri-list;type=image/jpeg",
getPublicURIForImage(...));
navigator.startActivity(intent);
-});</pre>
+};</pre>
<p>
+ This code delegates sharing functionality to an existing services chosen
+ by the user which are capable of sharing urls. So a social networking site
+ selected by the user might produce a status update with a thumbnail.
+ A blogging site might provide a UI allowing the user to post the picture.
+ </p><p>
Note that with this integration, other more high-minded services can be
selected by the user as well. Instead of using the service to add funny
- captions, the user can utilize a sophisticated photo editing application
+ captions, the user might utilize a sophisticated photo editing application
to adjust exposure, remove red-eye, or do any number of other
transformations on the image. The user can have many such tools
- registered, and choose any of that set to use at any given time. The photo
- hosting application isn't controlling which such application any given
- user uses, it is loosely coupled with such appliations by providing the
- data necessary for them to carry out their task and controls allowing the
+ registered, and choose any of that set to use for any given image editing
+ task. The photo hosting application isn't controlling which such application
+ any given user uses; it is loosely coupled with such applications by providing the
+ data necessary for them to carry out their task, and controls allowing the
user to launch these activities on the data.
</p>
<p>
- On the service page, it needs to register itself as a service, and
+ In this way, an Intent is like the dual of a hyperlink. With a hyperlink,
+ the source page specifies the exact URL to be navigated to. With an
+ Intent, the source page specifies the nature of the task to be done, and the
+ user can select any of a number of applications to be used to complete the task.
+ </p>
+ <p>
+ On the service side, the page needs to register itself as a Web Intents service, and
handle the incoming intent data, possibly producing a response. That is
done with this kind of code:
</p>
@@ -590,18 +604,27 @@
if (window.intent) {
setImageContentURI(window.intent.data);
}
- }
+ };
document.getElementById('save-button').onclick = function() {
window.intent.postResult(getImageDataURI(...));
- }
+ };
</script></pre>
<p>
- The assumed pieces here are functions which deal with the application's
- image display, for instance putting the image into a canvas and taking it back out
- again as a data URI.
+ The assumed pieces here (on both client and service pages) are functions
+ which deal with the application's image display, for instance putting the
+ image into a canvas and taking it back out again as a data URI. Or
+ producing the public URI of the image on the site.
</p>
- </div>
+ </div>
+
+ <div id="normative-parts" class="section">
+ <h3><span class="secno">1.2 </span>Normative parts</h3>
+ <p>
+ The normative parts of this specification are the API Description and the
+ User Agent Behavior section. All other parts are informative.
+ </p>
+ </div>
</div>
<div id="terminology" class="section">
@@ -613,31 +636,37 @@
<div id="actors" class="section">
<h3><span class="secno">2.1 </span>Actors</h3>
<p>
- A <dfn id="dfn-client">Client</dfn> is a web page which creates an intent and invokes
- it.
+ A <dfn id="dfn-client">Client</dfn> is a web page which creates an Intent and invokes
+ it. The User Agent may also allow non-web-page sources invoke Intents
+ to be delivered. For instance, the User Agent may have UI which
+ effectively triggers Intents delivery, or may register for external OS
+ hooks to trigger Intents.
</p>
<p>
- A <dfn id="dfn-service">Service</dfn> is a web page which can handle a Web Intent,
- possibly returning a piece of data to the calling Client page.
+ A <dfn id="dfn-service">Service</dfn> is a web page which can handle an Intent,
+ possibly returning a piece of data to the calling Client page. Again,
+ the User Agent may have ways to deliver Intents to Services which are
+ not web pages. These may be extension APIs, plug-in helpers, external OS
+ handlers, etc.
</p>
</div>
<div id="life-cycle-of-intents" class="section">
- <h3><span class="secno">2.2 </span>Life cycle of intents</h3>
+ <h3><span class="secno">2.2 </span>Life cycle of Intents</h3>
<p>
<dfn id="dfn-registration">Registration</dfn> is how a Service page informs the User Agent
that it is capable of handling Intents.
</p>
<p>
<dfn id="dfn-invocation">Invocation</dfn> refers to the API by which a Client page
- dispatches an intent for handling.
+ dispatches an Intent for handling.
</p>
<p>
<dfn id="dfn-selection">Selection</dfn> is the mechanism in which the User Agent decides
- which service will handle a particular intent.
+ which Service will handle a particular Intent.
</p>
<p>
- <dfn id="dfn-delivery">Delivery</dfn> is the means by which the User Agent hands intent
- data to a Service page for handling.
+ <dfn id="dfn-delivery">Delivery</dfn> is the means by which the User Agent passes an Intent
+ to a Service page for handling.
</p>
<p>
<dfn id="dfn-response">Response</dfn> is the means in which the Service can respond to an
@@ -652,10 +681,10 @@
<div id="intent-object" class="section">
<h3><span class="secno">3.1 </span>Intent object</h3>
<p>
- The client requests a specific intent handler and optionally sends in a callback to
- receive data from the service. The browser mediates the service selection by
- enumerating the list of registered services that match the requested
- intent action and type. The user is then able to select which service should handle the intent.
+ The Intent object models a particular task which can be requested by
+ handled by client pages. It is left up to the client page whether to
+ launch multiple Intents simultaneously. Specific Intent objects are
+ immutable once created.
</p>
<pre class="idl"><span class="idlInterface" id="idl-def-Intent">[<span class="extAttr">Constructor(in string action, in string type, in any data) raises DOMException</span>]
interface <span class="idlInterfaceID">Intent</span> {
@@ -667,39 +696,44 @@
};</span>
</pre><div id="attributes" class="section"><h4><span class="secno">3.1.1 </span>Attributes</h4><dl class="attributes"><dt id="widl-Intent-action"><code>action</code> of type <span class="idlAttrType"><a>DOMString</a></span>, readonly</dt><dd>This is an opaque string. Chosen strings <em class="rfc2119" title="should">should</em> be namespaced by a
URL namespace convention. The string <em class="rfc2119" title="must not">must not</em> be empty, or the
- constructor <em class="rfc2119" title="must">must</em> throw an exception.<div><em>No exceptions.</em></div></dd><dt id="widl-Intent-data"><code>data</code> of type <span class="idlAttrType"><a>any</a></span>, readonly</dt><dd>The object used <em class="rfc2119" title="must">must</em> be a Transferable or an object upon which the
- structured clone algorithm can be performed, or the constructor <em class="rfc2119" title="must">must</em>
+ constructor <em class="rfc2119" title="must">must</em> throw an exception.<div><em>No exceptions.</em></div></dd><dt id="widl-Intent-data"><code>data</code> of type <span class="idlAttrType"><a>any</a></span>, readonly</dt><dd>The object used <em class="rfc2119" title="must">must</em> be an object upon which the structured clone
+ algorithm can be performed, including Transferables, or the constructor <em class="rfc2119" title="must">must</em>
throw an exception.<div><em>No exceptions.</em></div></dd><dt id="widl-Intent-type"><code>type</code> of type <span class="idlAttrType"><a>DOMString</a></span>, readonly</dt><dd>The data payload <em class="rfc2119" title="must">must</em> be described by the type parameter.
- Recommended type strings are MIME strings and self-documenting urls. The
- string <em class="rfc2119" title="must not">must not</em> be empty, or the constructor <em class="rfc2119" title="must">must</em> throw an exception.<div><em>No exceptions.</em></div></dd></dl></div><div id="methods" class="section"><h4><span class="secno">3.1.2 </span>Methods</h4><dl class="methods"><dt id="widl-Intent-postFailure-void-any-data"><code>postFailure</code></dt><dd>The payload passed to this method will be returned to the onFailure
+ Recommended type strings are MIME strings or self-documenting urls. The
+ string <em class="rfc2119" title="must not">must not</em> be empty, or the constructor <em class="rfc2119" title="must">must</em> throw an exception.<div><em>No exceptions.</em></div></dd></dl></div><div id="methods" class="section"><h4><span class="secno">3.1.2 </span>Methods</h4><dl class="methods"><dt id="widl-Intent-postFailure-void-any-data"><code>postFailure</code></dt><dd><b>Only present when the Intent object is delivered to the Service
+ page.</b> The payload passed to this method will be returned to the onFailure
callback registered by the client page in the startActivity call (if any).
- The playload must be a Transferable object upon which the structured
- clone algorithm can be performed.<table class="parameters"><tr><th>Parameter</th><th>Type</th><th>Nullable</th><th>Optional</th><th>Description</th></tr><tr><td class="prmName">data</td><td class="prmType"><code><a>any</a></code></td><td class="prmNullFalse">✘</td><td class="prmOptFalse">✘</td><td class="prmDesc"></td></tr></table><div><em>No exceptions.</em></div><div><em>Return type: </em><code><a>void</a></code></div></dd><dt id="widl-Intent-postResult-void-any-data"><code>postResult</code></dt><dd>The payload passed to this method will be returned to the onSuccess
+ The playload must be an object upon which the structured clone algorithm
+ can be performed, including Transferables. [<cite><a class="bibref" rel="biblioentry" href="#bib-HTML5">HTML5</a></cite>]<table class="parameters"><tr><th>Parameter</th><th>Type</th><th>Nullable</th><th>Optional</th><th>Description</th></tr><tr><td class="prmName">data</td><td class="prmType"><code><a>any</a></code></td><td class="prmNullFalse">✘</td><td class="prmOptFalse">✘</td><td class="prmDesc"></td></tr></table><div><em>No exceptions.</em></div><div><em>Return type: </em><code><a>void</a></code></div></dd><dt id="widl-Intent-postResult-void-any-data"><code>postResult</code></dt><dd><b>Only present when the Intent object is delivered to the
+ Service page.</b> The payload passed to this method will be returned to the onSuccess
callback registered by the client page in the startActivity call (if any).
- The payload must be a Transferable object [<cite><a class="bibref" rel="biblioentry" href="#bib-HTML5">HTML5</a></cite>] upon which the structured
- clone algorithm can be performed.<table class="parameters"><tr><th>Parameter</th><th>Type</th><th>Nullable</th><th>Optional</th><th>Description</th></tr><tr><td class="prmName">data</td><td class="prmType"><code><a>any</a></code></td><td class="prmNullFalse">✘</td><td class="prmOptFalse">✘</td><td class="prmDesc"></td></tr></table><div><em>No exceptions.</em></div><div><em>Return type: </em><code><a>void</a></code></div></dd></dl></div>
+ The payload must be an object upon which the structured clone algorithm can be
+ performed, including Transferables. [<cite><a class="bibref" rel="biblioentry" href="#bib-HTML5">HTML5</a></cite>] <table class="parameters"><tr><th>Parameter</th><th>Type</th><th>Nullable</th><th>Optional</th><th>Description</th></tr><tr><td class="prmName">data</td><td class="prmType"><code><a>any</a></code></td><td class="prmNullFalse">✘</td><td class="prmOptFalse">✘</td><td class="prmDesc"></td></tr></table><div><em>No exceptions.</em></div><div><em>Return type: </em><code><a>void</a></code></div></dd></dl></div>
</div>
<div id="invocation-api" class="section">
<h3><span class="secno">3.2 </span>Invocation API</h3>
<p>
- The client invokes an intent by constructing an object as above and invoking
- a <code>navigator.startActivity</code> function on it. The callbacks are invoked when
- the intent has been handled.
+ The client invokes an intent by constructing an Intent object as above and invoking
+ the <code>navigator.startActivity</code> function on it. The callbacks
+ passed to this method are invoked when the intent has been handled by the service.
+ The User Agent will mediate the service selection by enumerating the list of
+ registered services that match the requested
+ intent action and type. The user is then able to select which service should handle the intent.
</p>
<pre class="idl"><span class="idlInterface" id="idl-def-Intents">[<span class="extAttr">NoInterfaceObject</span>]
interface <span class="idlInterfaceID">Intents</span> {
<span class="idlMethod"> <span class="idlMethType"><a>void</a></span> <span class="idlMethName"><a href="#widl-Intents-startActivity-void-Intent-intent--onSuccess--onFailure">startActivity</a></span> (<span class="idlParam"><span class="idlParamType"><a href="#idl-def-Intent" class="idlType"><code>Intent</code></a></span> <span class="idlParamName">intent</span></span>, <span class="idlParam">optional <span class="idlParamType"><a></a></span> <span class="idlParamName">onSuccess</span></span>, <span class="idlParam">optional <span class="idlParamType"><a></a></span> <span class="idlParamName">onFailure</span></span>) raises (<span class="idlRaises"><a>DOMException</a></span>);</span>
};</span>
-</pre><div id="methods-1" class="section"><h4><span class="secno">3.2.1 </span>Methods</h4><dl class="methods"><dt id="widl-Intents-startActivity-void-Intent-intent--onSuccess--onFailure"><code>startActivity</code></dt><dd>Called to invoke an intent service. The intent object is described
+</pre><div id="methods-1" class="section"><h4><span class="secno">3.2.1 </span>Methods</h4><dl class="methods"><dt id="widl-Intents-startActivity-void-Intent-intent--onSuccess--onFailure"><code>startActivity</code></dt><dd>Called to invoke an intent service. The Intent object is described
above. The onSuccess handler, if any, will be called by the user agent if
the service is dispatched, processes the intent, and calls postResult on
- the intent object it receives. The handler will be invoked with one
+ the Intent object it receives. The handler will be invoked with one
parameter: the data received from the service.
The onFailure handler, if any, will be called by the user agent if
the service cannot be dispatched, if the user aborts the selection
process, or if a service was chosen, received the intent, processes the intent,
- and calls postFailure on the intent object it receives. The handler will be invoked with one
+ and calls postFailure on the Intent object it receives. The handler will be invoked with one
parameter: the data received from the service.
User Agents <em class="rfc2119" title="should">should</em> restrict this method to only be successfully callable within the
context of an explicit user gesture.
@@ -718,7 +752,7 @@
<div id="delivery-and-response-api" class="section">
<h3><span class="secno">3.3 </span>Delivery and Response API</h3>
<p>
- When the user agent loads a service page to handle an intent invocation, it
+ When the User Agent loads a Service page to handle an Intent invocation, it
will place a <code>window.intent</code> object in the scope of the page.
</p>
@@ -726,14 +760,19 @@
interface <span class="idlInterfaceID">IntentProvider</span> {
<span class="idlAttribute"> readonly attribute <span class="idlAttrType"><a href="#idl-def-Intent" class="idlType"><code>Intent</code></a></span> <span class="idlAttrName"><a href="#widl-IntentProvider-intent">intent</a></span>;</span>
};</span>
-</pre><div id="attributes-1" class="section"><h4><span class="secno">3.3.1 </span>Attributes</h4><dl class="attributes"><dt id="widl-IntentProvider-intent"><code>intent</code> of type <span class="idlAttrType"><a href="#idl-def-Intent" class="idlType"><code>Intent</code></a></span>, readonly</dt><dd>The intent object as delivered to the service page.<div><em>No exceptions.</em></div></dd></dl></div>
+</pre><div id="attributes-1" class="section"><h4><span class="secno">3.3.1 </span>Attributes</h4><dl class="attributes"><dt id="widl-IntentProvider-intent"><code>intent</code> of type <span class="idlAttrType"><a href="#idl-def-Intent" class="idlType"><code>Intent</code></a></span>, readonly</dt><dd>The intent object as delivered to the service page (includes
+ postResult and postFailure methods).<div><em>No exceptions.</em></div></dd></dl></div>
<pre class="idl"><span class="idlImplements"><a>DOMWindow</a> implements <a href="#idl-def-IntentProvider" class="idlType"><code>IntentProvider</code></a>;</span></pre><div class="idlImplementsDesc"><p>All instances of the <code><a>DOMWindow</a></code> type are defined to also implement the <a href="#idl-def-IntentProvider" class="idlType"><code>IntentProvider</code></a> interface.</p></div>
<p>
- This object will only be made available to service pages when they are
- loaded in the context of an intent invocation. In other situations, the User
- Agent <em class="rfc2119" title="must not">must not</em> make <code>DOMWindow</code> implement
- <code>IntentProvider</code>.
+ This object will only be made available to Service pages when they are
+ loaded in the context of an intent invocation. Even if the same URL is
+ loaded in other situations, the User Agent <em class="rfc2119" title="must not">must not</em> make
+ <code>DOMWindow</code> implement <code>IntentProvider</code>. Similarly, if
+ a Service page is registered, but the User Agent loads it and it does not
+ contain the declarative markup marking it as expecting to handle the Intent
+ the User Agent is delivering, the User Agent <em class="rfc2119" title="must not">must not</em> make
+ <code>DOMWindow</code> implement <code>IntentProvider</code>.
</p>
<p>
The <code>window.intent</code> object <em class="rfc2119" title="must">must</em> be made available across
@@ -758,12 +797,20 @@
http://login.example.com
</p>
<p>
- In other words, in the browsing context in which the intent is originally
- delivered, the intent data <em class="rfc2119" title="must">must</em> be available to pages in a redirect sequence
- when they are in the same origin as that to which it was originally
- delivered, but <em class="rfc2119" title="must not">must not</em> be available to any other pages. If the user navigates to a
- different URL, even within the same origin, the intent data <em class="rfc2119" title="must not">must not</em> be made
- available.
+ The <code>window.intent</code> object <em class="rfc2119" title="must">must</em> be made available to a page on
+ the same-origin as the originally-delivered page if the user initiates a
+ navigation on the browsing context in which that Service page is displayed,
+ AND the new page has declarative syntax marking it as a handler for the
+ Intent type the User Agent is delivering.
+ </p>
+ <p>
+ In other words, in the browsing context in which the Intent is originally
+ delivered, the intent data <em class="rfc2119" title="must">must</em> be available to pages in a redirect or
+ navigation sequence when they are in the same origin as that to which it was originally
+ delivered, but <em class="rfc2119" title="must not">must not</em> be available to any other pages. This allows Service
+ pages to delegate handling, to redirect to login screens, and so forth, but
+ does not make the Intent data available to any such pages encountered which
+ are not in the same origin.
</p>
</div>
@@ -772,26 +819,30 @@
<p>
Service pages declaratively mark themselves as providing handling
functionality for particular intent actions and types. A User Agent <em class="rfc2119" title="must not">must not</em>
- deliver an intent to a page which is not described in its metadata
- describing what intents it can handle. The algorithm for matching intents is
- that the action string provided in invocation and registration must match
- exactly, and the type strings must match exactly except for possible [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2046">RFC2046</a></cite>]
- MIME subtype wildcards.
- </p><pre> <!ENTITY % Disposition "window|inline">
+ deliver an Intent to a page which does not include markup describing what
+ intents it can handle which matches the intent being delivered. The algorithm
+ for matching intents is that the action string provided in invocation and
+ registration must match exactly, and the type strings must match exactly
+ except for possible [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2046">RFC2046</a></cite>] MIME subtype wildcards. MIME parameters
+ specified in the Service page markup will be checked and must match exactly,
+ except for MIME-formatted strings with MIME subtype wildcards. MIME
+ parameters which are included in the intent and which are not specified do
+ not impact delivery.
+ </p><pre> <!ENTITY % Disposition "{window|inline}">
<!ELEMENT INTENT - O EMPTY -- a Web Intents registration →
<!ATTLIST INTENT
- action %URI; #<em class="rfc2119" title="required">required</em> -- URI specifying action --
- type %ContentTypes; #<em class="rfc2119" title="required">required</em> -- advisory content type --
- href %URI; #IMPLIED -- URI for linked resource --
- title CDATA #IMPLIED -- service title --
- disposition %Disposition (window) -- where the service is created --
+ action %URI; #IMPLIED -- URI specifying action --
+ type %ContentTypes #IMPLIED -- advisory content type --
+ href %URI; #IMPLIED -- URI for linked resource --
+ title %i18n; #IMPLIED -- service title --
+ disposition %Disposition "window" -- where the service is created --
>
</pre>
<p></p>
<p>
- The <code>dispositon</code> attribute allows a service to choose which
- context to be opened in. The User Agent <em class="rfc2119" title="must not">must not</em> allow the client any
+ The <code>disposition</code> attribute allows a service to choose which
+ context to be opened in. The User Agent <em class="rfc2119" title="must not">must not</em> allow the Client page any
ability to change the disposition. The <code>window</code> disposition means
that the service is opened in a new tab or window context. The
<code>inline</code> disposition means that the User Agent <em class="rfc2119" title="should">should</em> open the
@@ -800,8 +851,30 @@
under the control of the client page.
</p>
<p>
- The User Agent <em class="rfc2119" title="should">should</em> discard any registration markup which is not
- same-origin.
+ The User Agent <em class="rfc2119" title="must">must</em> not obey any registration markup which is not
+ same-origin. That is, a page may only register <code>href</code> attributes
+ for other service handlers on its same origin. A page may register itself
+ as a Service handler, by leaving this attribute empty.
+ </p>
+ <p>
+ If the <code>title</code> attribute is missing, the User Agent <em class="rfc2119" title="should">should</em>
+ utilize the title of the registered Service page to guide the user-visible
+ indicator of that Service during Selection.
+ </p>
+ <p>
+ If the <code>action</code> attribute is missing, the intent Service is
+ assumed to handle display of the provided type(s) in that attribute.
+ </p>
+ <p>
+ If the <code>type</code> attribute is missing, the intent Service is
+ assumed to be registered specifically for a <code>text/plain</code> type.
+ </p>
+ <p>
+ The User Agent <em class="rfc2119" title="should">should</em> treat any registration markup which has both
+ <code>action</code> and <code>type</code> attributes missing as if the
+ markup specified no intent capability on the page. That is, a page may
+ unregister itself quietly by removing the tag altogether, or explicitly
+ by keeping the tag present, but empty.
</p>
</div>
@@ -814,11 +887,11 @@
the user to configure that page as a web intents service. The details of
this process is left up to the User Agent. The model is that the page
advises of the ability to handle intents, and the User Agent may remember
- that, but
+ that.
</p>
<p>
The User Agent <em class="rfc2119" title="must not">must not</em> allow web pages the ability to discover passively
- which services the user has configured to handler particular intents,
+ which services the user has configured to handle particular intents,
or any intents, whether by enumeration or exact query. There may be
mechanisms for the user to actively grant this information to web pages,
but it <em class="rfc2119" title="must not">must not</em> be made available passively.
@@ -857,7 +930,13 @@
declaring themselves as intent handlers. This means that any use of
<code>window.intent</code> in pages which do not explicitly declare
themselves as web intents handlers <em class="rfc2119" title="must not">must not</em> be overwritten by the User
- Agent.
+ Agent. It also means that Service pages cannot access
+ <code>window.intent</code> in scripts which occur before the page parses
+ the intents registration markup. If such scripts are simply declaring
+ functions to be called later, that will work, but scripts which run before
+ the registration markup is parsed won't find <code>window.intent</code>
+ set, even though it may be made available later in the page load, and so are
+ likely broken.
</p>
<p>
When a new context is opened for the service page, the User Agent <em class="rfc2119" title="must">must</em>
@@ -873,14 +952,15 @@
if any.
</p>
<p>
- The User Agent <em class="rfc2119" title="should">should</em> allow any serializable object to be passed between
- client to service and back from service to client. This includes Blobs [<cite><a class="bibref" rel="biblioentry" href="#bib-BLOB">BLOB</a></cite>],
- MessagePorts, etc. The User Agent <em class="rfc2119" title="may">may</em> inspect the payload of intents and
- present specialized UI corresponding to well-known intent types. The User
- Agent <em class="rfc2119" title="must not">must not</em> categorically prohibit dispatch of unknown intent types.
- This is not meant to prohibit the User Agent from performing filtering
- functions on intents, such as suppressing unwanted intent invocations,
- intents as used as an attack vector, and other mis-use.
+ The User Agent <em class="rfc2119" title="should">should</em> allow any serializable and/or Transferable object
+ to be passed between client to service and back from service to client.
+ This includes Blobs [<cite><a class="bibref" rel="biblioentry" href="#bib-BLOB">BLOB</a></cite>], MessagePorts, etc. The User Agent <em class="rfc2119" title="may">may</em> inspect
+ the payload of intents and present specialized UI corresponding to
+ well-known intent types. The User Agent <em class="rfc2119" title="must not">must not</em> categorically prohibit
+ dispatch of unknown intent types. This is not meant to prohibit the User
+ Agent from performing filtering functions on intents, such as suppressing
+ unwanted intent invocations, intents as used as an attack vector, and
+ other mis-use.
</p>
<p>
In the same way User Agents <em class="rfc2119" title="may">may</em> dispatch intents caused by non-web
@@ -888,19 +968,19 @@
web applications to handlers which are not web applications. In those
cases, the User Agent <em class="rfc2119" title="should">should</em> provide a public API mechanism for external
connection to the intent dispatch mechanism selected. For example, the
- User Agent may be able to run an Operating System level command in
+ User Agent may be able to run an Operating System command in
response to an intent. The User Agent could provide a configuration
interface such that the user can install handler applications, and a
documented format in which intent payload data is translated to that
- application. In these cases, the requirement that User Agents <em class="rfc2119" title="should">should</em> pass
- any serializable object may need to be relaxed for some kinds of handlers.
+ application. In these cases, the requirement that User Agents pass
+ any serializable object is relaxed for some kinds of handlers.
</p>
<p>
- User Agents <em class="rfc2119" title="may">may</em> also dispatch intents based on data-specific controls
- derived from microdata in pages. For instance, if the user has services
- registered which handle text/vcard, then the User Agent may provide the
- user with a way to invoke particular intents that consume such data as it
- detects it in web pages.
+ User Agents <em class="rfc2119" title="may">may</em> also dispatch intents directly based on data-specific controls
+ derived from microdata in pages, or based on other User Agent-level
+ features. For instance, if the user has services registered which handle
+ text/vcard, then the User Agent may provide the user with a way to invoke
+ particular intents that consume such data as it detects it in web pages.
</p>
<p>
If the user has no services registered for a particular type of intent,
@@ -915,7 +995,7 @@
<div id="sharing" class="section">
<h3><span class="secno">5.1 </span>Sharing</h3>
<p>
- Web Intents should be useful to enable to share content as they
+ Web Intents should be useful to enable users to share content as they
encounter it on web pages. Whether by implicit controls made available
by the User Agent or explicit controls placed in web pages, Web Intents
should handle the use case of a user wishing to share a page as a whole,
@@ -1010,3 +1090,4 @@
</dd><dt id="bib-HTML5">[HTML5]</dt><dd>Ian Hickson; David Hyatt. <a href="http://www.w3.org/TR/html5"><cite>HTML5.</cite></a> 25 May 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/html5">http://www.w3.org/TR/html5</a>
</dd><dt id="bib-RFC2046">[RFC2046]</dt><dd>N. Freed; N. Borenstein. <a href="http://www.ietf.org/rfc/rfc2046.txt"><cite>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.</cite></a> November 1996. Internet RFC 2046. URL: <a href="http://www.ietf.org/rfc/rfc2046.txt">http://www.ietf.org/rfc/rfc2046.txt</a>
</dd></dl></div><div id="informative-references" class="section"><h3><span class="secno">B.2 </span>Informative references</h3><p>No informative references.</p></div></div></body></html>
+