Re: Mechanics of interfacing WebRTC API and JSEP

To make life more compilcated .... the version of the draft on github is
not the official draft version; the HTML version on is
not the official draft version, but an unofficial reformatting; the
eventual target for JSEP is an RFC, which doesn't offer semantic anchors
at all (AFAIK).

I think the third option comes closest to doing what we want - we have
to generate the mapping table from the github version, and point into
the published draft version.

Methodologies aren't completely aligned.

On 11/02/2015 12:35 PM, Dominique Hazael-Massieux wrote:
> Hi,
> As part of discussing at
> the WebRTC F2F last week, we came to the conclusion that we needed a
> better mechanism to link from the WebRTC API to the JSEP draft, and I
> volunteered to work with EKR on finding the right mechanism for that.
> Having looked quickly in the tools used to build the JSEP draft, I can
> imagine the following options:
> * we link directly to the "latest" version of JSEP posted at
>  this one has semantic anchors
> (e.g. so it's easy
> to do and requires little or no machinery to work; but it's not the
> official URL
> * we extract "live" the matching of semantic anchors to section
> numbers from that same document, and use these to build full links to
> URLs; the extraction can be done live since the doc is
> CORS'd; fairly easy to do, but requires some understanding and
> commitment of the alignment between
> and ; also, it will
> make the WebRTC spec slower to load
> * we set up a (automated?) process whereby each time the JSEP draft is
> updated, we run a tool that extract the mapping between semantic
> anchors and section numbers; I'm not sure how we integrate with the
> updates to JSEP draft (is there an IETF webhook for that?)
> Any reaction or preference?
> Dom

Surveillance is pervasive. Go Dark.

Received on Wednesday, 4 November 2015 13:26:59 UTC