W3C home > Mailing lists > Public > public-tracking@w3.org > February 2013

action-363: Draft text for user agent flexibility on exceptions

From: Nicholas Doty <npdoty@w3.org>
Date: Wed, 27 Feb 2013 00:09:22 -0800
Message-Id: <7672B3FE-B01B-4B13-9417-0862E6F1C8A7@w3.org>
To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi all,

At our last face-to-face, I volunteered to write text on user agent flexibility regarding user-granted exceptions. Much of this flexibility was already present in the working draft option (drafted by Dave Singer and Adrian Bateman mostly, I believe); the additional text was intended to explain that in not providing a return value to the synchronous store*Exception() methods, the user agent and user could take advantage of them as they see fit.

From the current text, I think we would need the following changes/additions:

1. the method signatures need to be updated to be void rather than returning an integer with defined meanings (dsinger, do we have an action for this?)

2. the list of what a user agent MAY do in Section 6.3.1 User Interaction should be expanded/changed to:

> The user agent MAY provide an interface to the user to indicate the presence of stored user-granted exceptions or to interactively confirm a user-granted exception prior to storage.
> 
> There is no required user interface for the user agent; user agents MAY choose to provide no user interface regarding user-granted exceptions.

3. for 6.3.2 "Processing Model" and 6.3.3 "Exception use by browsers", both of these sections (I still believe they are redundant and should be merged) should indicate that a browser MAY store exception duplets when the store*Exception() methods are called. In 6.3.3, we should clarify in the second numbered item that:

> Responses to the JavaScript <code>confirm*</code> methods described below MUST be consistent with this user preference (see below).

4. the non-normative User interface guidelines section requires no changes.

5. section 6.9 "Exceptions without a DNT header" may be very useful under the store exception model (for users who haven't enabled a general DNT preference, you may still be able to store an exception from the site's consent flow); this functionality is also mentioned in 6.3.1, so perhaps we should add a reference there to this section.

I believe these are all the changes needed; I'm happy to walk through them with one of the editors after/when the change to the method signatures (to return void, I believe) happens.

Thanks,
Nick
Received on Wednesday, 27 February 2013 08:09:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:04 UTC