Identify the state of provisional stats

[youennf]

The current draft makes it difficult to understand whether these stats are actively being worked on or are there for historical reasons. It would be good to document this somehow.

From what I understood, most of these stats are in the current draft for historical reasons.
Should we create a section for all of these stats? Or remove them from the document?

We could group the stats that are implemented or prototyped in a specific section.
This could help both implementors and developers.

[youennf]

@henbos mentioned the following stats that are implemented in at least one UA: networkType and contentType.
Are there others?

@vr000m, thoughts?

[vr000m]

Most stats have not been implemented by the browsers.

My thought on deletion is this:
These stats are well defined if and when there is reasons to implement a particular stat, instead of defining a new stats at that moment, falling back to well defined and well understood stat is a better starting point for implementation as opposed to defining a new stat and showing that it will measure accurately what we want to measure.

[youennf]

@vr000m, I am not sure whether you are arguing for or against deletion.
I would personally favour deletion to limit potential confusion (we can always revive them from the git history).
I am ok leaving unimplemented stats in the document as long as we are clearly labelling them as such.

[vr000m]

I'm advocating for not deleting. And while git history is a good solution for editors, it's not a great way for implementers to look for potential solutions.

I agree that marking them as unimplemented makes a lot of sense and gives an opportunity for folks that are looking to solve a particular problem to anchor on a well defined metric (even if it's a starting point).

[henbos]

I would like the specs to be clear about what is implemented and what is a wish list/idea list for the future that may or may not happen.

I'm fine with not deleting the metrics, but I would like it to be clear what is or is not implemented.

Ideally if we move all the implemented metrics (networkType, contentType, maybe others) to the main stats spec, and let provisional spec be metrics that have either not been implemented or not exposed to JS, then there would be no confusion.

[henbos]

According to Chromium's WebIDL, the metrics that have been implemented from the provisional stats spec are:

• contentType
• rtcpTransportStatsId
• networkType

In addition, these have also been implemented but are not defined in any of the two specs:

• googTimingFrameInfo: from legacy getStats, see issue.
• isRemote: removed from spec a long time ago because type == 'local-candidate' or 'remote-candidate' reveals same info.
• ip: removed from spec a long time ago because it was renamed address.
• writable: not in any spec, probably a remnant of legacy getStats.
• priority: not in any spec, probably a remnant of legacy getStats.

Proposal:

• Move contentType, rtcpTransportStatsId and networkType to the main spec with an "At Risk" note.
• The remaining ones that have been implemented but have no spec should probably be deprecated and removed, though I don't see googTimingFrameInfo going away without a replacement. The other ones seems ready to Intent to Deprecate though IIUC.

If we do this, https://w3c.github.io/webrtc-stats/ will reflect implementations and this provisional stat specs can remain an idea document used for inspiration, but not something that the WG advocates implementing unless a WG meeting is hold about wanting to implement one of the metrics. WDYT @alvestrand @vr000m @youennf @jan-ivar ?

[henbos]

Speaking of networkType, it was originally moved due to privacy concerns (and Safari might even have unshipped them, not sure?) so that's definitely "At Risk". However now that we've added a HW exposure privacy gate used by powerEfficient, I think we could do the same think to networkType as a privacy mitigation, and perhaps that would be sufficient to remove the "At Risk". But that would be a follow-up discussion

[henbos]

contentType has no such issue but it is only defined if the UA supports the video-content-type RTP header extension, which is why it ended up here

[henbos]

And rtcpTransportStatsId... well I think it just ended up here because "who cares about RTP and RTCP not being multiplixed?"

[youennf]

I prefer the model of a main spec where stats would get consensus & implementation, and an extension spec where prototyped stats are described.
If we want to keep inspirational stats, let's clearly label them as such, in a dedicated section.

• Move contentType, rtcpTransportStatsId and networkType to the main spec with an "At Risk" note.

I doubt networkType will get consensus since we discussed it in the past and there is no new information to revive/drive this debate.
It might be interesting to discuss contentType and rtcpTransportStatsId.

[henbos]

I doubt networkType will get consensus since we discussed it in the past and there is no new information to revive/drive this debate.

My understanding was that it was moved because we didn't know what to do with privacy sensitive information and couldn't get consensus about keep or remove. Now we have a privacy gate. That's new information and it fundamentally challenges why it was moved in the first place, so I think it does make sense to at least talk about it.

[henbos]

To clarify, the privacy gate means you only expose networkType if the site is actively using your camera or microphone.