--- a/spec/Overview-respec.html Tue Sep 04 14:18:17 2012 -0700
+++ b/spec/Overview-respec.html Tue Sep 11 13:28:16 2012 -0700
@@ -260,16 +260,16 @@
<dt>DOMString type</dt>
<dd>A string indicating the type of the data payload. The data payload
MUST be described by this parameter, which MUST NOT be empty.</dd>
- <dt>any data</dt>
+ <dt>any? data</dt>
<dd>The data payload used MUST be an object upon which the structured
clone algorithm can be performed, including Transferables.</dd>
- <dt>sequence<Transferable> transfer</dt>
+ <dt>sequence<Transferable>? transfer</dt>
<dd>The list of Transferables, for use in the structured clone
algorithm.</dd>
- <dt>URL service</dt>
+ <dt>URL? service</dt>
<dd>When present, this field marks the intent as an explicit intent. The
value MUST be an absolute URL.</dd>
- <dt>sequence<URL> suggestions</dt>
+ <dt>sequence<URL>? suggestions</dt>
<dd>When present, this field provides a list of suggested Service URLs,
each of which is an absolute URL that the Client is aware of and which
can handle the intent.</dd>
@@ -415,14 +415,14 @@
</p>
<p>
The <code>window.intent</code> object MUST be made available across
- same-origin redirects of the service page. It MUST NOT be available if
+ same-origin redirects of the service page. It MUST NOT be made available if
redirects cross an origin boundary.
</p>
<p>
So the following redirect sequence
will work: http://example.com/service to http://example.com/login back to
http://example.com/service. In this case, the <code>window.intent</code>
- data would be available to all three page loads.
+ data would be made available to all three page loads.
</p>
<p>
This will also work: http://example.com/service to
@@ -444,13 +444,17 @@
</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
+ delivered, the intent data MUST be made available to pages in a redirect or
navigation sequence when they are in the same origin as that to which it was originally
- delivered (and have the enabling markup), but MUST NOT be available to any other pages.
+ delivered (and have the enabling markup), but MUST NOT be made 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>
+ <p>
+ Multiple invocation by code in the service page MUST throw a Javascript
+ exception. The User Agent MUST NOT allow a particular Intent to be replied to multiple times.
+ </p>
</section>
<section>
@@ -530,22 +534,22 @@
<p>
The intent tags on the service handler page itself SHOULD be interpreted by
the User Agent as authoritative. That is, if the User Agent loads a service
- page, and sees that not all intent descriptors it believes will be handled
- by the page are actually handled, it would replace the currently-registered
- set with the new set declared by the page.
+ page, and sees that its intent descriptors do not match the set currently
+ registered for that page, it would replace the currently-registered
+ set with the set discovered on the more current load of the page.
</p>
- <h4>HTTP Error Codes on Service Pages</h4>
+ <h4>HTTP Status Codes on Service Pages</h4>
<p>
If a registered service page is retrieved and has a non-20x error code
[[!HTTP11]], the User Agent SHOULD take the following actions:</p>
<p>
30x: redirect to the indicated page. If the page is on-domain, and has
- intent markup, the intent will be re-delivered. If the redirect is permanent
- (301), the User Agent MAY update its service registration records to reflect
- that.
+ intent markup, the intent will be made available to the redirect page.
+ If the redirect is permanent (301), the User Agent MAY update its service
+ registration records to reflect that.
</p>
<p>
- 40x: indicate to the user that the page cannot be loaded, along with any
+ 4xx: indicate to the user that the page cannot be loaded, along with any
remediation capabilities (i.e. authentication for 403 or payments for 402).
In the case of error 410, the User Agent SHOULD unregister the handler from
its internal registry.
@@ -553,6 +557,9 @@
<p>
50x: indicate to the user that the page cannot be loaded.
</p>
+ <p>
+ If the desired registered service page cannot be loaded, the User Agent SHOULD
+ display UI allowing the user to select another service.
</p>
</section>
@@ -560,6 +567,8 @@
<section>
<h2>User Agent Behavior</h2>
+ <section>
+ <h3>Service Registration</h3>
<p>
When the User Agent loads a page with registration markup, it SHOULD allow
the user to configure that page as a web intents service. The details of
@@ -582,6 +591,18 @@
or pre-bundled. (TODO: add example of a local network service)
</p>
<p>
+ The User Agent MAY act as a Client or a Service. For example, the User
+ Agent may implement particular affordances which directly launch Intents
+ that may be handled by registered Services, or present UI allowing its own
+ functionality to be used alongside other registered Services to handle
+ Intents. For instance, 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.
+ </p>
+ </section>
+ <section>
+ <h3>Invocation and Dispatch</h3>
+ <p>
For intents invoked by client web applications, the User Agent MUST
require that such invocations be in the context of a user gesture. User
Agents MAY also dispatch intents invoked through other mechanisms. For
@@ -595,16 +616,15 @@
helper applications, proxy them through connections to other hardware,
etc. In general, though, the User Agent MUST provide a way for the user
to configure which intents are delivered to which services. This process
- SHOULD be configurable on a per-invocation basis for most intents,
- although defaulting rules, as long as they are configurable by the user,
- are expected to mean that the User Agent need not present specific UI
- controls on every invocation.
+ SHOULD be configurable on a per-invocation basis. Defaulting rules,
+ as long as they are configurable by the user, are expected to result in
+ the User Agent not presenting full UI controls on every invocation.
</p>
<p>
When the User Agent delivers an intent payload to a web application, it
MUST make the <code>window.intent</code> object available as the document
is loaded and parsed, so that scripts on the page may process the intent
- data as they load. User agents MUST NOT place a <code>window.intent</code>
+ data as they load. User agents MUST NOT make available a <code>window.intent</code>
object in the scope of pages which do not have registration metadata
declaring themselves as intent handlers. This means that any use of
<code>window.intent</code> in pages which do not explicitly declare
@@ -614,8 +634,8 @@
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.
+ made available, 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
@@ -640,13 +660,10 @@
"share" type, or that the Client is asking them to pick an image.
</p>
<p>
- The User Agent MAY act as a Client or a Service. For example, the User
- Agent may implement particular affordances which directly launch Intents
- that may be handled by registered Services, or present UI allowing its own
- functionality to be used alongside other registered Services to handle
- Intents. For instance, 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.
+ If the user has no services registered for a particular type of intent,
+ the User Agent MAY display options from other sources of data about
+ services it knows can handle that intent type so that the user can
+ complete the activity.
</p>
<p>
The User Agent MUST NOT categorically prohibit
@@ -655,12 +672,7 @@
unwanted intent invocations, intents as used as an attack vector, and
other mis-use.
</p>
- <p>
- If the user has no services registered for a particular type of intent,
- the User Agent MAY display options from other sources of data about
- services it knows can handle that intent type so that the user can
- complete the activity.
- </p>
+ </section>
<section>
<h3>Explicit Intents</h3>
<p>
@@ -821,7 +833,7 @@
It should be possible to translate a few existing features to use Web
Intents, thus putting web applications on the same footing as local
resources. For instance, it should be possible for the User Agent to
- translate file selection controls to intents such that the use can
+ translate file selection controls to intents such that the user can
choose to upload a file from a cloud storage locker as well as from
local disk. In these cases, the User Agent may supply built-in intent
handlers corresponding to existing functionality.
@@ -852,13 +864,13 @@
<section>
<h2>Privacy Considerations</h2>
<p>
- The user needs to have confidence that the Service will user the data
+ The user needs to have confidence that the Service will use the data
associated with the action for the purpose intended and not share or retain
the data inappropriately [[WEBAPP-PRIVACY-BESTPRACTICES]]. For this reason
it is important that the user have control over Intents, in particular the
selection mechanism which determines which Service will handle a particular Intent.
This offers the possibility of user decision and control related to the choice of
- Service, allowing them to take into account expectations regarding the Service,
+ Service, allowing the user to take into account expectations regarding the Service,
including Service policies related to retention and secondary use. This relates
to the privacy principles of control and consent [[DAP-PRIVACY-REQS]]. For
this reason a user should be made aware of explicit intents and be able to view and
--- a/spec/Overview.html Tue Sep 04 14:18:17 2012 -0700
+++ b/spec/Overview.html Tue Sep 11 13:28:16 2012 -0700
@@ -373,7 +373,7 @@
</p>
<h1 class="title" id="title">Web Intents</h1>
- <h2 id="w3c-editor-s-draft-04-september-2012"><abbr title="World Wide Web Consortium">W3C</abbr> Editor's Draft 04 September 2012</h2>
+ <h2 id="w3c-editor-s-draft-11-september-2012"><abbr title="World Wide Web Consortium">W3C</abbr> Editor's Draft 11 September 2012</h2>
<dl>
<dt>This version:</dt>
@@ -488,7 +488,7 @@
-</section><section id="toc"><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-and-services" class="tocxref"><span class="secno">2.2 </span>Life cycle of Intents and Services</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-parameters-dictionary" class="tocxref"><span class="secno">3.1 </span>Intent parameters dictionary</a><ul class="toc"><li class="tocline"><a href="#dictionary-intentparameters-members" class="tocxref"><span class="secno">3.1.1 </span>Dictionary <span class="formerLink"><code>IntentParameters</code></span> Members</a></li></ul></li><li class="tocline"><a href="#intent-object" class="tocxref"><span class="secno">3.2 </span>Intent object</a><ul class="toc"><li class="tocline"><a href="#attributes" class="tocxref"><span class="secno">3.2.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#invocation-api" class="tocxref"><span class="secno">3.3 </span>Invocation API</a><ul class="toc"><li class="tocline"><a href="#methods" class="tocxref"><span class="secno">3.3.1 </span>Methods</a></li></ul></li><li class="tocline"><a href="#delivery-and-response-api" class="tocxref"><span class="secno">3.4 </span>Delivery and Response API</a><ul class="toc"><li class="tocline"><a href="#attributes-1" class="tocxref"><span class="secno">3.4.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#registration-markup" class="tocxref"><span class="secno">3.5 </span>Registration Markup</a><ul class="toc"><li class="tocline"><a href="#attributes-2" class="tocxref"><span class="secno">3.5.1 </span>Attributes</a></li></ul></li></ul></li><li class="tocline"><a href="#user-agent-behavior" class="tocxref"><span class="secno">4. </span>User Agent Behavior</a><ul class="toc"><li class="tocline"><a href="#explicit-intents" class="tocxref"><span class="secno">4.1 </span>Explicit Intents</a></li><li class="tocline"><a href="#matching-action-and-type-for-delivery" class="tocxref"><span class="secno">4.2 </span>Matching action and type for delivery</a></li><li class="tocline"><a href="#handling-service-suggestions-from-intent-invocation" class="tocxref"><span class="secno">4.3 </span>Handling Service suggestions from Intent Invocation</a></li></ul></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="#privacy-considerations" class="tocxref"><span class="secno">6. </span>Privacy Considerations</a></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></section>
+</section><section id="toc"><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-and-services" class="tocxref"><span class="secno">2.2 </span>Life cycle of Intents and Services</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-parameters-dictionary" class="tocxref"><span class="secno">3.1 </span>Intent parameters dictionary</a><ul class="toc"><li class="tocline"><a href="#dictionary-intentparameters-members" class="tocxref"><span class="secno">3.1.1 </span>Dictionary <span class="formerLink"><code>IntentParameters</code></span> Members</a></li></ul></li><li class="tocline"><a href="#intent-object" class="tocxref"><span class="secno">3.2 </span>Intent object</a><ul class="toc"><li class="tocline"><a href="#attributes" class="tocxref"><span class="secno">3.2.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#invocation-api" class="tocxref"><span class="secno">3.3 </span>Invocation API</a><ul class="toc"><li class="tocline"><a href="#methods" class="tocxref"><span class="secno">3.3.1 </span>Methods</a></li></ul></li><li class="tocline"><a href="#delivery-and-response-api" class="tocxref"><span class="secno">3.4 </span>Delivery and Response API</a><ul class="toc"><li class="tocline"><a href="#attributes-1" class="tocxref"><span class="secno">3.4.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#registration-markup" class="tocxref"><span class="secno">3.5 </span>Registration Markup</a><ul class="toc"><li class="tocline"><a href="#attributes-2" class="tocxref"><span class="secno">3.5.1 </span>Attributes</a></li></ul></li></ul></li><li class="tocline"><a href="#user-agent-behavior" class="tocxref"><span class="secno">4. </span>User Agent Behavior</a><ul class="toc"><li class="tocline"><a href="#service-registration" class="tocxref"><span class="secno">4.1 </span>Service Registration</a></li><li class="tocline"><a href="#invocation-and-dispatch" class="tocxref"><span class="secno">4.2 </span>Invocation and Dispatch</a></li><li class="tocline"><a href="#explicit-intents" class="tocxref"><span class="secno">4.3 </span>Explicit Intents</a></li><li class="tocline"><a href="#matching-action-and-type-for-delivery" class="tocxref"><span class="secno">4.4 </span>Matching action and type for delivery</a></li><li class="tocline"><a href="#handling-service-suggestions-from-intent-invocation" class="tocxref"><span class="secno">4.5 </span>Handling Service suggestions from Intent Invocation</a></li></ul></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="#privacy-considerations" class="tocxref"><span class="secno">6. </span>Privacy Considerations</a></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></section>
<section id="introduction">
<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
@@ -691,18 +691,18 @@
<b>type</b> fields are required; all others are optional.
</p>
<pre class="idl"><span class="idlDictionary" id="idl-def-IntentParameters">dictionary <span class="idlDictionaryID">IntentParameters</span> {
-<span class="idlMember"> <span class="idlMemberType"><a>DOMString</a></span> <span class="idlMemberName"><a href="#widl-IntentParameters-action">action</a></span>;</span>
-<span class="idlMember"> <span class="idlMemberType"><a>DOMString</a></span> <span class="idlMemberName"><a href="#widl-IntentParameters-type">type</a></span>;</span>
-<span class="idlMember"> <span class="idlMemberType"><a>any</a></span> <span class="idlMemberName"><a href="#widl-IntentParameters-data">data</a></span>;</span>
-<span class="idlMember"> <span class="idlMemberType">sequence<<a>Transferable</a>></span> <span class="idlMemberName"><a href="#widl-IntentParameters-transfer">transfer</a></span>;</span>
-<span class="idlMember"> <span class="idlMemberType"><a>URL</a></span> <span class="idlMemberName"><a href="#widl-IntentParameters-service">service</a></span>;</span>
-<span class="idlMember"> <span class="idlMemberType">sequence<<a>URL</a>></span> <span class="idlMemberName"><a href="#widl-IntentParameters-suggestions">suggestions</a></span>;</span>
+<span class="idlMember"> <span class="idlMemberType"><a>DOMString</a></span> <span class="idlMemberName"><a href="#widl-IntentParameters-action">action</a></span>;</span>
+<span class="idlMember"> <span class="idlMemberType"><a>DOMString</a></span> <span class="idlMemberName"><a href="#widl-IntentParameters-type">type</a></span>;</span>
+<span class="idlMember"> <span class="idlMemberType"><a>any</a>?</span> <span class="idlMemberName"><a href="#widl-IntentParameters-data">data</a></span>;</span>
+<span class="idlMember"> <span class="idlMemberType">sequence<<a>Transferable</a>>?</span> <span class="idlMemberName"><a href="#widl-IntentParameters-transfer">transfer</a></span>;</span>
+<span class="idlMember"> <span class="idlMemberType"><a>URL</a>?</span> <span class="idlMemberName"><a href="#widl-IntentParameters-service">service</a></span>;</span>
+<span class="idlMember"> <span class="idlMemberType">sequence<<a>URL</a>>?</span> <span class="idlMemberName"><a href="#widl-IntentParameters-suggestions">suggestions</a></span>;</span>
};</span></pre><section id="dictionary-intentparameters-members"><h4><span class="secno">3.1.1 </span>Dictionary <a class="idlType" href="#idl-def-IntentParameters"><code>IntentParameters</code></a> Members</h4><dl class="dictionary-members"><dt id="widl-IntentParameters-action"><code>action</code> of type <span class="idlMemberType"><a>DOMString</a></span></dt><dd>An opaque string indicating the action type of the intent. The
- string <em class="rfc2119" title="must not">must not</em> be empty.</dd><dt id="widl-IntentParameters-data"><code>data</code> of type <span class="idlMemberType"><a>any</a></span></dt><dd>The data payload used <em class="rfc2119" title="must">must</em> be an object upon which the structured
- clone algorithm can be performed, including Transferables.</dd><dt id="widl-IntentParameters-service"><code>service</code> of type <span class="idlMemberType"><a>URL</a></span></dt><dd>When present, this field marks the intent as an explicit intent. The
- value <em class="rfc2119" title="must">must</em> be an absolute URL.</dd><dt id="widl-IntentParameters-suggestions"><code>suggestions</code> of type <span class="idlMemberType">sequence<<a>URL</a>></span></dt><dd>When present, this field provides a list of suggested Service URLs,
+ string <em class="rfc2119" title="must not">must not</em> be empty.</dd><dt id="widl-IntentParameters-data"><code>data</code> of type <span class="idlMemberType"><a>any</a></span>, nullable</dt><dd>The data payload used <em class="rfc2119" title="must">must</em> be an object upon which the structured
+ clone algorithm can be performed, including Transferables.</dd><dt id="widl-IntentParameters-service"><code>service</code> of type <span class="idlMemberType"><a>URL</a></span>, nullable</dt><dd>When present, this field marks the intent as an explicit intent. The
+ value <em class="rfc2119" title="must">must</em> be an absolute URL.</dd><dt id="widl-IntentParameters-suggestions"><code>suggestions</code> of type <span class="idlMemberType">sequence<<a>URL</a>></span>, nullable</dt><dd>When present, this field provides a list of suggested Service URLs,
each of which is an absolute URL that the Client is aware of and which
- can handle the intent.</dd><dt id="widl-IntentParameters-transfer"><code>transfer</code> of type <span class="idlMemberType">sequence<<a>Transferable</a>></span></dt><dd>The list of Transferables, for use in the structured clone
+ can handle the intent.</dd><dt id="widl-IntentParameters-transfer"><code>transfer</code> of type <span class="idlMemberType">sequence<<a>Transferable</a>></span>, nullable</dt><dd>The list of Transferables, for use in the structured clone
algorithm.</dd><dt id="widl-IntentParameters-type"><code>type</code> of type <span class="idlMemberType"><a>DOMString</a></span></dt><dd>A string indicating the type of the data payload. The data payload
<em class="rfc2119" title="must">must</em> be described by this parameter, which <em class="rfc2119" title="must not">must not</em> be empty.</dd></dl></section>
</section>
@@ -822,14 +822,14 @@
</p>
<p>
The <code>window.intent</code> object <em class="rfc2119" title="must">must</em> be made available across
- same-origin redirects of the service page. It <em class="rfc2119" title="must not">must not</em> be available if
+ same-origin redirects of the service page. It <em class="rfc2119" title="must not">must not</em> be made available if
redirects cross an origin boundary.
</p>
<p>
So the following redirect sequence
will work: http://example.com/service to http://example.com/login back to
http://example.com/service. In this case, the <code>window.intent</code>
- data would be available to all three page loads.
+ data would be made available to all three page loads.
</p>
<p>
This will also work: http://example.com/service to
@@ -851,13 +851,17 @@
</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
+ delivered, the intent data <em class="rfc2119" title="must">must</em> be made available to pages in a redirect or
navigation sequence when they are in the same origin as that to which it was originally
- delivered (and have the enabling markup), but <em class="rfc2119" title="must not">must not</em> be available to any other pages.
+ delivered (and have the enabling markup), but <em class="rfc2119" title="must not">must not</em> be made 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>
+ <p>
+ Multiple invocation by code in the service page <em class="rfc2119" title="must">must</em> throw a Javascript
+ exception. The User Agent <em class="rfc2119" title="must not">must not</em> allow a particular Intent to be replied to multiple times.
+ </p>
</section>
<section id="registration-markup">
@@ -932,22 +936,22 @@
<p>
The intent tags on the service handler page itself <em class="rfc2119" title="should">should</em> be interpreted by
the User Agent as authoritative. That is, if the User Agent loads a service
- page, and sees that not all intent descriptors it believes will be handled
- by the page are actually handled, it would replace the currently-registered
- set with the new set declared by the page.
+ page, and sees that its intent descriptors do not match the set currently
+ registered for that page, it would replace the currently-registered
+ set with the set discovered on the more current load of the page.
</p>
- <h4 id="http-error-codes-on-service-pages">HTTP Error Codes on Service Pages</h4>
+ <h4 id="http-status-codes-on-service-pages">HTTP Status Codes on Service Pages</h4>
<p>
If a registered service page is retrieved and has a non-20x error code
[<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], the User Agent <em class="rfc2119" title="should">should</em> take the following actions:</p>
<p>
30x: redirect to the indicated page. If the page is on-domain, and has
- intent markup, the intent will be re-delivered. If the redirect is permanent
- (301), the User Agent <em class="rfc2119" title="may">may</em> update its service registration records to reflect
- that.
+ intent markup, the intent will be made available to the redirect page.
+ If the redirect is permanent (301), the User Agent <em class="rfc2119" title="may">may</em> update its service
+ registration records to reflect that.
</p>
<p>
- 40x: indicate to the user that the page cannot be loaded, along with any
+ 4xx: indicate to the user that the page cannot be loaded, along with any
remediation capabilities (i.e. authentication for 403 or payments for 402).
In the case of error 410, the User Agent <em class="rfc2119" title="should">should</em> unregister the handler from
its internal registry.
@@ -955,13 +959,18 @@
<p>
50x: indicate to the user that the page cannot be loaded.
</p>
- <p></p>
+ <p>
+ If the desired registered service page cannot be loaded, the User Agent <em class="rfc2119" title="should">should</em>
+ display UI allowing the user to select another service.
+ </p>
</section>
</section>
<section id="user-agent-behavior">
<!--OddPage--><h2><span class="secno">4. </span>User Agent Behavior</h2>
+ <section id="service-registration">
+ <h3><span class="secno">4.1 </span>Service Registration</h3>
<p>
When the User Agent loads a page with registration markup, it <em class="rfc2119" title="should">should</em> allow
the user to configure that page as a web intents service. The details of
@@ -984,6 +993,18 @@
or pre-bundled. (TODO: add example of a local network service)
</p>
<p>
+ The User Agent <em class="rfc2119" title="may">may</em> act as a Client or a Service. For example, the User
+ Agent may implement particular affordances which directly launch Intents
+ that may be handled by registered Services, or present UI allowing its own
+ functionality to be used alongside other registered Services to handle
+ Intents. For instance, 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.
+ </p>
+ </section>
+ <section id="invocation-and-dispatch">
+ <h3><span class="secno">4.2 </span>Invocation and Dispatch</h3>
+ <p>
For intents invoked by client web applications, the User Agent <em class="rfc2119" title="must">must</em>
require that such invocations be in the context of a user gesture. User
Agents <em class="rfc2119" title="may">may</em> also dispatch intents invoked through other mechanisms. For
@@ -997,16 +1018,15 @@
helper applications, proxy them through connections to other hardware,
etc. In general, though, the User Agent <em class="rfc2119" title="must">must</em> provide a way for the user
to configure which intents are delivered to which services. This process
- <em class="rfc2119" title="should">should</em> be configurable on a per-invocation basis for most intents,
- although defaulting rules, as long as they are configurable by the user,
- are expected to mean that the User Agent need not present specific UI
- controls on every invocation.
+ <em class="rfc2119" title="should">should</em> be configurable on a per-invocation basis. Defaulting rules,
+ as long as they are configurable by the user, are expected to result in
+ the User Agent not presenting full UI controls on every invocation.
</p>
<p>
When the User Agent delivers an intent payload to a web application, it
<em class="rfc2119" title="must">must</em> make the <code>window.intent</code> object available as the document
is loaded and parsed, so that scripts on the page may process the intent
- data as they load. User agents <em class="rfc2119" title="must not">must not</em> place a <code>window.intent</code>
+ data as they load. User agents <em class="rfc2119" title="must not">must not</em> make available a <code>window.intent</code>
object in the scope of pages which do not have registration metadata
declaring themselves as intent handlers. This means that any use of
<code>window.intent</code> in pages which do not explicitly declare
@@ -1016,8 +1036,8 @@
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.
+ made available, 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>
@@ -1042,13 +1062,10 @@
"share" type, or that the Client is asking them to pick an image.
</p>
<p>
- The User Agent <em class="rfc2119" title="may">may</em> act as a Client or a Service. For example, the User
- Agent may implement particular affordances which directly launch Intents
- that may be handled by registered Services, or present UI allowing its own
- functionality to be used alongside other registered Services to handle
- Intents. For instance, 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.
+ If the user has no services registered for a particular type of intent,
+ the User Agent <em class="rfc2119" title="may">may</em> display options from other sources of data about
+ services it knows can handle that intent type so that the user can
+ complete the activity.
</p>
<p>
The User Agent <em class="rfc2119" title="must not">must not</em> categorically prohibit
@@ -1057,14 +1074,9 @@
unwanted intent invocations, intents as used as an attack vector, and
other mis-use.
</p>
- <p>
- If the user has no services registered for a particular type of intent,
- the User Agent <em class="rfc2119" title="may">may</em> display options from other sources of data about
- services it knows can handle that intent type so that the user can
- complete the activity.
- </p>
+ </section>
<section id="explicit-intents">
- <h3><span class="secno">4.1 </span>Explicit Intents</h3>
+ <h3><span class="secno">4.3 </span>Explicit Intents</h3>
<p>
When handling an Intent marked as explicit (that is, constructed with the
object literal constructor with a non-empty <b>service</b> field), the
@@ -1090,7 +1102,7 @@
</section>
<section id="matching-action-and-type-for-delivery">
- <h3><span class="secno">4.2 </span>Matching action and type for delivery</h3>
+ <h3><span class="secno">4.4 </span>Matching action and type for delivery</h3>
<p>
When an Intent is delivered, the User Agent must verify that the Service to
which the intent is to be delivered (either from an explicit invocation or from
@@ -1142,7 +1154,7 @@
</section>
<section id="handling-service-suggestions-from-intent-invocation">
- <h3><span class="secno">4.3 </span>Handling Service suggestions from Intent Invocation</h3>
+ <h3><span class="secno">4.5 </span>Handling Service suggestions from Intent Invocation</h3>
<p>
If the user has no persistent information about a qualifying service
for a particular intent registered with the User Agent, the User Agent
@@ -1223,7 +1235,7 @@
It should be possible to translate a few existing features to use Web
Intents, thus putting web applications on the same footing as local
resources. For instance, it should be possible for the User Agent to
- translate file selection controls to intents such that the use can
+ translate file selection controls to intents such that the user can
choose to upload a file from a cloud storage locker as well as from
local disk. In these cases, the User Agent may supply built-in intent
handlers corresponding to existing functionality.
@@ -1254,13 +1266,13 @@
<section id="privacy-considerations">
<!--OddPage--><h2><span class="secno">6. </span>Privacy Considerations</h2>
<p>
- The user needs to have confidence that the Service will user the data
+ The user needs to have confidence that the Service will use the data
associated with the action for the purpose intended and not share or retain
the data inappropriately [<cite><a class="bibref" href="#bib-WEBAPP-PRIVACY-BESTPRACTICES">WEBAPP-PRIVACY-BESTPRACTICES</a></cite>]. For this reason
it is important that the user have control over Intents, in particular the
selection mechanism which determines which Service will handle a particular Intent.
This offers the possibility of user decision and control related to the choice of
- Service, allowing them to take into account expectations regarding the Service,
+ Service, allowing the user to take into account expectations regarding the Service,
including Service policies related to retention and secondary use. This relates
to the privacy principles of control and consent [<cite><a class="bibref" href="#bib-DAP-PRIVACY-REQS">DAP-PRIVACY-REQS</a></cite>]. For
this reason a user should be made aware of explicit intents and be able to view and