Web Intent review

Dear DAP WG,

It is good to see the Web Intent task force making progress with the publication of its first Web Intent Working Draft.
Please find below some comments and open questions.

Regards,
                Youenn

1 Section 3
The pick media spec uses '?' to specify whether a particular WebIDL field is optional or not.
This is easy to read and could be reused in the web intent specification (e.g. the IntentParameters dictionary).

2 Section 3.1
The usage of  the "extras" and "data" seems to partially overlap one with the other.
Basically, both mechanisms allow transferring data from Client to Service.

The pick-media and pick-contact intents use the "extras" parameter but not the "data" parameter.
The examples in the Web Intent specification use the "data" member but not the "extras" parameter.

'extras' creates an asymmetry  between Web Intent request ('extras' available) and Web Intent response ('extras' not available).
In the case of 'symmetric' intents, like Pick and Save intents, the request structure of one intent could be defined as equal to the response structure of the other intent, thus removing the need for 'extras'.
Would some guidelines/rationale on why using one or the other be useful?
Would it make sense to simplify and have one single way of transferring data?

3 Section 3.3
3.1
Section 3.3.1 details when the onFailure callback is called.
This section is partially redundant with paragraph 7 of section 4.
I wonder whether a single place that details exhaustively when onFailure callback is called would be better.

3.2
Related to my previous mail on the pick media intent, it seems that nothing precludes the startActivity function to be called several times using the same Intent object.
If so, is a new context created for each startActivity call?
Is it possible for a particular user agent to load only on the first call the intent provider page and reuse the same page for the other calls?

What happens if startActivity is called several times in parallel on the same Intent object without letting the user complete previous intents?
Is it ok? Are the previous startActivity 'cancelled'? Is startActivity returning an error?

3.3
It is not very clear what happens to the service page when it returns a result or an error.
Can postResult/postFailure be called once (probably?) or several times for a given startActivity call?
If so, does it raise an error if called more than once in a given Service page?

This is probably user agent implementation specific but in the "window" disposition,
it would be nice for users if the user agent focus was set back to the calling web intent client tab when postResult/postFailure is called,
at least if the current focus is in the intent provider tab.

4. Section 3.5
4.1
Beginning of section 3.5 says that "A User Agent must not deliver an Intent to a web app service page which does not include markup describing what intents it can handle which matches the intent being delivered".
In section 3.4.1, the spec says that window.intent object must not be available for such pages (that have no mark-up) even though it was delivered for the initial page.
What is the rationale behind this restriction? security?
Would it be simpler to always make available window.intent to pages with the same context and same origin as the page for which the intent was delivered?

Going further down this path, is it absolutely needed to have that <intent> mark-up within the page to which the intent is delivered in the first place?
This approach adds some complexity (window.intent is available only after parsing <intent> markup) and should be compared with its benefit.
Is it to cope with obsolete-but-still-registered-providers?
Would programmatic unregistration be simpler?

In terms of wording, sections 3.4.1 and 4 use the term "Make available" a window.intent object.
Is there any difference with the wording "re-deliver" an intent as stated in the HTTP Error Codes section?

4.2
The "inline" disposition definition seems a bit vague.
Are "inline" intents displayed on top of the web page, or in some reserved user agent UI space?
Are there any additional constraint the spec should state on the "inline" behavior? pop-up, iframe-like with highest CSS z-index, banner...?

If an "inline" intent can be displayed on top of the client page, this may open the door to clickjacking.
For good UI integration, it may be nice to allow the client to suggest where/how should appear the Service page.
But this may be even worse for clickjacking...

4.3
In the "Same-origin registration" subsection, it may be good to define what means "when the href attribute points to a different resource".
Is it based on normalized URL?

4.4
The last sentence of the "Unregistering" subsection may be somewhat tightened.
If the new set is a subset of the currently-registered set, everything is fine.
If the new set partially overlaps the currently-registered set,
the user agent should probably not replace the currently-registered set with the new set,
but only remove the items that are in the currently registered set and not in the new set.

4.5
The "HTTP Error Codes" section title should probably be changed to "HTTP Status Codes on Service Pages".

When retrieving the service page and retrieving a 4xx or 50x, the Intent is dispatched but cannot be delivered.
May a user agent go back to the Selection phase directly, especially in the case of a 410 response?
It is not clear whether a 4xx/50x response makes the intent to not be dispatched (in which case onFailure will be called) or not.

In the 'window' disposition, a user could refresh the tab until it works or fails.
When user closes the tab, the onFailure callback would be called if the intent is not yet completed.
For 'hidden' and 'inline' disposition, this may not work as well.

5. Section 4
5.1
Section 4 preamble (before section 4.1) is really dense.
It explains both intent registration and intent invocation.
It may be easier for readers if split into subsections.

5.2
The <intent> element advertises an Intent capacity for two purposes apparently: enabling web-based intent discovery/registration and validating intent delivery.
Beginning of section 4 seems to apply to the first usage when stating:
"When the User Agent loads a page with registration markup, it SHOULD allow the user to configure that page as web intents service".
The SHOULD statement seems somehow too strong for "re-delivered web pages" that would have mark-up for the second usage typically.

5.3
"This process SHOULD be configurable on a per-invocation basis for most intents, although..."
The word 'most' weakens the 'SHOULD.
Would it make sense to detail what 'most' means (all except explicit?) or simply remove 'for most intents'.

5.4
In section 4.2, it says: 'if the intent action is different from the service action'.
Does it mean character-based comparison? How about whitespaces?
Same questions applies to service/action type if they are not mime types.

6. Section 4.1
While section 5 defines use cases and requirements, it is difficult to relate any such requirement with explicit intents.
In addition, a well-designed User Agent implementation may well cover most of explicit intents functionality through "normal" intent.
Is there a chance that a good blend of defaulting rules plus a single URL as "suggestions" field be sufficient for those use cases?
Should additional experimentation be carried on before including explicit intents in the spec?

7. Section 5
This section is useful for WG members.
On the other hand, I do not know how useful it is for implementers or users of the specification.
Should it be moved to a non-normative appendix or a separate document?

8. Typos
Section 3.5.1
                "40X" -> "4XX"
Section 5.5, first paragraph
             "the use" -> "the user"
Section 6 first sentence
             "will user" -> "will use"
Section 6 second sentence
             them -> "the user"