- From: Soares Chen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Jul 2017 02:45:15 +0000
- To: public-webrtc-logs@w3.org
I think the wordings can be more explicit instead of relying on the implicit behavior of promises. e.g. "If `connection.peerIdentity` is not yet resolved, resolve it with ...".
Still, it doesn't solve the first case where peer identity is set but first call to identity validation fails.
```javascript
// target peer identity is established during construction
const pc = new RTCPeerConnection({ peerIdentity: ... })
pc.setRemoteDescription(sdpWithInvalidAssertion) // first SRD fails
.catch(() => pc.setRemoteDescription(sdpWithValidAssertion)) // second SRD succeeds
.then(pc.peerIdentity)
.catch(err => ...); // pc.peerIdentity stays rejected forever
```
Relevant paragraphs:
> If identity validation fails, the peerIdentity promise is rejected with a newly created OperationError.
>
> If identity validation fails and there is no a target peer identity, the value of the peerIdentity MUST be set to a new, unresolved promise instance.
So if validation fails and there _is_ a target peer identity, the rejected `peerIdentity` promise is never replaced.
Probably a better way to cover all failure cases is:
- If identity validation fails and the `connection.peerIdentity` promise is not yet resolved, reject it with a newly created `OperationError` and set `connection.peerIdentity` to a new, unresolved promise instance.
--
GitHub Notification of comment by soareschen
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1513#issuecomment-318541423 using your GitHub account
Received on Friday, 28 July 2017 02:45:16 UTC