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

On Feb 27, 2013, at 0:09 , Nicholas Doty <npdoty@w3.org> wrote:

> 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?)

we don't.  I think we have verbal agreement to say that the calls may raise (Javascript) exceptions, but do we need to document what they are?

(The name clash is unfortunate;  "I got an exception when asking to store an exception!" Rather invites the reply -- "what's the problem?")


> 
> 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.
> 

I'm not sure I understand -- you want to replace the existing text with the above (which is shorter)?  The existing text reads:

> The user-agent may provide interfaces to the user:
> 	• To indicate that a call to store an exception has just been made;
> 	• To indicate that one or more exceptions exist for the current top-level origin;
> 	• To indicate that one or more exceptions exist for sites incorporated into the current page;
> 	• To allow the user to see and possibly revoke stored exceptions.
> 	• Other aspects of the exception mechanism, as desired.
> There is no required user-interface for the user-agent.
> 

It seems we should add a bullet "to [[interactively]] confirm a user-granted exception prior to storage"

> 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:
> 

probably 'should' store them, no (unless you have good reason, the expectation is that the exception will be stored).

>> 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

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 28 February 2013 19:25:00 UTC