standards-positions
standards-positions copied to clipboard
WebRTC: RTCIceCandidate relayProtocol and url properties
WebKittens
@youennf
Title of the spec
WebRTC
URL to the spec
https://github.com/w3c/webrtc-pc/pull/2773 https://github.com/w3c/webrtc-pc/pull/2763
URL to the spec's repository
https://github.com/w3c/webrtc-pc
Issue Tracker URL
No response
Explainer URL
No response
TAG Design Review URL
No response
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/976
WebKit Bugzilla URL
No response
Radar URL
No response
Description
It has been a while since the spec PRs landed. Not tackling the removal (or implementation of) the url field in https://w3c.github.io/webrtc-pc/#rtcpeerconnectioniceevent which seems to be implemented in Safari (see https://github.com/w3c/webrtc-pc/issues/2795)
Reading those issues I had these thoughts:
- If you do remove something from the specification you should feel somewhat obliged to add a negative test if you know of an implementation. See tests named "historical" for precedent.
-
url
members should probably use USVString, although it doesn't matter a whole lot for getters. - Ideally a
url
getter returns the URL serialization of an internal URL. The data model is a bit too opaque here for my taste.
If you do remove something from the specification you should feel somewhat obliged to add a negative test if you know of an implementation. See tests named "historical" for precedent.
Problem is that is not testable in WPT due to the lack of infrastructure (STUN/TURN servers) which is colocated.
url members should probably use USVString, although it doesn't matter a whole lot for getters.
This particular url is a url that is not touched much by the browser (which explains some of the awkwardness from https://github.com/w3c/webrtc-pc/issues/2660)
Ideally a url getter returns the URL serialization of an internal URL.
Actually this was how the implementation had to work but at a much, much deeper level ;-)