WebRTC: RTCIceCandidate relayProtocol and url properties

[fippo]

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)

[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 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 ;-)