I'm reading "The MIME media type. Valid types are listed in [IANA-RTP-2]. The name must always be provided.". The link [IANA-RTP-2] points to is:
By opening such a link I do not see the "IANA-RTP-2" bullet at all but, depending on the browser, "[RFC4585]" or any other.
This happens in most of the internal anchor links and it makes very hard to jump within the spec.
It's not just that link. It's also the TOC. Seems that anchors don't always work very well in general. Sometimes they work. Sometimes they don't.
It seems that the generated web does not use "common" anchor links. For example, there is not a section with id="bib-IANA-RTP-2", so when we click on http://ortc.org/wp-content/uploads/2015/11/ortc.html#bib-IANA-RTP-2 some script intercepts it, gets the desired section from the URL fragment component, and scrolls down the web...
But that is obviously buggy and does not work in most of the cases. I expect something wrong in the respec-w3c-common script, but who knows.
Changed [TSVWG-RTCWEB-QOS] reference to normative from informative and now links seem to work:
Something is wrong with document anchor links
A small change that seems to fix a bunch of the reference links. Not sure why, exactly.
Related to Issue #353
That this minor an issue would break respec is beyond comprehension. So I'm hesitant to say that the problem is really fixed now. Please weigh in if you believe that things are fully working... if not, please let me know which links remain broken and I will investigate further.
Fix voiceActivityFlag typo and added change log
In line 3901, "v" was used instead of "voiceActivityFlag". Also added a change log reference to Issue #353
One outstanding broken link left: to WebRTC 1.0. Right now this is informative, would need to promote it to normative for the link to function correctly.
WebRTC 1.0 as normative reference
Portions of the ORTC API are derived from WebRTC 1.0, including the sections on Data Channel, DTMF and Identity. Therefore it is proposed that the WebRTC 1.0 API be made a normative reference. This change also addresses Issue #353
Once PR 371 is merged, I believe we can close this issue.