API changes

[holloway]

docList API

• These additional fields in each response item: https://github.com/ietf-tools/rfced-www/blob/main/client/utilities/rfc.mocks.ts#L107
• a request option to also return non-issued RFCs (ie RFC14, 26, 92, 201, 220, 244) which are filtered by default
• more complete data in the database for many early (sub 1k?) RFCs that's currently hardcoded https://github.com/ietf-tools/rfced-www/blob/main/client/utilities/rfc.mocks.ts#L119

docRetrieve API

• HTML string ... output by xml2rfc when we have it, and the output of rfc2html when we don’t - decorating it with metadata and things like the ToC extracted from whichever html form is available

• Additional 'errata' field so that I have the data to render this... ie errata array w/ verified errata state
  

• Additional 'contents' field for the sidebar of headings (a hierarchical list of headings in the RFC text).
  
  Those headings link to the RFC text headings so we might need a different structure for the RFC text itself in the response so that I can easily link to specific parts of it. I presume that I'm not supposed to parse the RFC text and derive this structure.

BCP API

• All BCPs (currently BCP1-239 ) with an 'is also' array referencing RFC ids.

FYI API

• All FYIs (currently FYI2-38) with an 'is also' array referencing RFC ids.

STD API

• All STDs (currently STD1-99) with a 'title' and 'is also' array referencing RFC ids.
  • In STD14, 15, 18 the <title> is sometimes rendered as (eg) [Was Simple Network Management Protocol. Now Historic.] so is that the actual title or do we need another field in the response to express whether it's historic. Same for STD12 the XML title is [Reserved for Network Time Protocol (NTP). See RFC 1305.] so is that the actual title or do I need fields to express whether it's reserved?

[rjsparks]

If you aren't going to be using the output of html2rfc for the html(ized) presentation, then we should be talking about where that computation lives, and how to avoid re computation of it for the views you're working on.

[holloway]

@rjsparks what approach would you recommend to create the data for sections/headings like the wireframes? I presume that the Datatracker API should handle the computation, returning more structure than a string.

(fyi @jennifer-richards)

[rjsparks]

That wireframe was informed by the current html produced by xml2rfc. The datatracker does not know about the insides of documents this way. The closest it gets to knowing is by using rfc2html, so providing information about the inside of a document like this will require a new kind of thing in the backend than what the datatracker has had to date.

[jennifer-richards]

The datatracker does not know about the insides of documents this way. The closest it gets to knowing is by using rfc2html, so providing information about the inside of a document like this will require a new kind of thing in the backend than what the datatracker has had to date.

As was mentioned on slack, datatracker's JS does have a module that extracts ToC for the sidebar of its htmlized document view. That's here https://github.com/ietf-tools/datatracker/blob/main/ietf/static/js/nav.js and provides the "Contents" sidebar tab for pages like https://datatracker.ietf.org/doc/html/draft-ietf-asap-sip-auto-peer-15.

A few options that come to mind are that we could 1) move that JS over to the rfced-www app and apply it to HTML slung at it by the datatracker API; 2) translate it (or something like it) to Python and generate a representation of the headings/targets as part of the API response alongside the HTML; or 3) same as 2 but precomputed.

(fyi, the ToC it generates currently look like this screenshot)