Normative text for exceptions based on adrianba's proposal (ACTION-313)

The following is a stab at normative text based on Adrian's proposal [1]
that he brought forward at the Amsterdam f2f. I don't want to go through
the hassle of exactly spelling out all the details (parameter names, types,
nullable, optional, etc) before we have agreement on the API so pardon the
pseudocode.

API to request site-specific exceptions:

interface NavigatorDoNotTrack {
integer storeSiteSpecificTrackingException(optional sequence<DOMString>
arrayOfDomainStrings,  optional optional siteName, optional optional
explanationString, optional optional detailURI);
}

Most of the parameters remain the same, except instead of having a
callback, the API is turned into a synchronous response where the only
failure mode is the result of a syntax error.

Return type: (we probably need to discuss this. Note 3.2.1 in WebIDL,
moving away from integer codes in the style of enumeration to strings. In
general though, this isn't really a change as a result of Adrian's proposal
but an orthogonal issue.

If the request does not include the arrayOfDomainStrings, then this request
is for a site-wide exception. Otherwise each string in arrayOfDomainStrings
specifies a target. When called, requestSiteSpecificTrackingException must
return immediately. The return value has one of three states. 0 (or a
string per 3.2.1 of WebIDL) represents a syntax error or other such error
that the exception technically can not be stored as the site requested it.
1/2 remain as is.

...

6.8 User interface guidelines

User agents MUST store exceptions upon request from a website via the APIs
documented earlier in this section. As the request is synchronous, user
agents MUST NOT block the request on any user confirmation or interaction.
User agents MAY present indications to the user that an exception has been
stored, and MAY subsequently revoke stored exceptions.

The following text is non-normative.

User agents are free to implement exception management user interfaces as
they see fit...

...

A user agent that chooses to highlight when tracking exceptions have been
stored might provide an interface like the following.

- an icon in the status bar indicating that an exception has been stored,
which, when clicked on, gives the user more information about the exception
and an option to revoke such an exception.

- an infobar stating "Example News (news.example.com) has indicated to
Browser that you have consented to granting it exceptions to your general
Do Not Track preference. If you believe this is incorrect, click Revoke."

- no UI at all

In this example, the domain listed...



"The user agent might then store that decision, and answer future requests
based on this stored preference. A user agent might provide the user with
an interface to explicitly remove (or add) user-granted exceptions." -> "A
user agent might provide the user with an interface to explicitly remove
(or add) user-granted exceptions."

Remove: Users might not configure their agents to have simple values for
DNT, but use different browsing modes or other contextual information to
decide on a DNT value. What algorithm a user agent employs to determine DNT
values (or the lack thereof) is out of the scope of this specification.

[1] http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0112.html