PeerConnection event queue & "closed" state

In section 4.3.1, the second numbered list indicates that all calls to 
the indicated methods enqueue an action without mentioning the current 
peer state (and the closed state in particular). Since this impacts 
application-visible behavior (in terms of which method calls trigger 
callbacks), we want to make sure this is handled consistently among 
implementations. I think we have three options:

 1. In closed state, continue to queue and process operations (although
    many, if not all, will fail).
 2. In closed state, close the queue to new operations, but continue to
    process any that were enqueued prior to reaching the closed state.
 3. When transitioning to the closed state, clear the operations queue
    and close it to new operations.


By omitting a discussion of state in section 4.3.1, the current spec 
implies behavior 1, which is probably not what we intend.

Our current implementation does behavior 2, which has the property -- or 
at least can be made to have the property -- that any method that 
typically enqueues an operation either fails immediately, or is 
guaranteed to trigger a callback at some point in the future.

There is a reasonable argument to be made for option 3 in that an 
application knows, after closing a PC, that no further operations can be 
processed, saving it from the need to track state for PCs that cannot 
form connections. And we could add the property of guaranteeing a 
callback by specifying that any pending operations have their error 
callback executed whenever the queue is closed.

My personal preference would be behavior 3 with the error callbacks -- 
does anyone see a reason to go with either of the other two behaviors?

-- 
Adam Roach
Principal Platform Engineer
abr@mozilla.com
+1 650 903 0800 x863