- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 27 May 2016 08:01:04 -0700
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CABcZeBN7Yj_OaxE_GrSD5WByoSsjwi6ee6e4-b7R9g+bzW=iug@mail.gmail.com>
Section 4.3.1. reads in part: 1. If the process to apply description fails for any reason, then user agent must queue a task runs the following steps: 1. If connection's [[isClosed <http://w3c.github.io/webrtc-pc/#dfn-isclosed>]] slot is true, then abort these steps. 2. If elements of the SDP were modified in an invalid way as specified in [JSEP <http://w3c.github.io/webrtc-pc/#bib-JSEP>] (section 6. <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-6>), then reject p with an InvalidModificationError and abort these steps. 3. If the description's type <http://w3c.github.io/webrtc-pc/#dom-rtcsessiondescription-type> is wrong for the current signaling state <http://w3c.github.io/webrtc-pc/#dfn-signaling-state> of connection, then reject p with aInvalidStateError and abort these steps. 4. If the content of description is invalid, then reject p with an InvalidAccessError and abort these steps. 5. For all other errors, for example if description cannot be applied at the media layer, reject p withOperationError. Consider what happens if I invalidly modify an SDP *and* the PC is in the wrong state. This algorithm clearly tells you that you should be returning InvalidModificationError, which doesn't seem sensible. In general, I don't think the spec should be requiring a specific order of error checking. -Ekr
Received on Friday, 27 May 2016 15:02:12 UTC