WebRTC: RTCIceCandidate relayProtocol and url properties

[fippo]

WebKittens

@youennf

Title of the spec

WebRTC

URL to the spec

w3c/webrtc-pc#2773
w3c/webrtc-pc#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

mozilla/standards-positions#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 w3c/webrtc-pc#2795)

[annevk]

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.

[fippo]

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 w3c/webrtc-pc#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 ;-)