Add support for IETF specs

[dontcallmedom]

based on #279, we should start with
'https://datatracker.ietf.org/doc/html/rfc6265',
'https://datatracker.ietf.org/doc/html/rfc6454',
'https://datatracker.ietf.org/doc/html/rfc7230',
'https://datatracker.ietf.org/doc/html/rfc7231',
'https://datatracker.ietf.org/doc/html/rfc7232',
'https://datatracker.ietf.org/doc/html/rfc7233',
'https://datatracker.ietf.org/doc/html/rfc7234',
'https://datatracker.ietf.org/doc/html/rfc7235',
'https://datatracker.ietf.org/doc/html/rfc7239',
'https://datatracker.ietf.org/doc/html/rfc7469',
'https://datatracker.ietf.org/doc/html/rfc7538',
'https://datatracker.ietf.org/doc/html/rfc7540',
'https://datatracker.ietf.org/doc/html/rfc8470'

There is also https://datatracker.ietf.org/doc/html/draft-thomson-hybi-http-timeout but compared to the other ones, not only is it not an RFC, but it's not even being worked on, so not sure we should handle it the same way.

[Elchi3]

There is also https://datatracker.ietf.org/doc/html/draft-thomson-hybi-http-timeout but compared to the other ones, not only is it not an RFC, but it's not even being worked on, so not sure we should handle it the same way.

This is for https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive#specifications. Happy to change it to something else (or just remove it if there isn't a good spec to link to)

[dontcallmedom]

I looked a bit into it; it looks like it lost momentum since Keep-Alive is no longer relevant (and even forbidden) in HTTP2, but I'll try to confirm this

[jyasskin]

A couple notes for whoever implements this:

1. Some non-RFC Internet Drafts do get shipped, sometimes even before being adopted by a working group. https://datatracker.ietf.org/doc/draft-davidben-http-client-hint-reliability/ may be a good example, with 3 LGTMs in https://groups.google.com/a/chromium.org/g/blink-dev/c/6EoEnqxqhsk/m/rQeg6meJAQAJ.
2. Document names change, both when they get adopted by a WG, and when they get published as an RFC. https://datatracker.ietf.org/doc/draft-ietf-tls-rfc5246-bis/ shows the "replaced by" series, but I don't see how to pull that out of https://datatracker.ietf.org/api/.
3. I-Ds have an XML form that'll probably be easier to parse than their HTML form.

[dontcallmedom]

so looking into this, I've been trying to determine the impact of adding IETF RFCs to browser-specs, in particular how reffy would react to it.

As far as I could determine, reffy doesn't break, but:

• specref sets nightly URLs to httpwg.org URLs for a number of hardcoded RFCs; it would be good to determine if this appropriate or if specref input should be fixed upstream / ignored in browser-specs
• reffy only extracts little valuable information from the basic RFCs, and somewhat more useful but also partially bogus information on references when using the (easier to parse) httpwg.org documents

(re using XML source, not all RFCs are available in that format AFAICT)#306

@tidoust, thoughts?

[dontcallmedom]

looking a bit more into the httpwg.org url questions:

• there are maintained editors drafts for these RFCs, which would fit well in the nightly URL of browser specs, e.g. https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html
• these aren't the specs listed by specref, though - specref linked to this based on Use specs from HTTP WG's website tobie/specref#539 which doesn't give much details

I think we should document these nightly in browser-specs, with their sourcePath set to the XML version from which they're built; I suspect we will want reffy to extract data from the source XML in this case.

[tidoust]

For browser-specs, it would be good to use the same form of canonical URLs for all IETF specs. I'm not clear what URL to use in practice. It seems equally valid to use URLs that start with https://datatracker.ietf.org/doc/html/ or https://www.rfc-editor.org. The httpwg.org URLs are specific to IETF HTTP Working Group specs, so don't strike me as "canonical enough".

FWIW, I note that the "bibtex" links at the top of RFCs target www.rfc-editor.org URLs... but then they link to a textual representation of the RFCs. For instance, https://datatracker.ietf.org/doc/rfc7231/bibtex/ contains:

url = {https://rfc-editor.org/rfc/rfc7231.txt}

I agree that it would make sense to document the httpwg.org latest URLs under nightly in browser-specs.

I would push to update Specref to switch back to datatracker.ietf.org or www.rfc-editor.org URL everywhere, and have the httpwg.org URLs (the real ED, that is) documented in the edDraft property.

[dontcallmedom]

@tidoust and I discussed that what constitutes an edDraft of what spec might be more complex given that e.g. https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest is set to replace several RFCs, some only partially; but in any case, it sounds like the reffy extraction story is likely to more involved in general, so we're focusing on collecting data for the browser-spec context for the time being, and looking to whether to patch specref upstream or here to use the datatracker.ietf.org urls (which, while they won't provide much useful data in reffy, shouldn't break it either)

[jyasskin]

@mnot will know more about the right thing to do here. I have a couple guesses:

• The way that IETF I-Ds replace RFCs is more complicated than the way W3C EDs and WDs replace RECs. Because of that, I wouldn't try to automatically map an RFC to an edDraft for it.
• There's often a WD<->ED mapping for I-Ds, but the mapping isn't stored in the I-D itself. e.g. https://github.com/cbor-wg/cddl-control links to https://cbor-wg.github.io/cddl-control/draft-ietf-cbor-cddl-control.html as the ED and https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-control as the WD, but neither of those links to the other. In this case, I'd probably again give up on having an edDraft, and just link to the datatracker.ietf.org URL for both sides.

[mnot]

Yep. I'm hoping that metadata availability from datatracker will improve (I've put in a query to the powers that be), but EDs are really a separate matter (if you don't want to consider the latest I-D the ED).

I had a nascent effort towards an ietf.json in repos, but it never really took off. If you had need for such a thing we could try to make it work again.

[dontcallmedom]

I've created a separate issue in reffy to discuss data extraction which summarizes my understanding of our options there: w3c/reffy#644 - this issue will focus on the narrower needs of browser-spec metadata.

[dontcallmedom]

@Elchi3 the HTTP RFCs exist at different URLs and with different rendering; the one currently referenced in MDN (per the above) are à la https://datatracker.ietf.org/doc/html/rfc6265; the IETF HTTP Working Group maintains much more readable and accessible versions in URLs à la https://httpwg.org/specs/rfc6265.html

Can you comment whether from an MDN linking policy perspective:

• it's preferable to use the ietf.org URLs
• it's preferable to use the most-user friendly rendering (in this case the httpwg.org) URLs
• there is no preference

[Elchi3]

@sideshowbarker and I put some effort into having user-friendly spec links, so I'd say the httpwg.org links are preferable. (under the condition that they are as up-to-date and as authoritative as the ietf.org urls).

It would be good to hear what the HTTP community thinks, though. @mnot?

[dontcallmedom]

@mnot already opined on this in the related specref discussion; so it sounds like httpwg.org URLs would be the better option, thanks!

[jyasskin]

For RFCs in the last year or two, the rfc-editor.org versions, like https://www.rfc-editor.org/rfc/rfc8740.html, are just as readable as the httpwg.org ones. Ones before that are better on httpwg.org. So … I'll suggest that you stop adding new RFCs to the httpwg.org list, even if you decide to keep the older ones.

[tidoust]

For RFCs in the last year or two, the rfc-editor.org versions, like https://www.rfc-editor.org/rfc/rfc8740.html, are just as readable as the httpwg.org ones.

I note that this also suggests using rfc-editor URLs for IETF specs (at least for new ones) instead of datatracker ones as the latter ones don't have these improvements.