RFC.fyi: Browse RFCs by keywords, id or collection | Hacker News Reader

RFC.fyi: Browse RFCs by keywords, id or collection

rfc.fyi

161 pointsamjd24 comments

Nice, but make sure to "replace" the URL when adding the user query (= don't "push"), otherwise the user has to press back many times before he can leave the website again

Came to say the same thing. Or only do a push when the user actually performs their query.

Is it the norm now to break history? Why?

I want my Back and Forward buttons working. Especially on this site, which has no other means to clear the query.

Neither push nor replace history actually work in Chrome, so the fault lies more with the browser than the developers.

This works by loading a bunch of JSON on page load, and then do search on the client side in that json blob. I think it's fine, but I have looked into something similar to do as a toy project for learning postgres FTS by fetching an API provided by ietf, storing the data and doing search on the stored data. However, I couldn't find a straightforward API provided by IETF, and I was super surprised. Similarly I would also have liked a similar straightforward API from W3C for documents.

I tried one of the example queries, "UDP".

Out of the 45 search results, the most relevant one (the UDP RFC itself) was all the way at the bottom, listed as "RFC0768" and tagged as "legacy". (I'm not sure what legacy actually means here?)

Anyway, I clicked the link, which took me to a 404 error page - https://www.rfc-editor.org/rfc/rfc0768.html (The correct URL is apparently without the leading 0)

This site does seem genuinely useful, but I think the UX could really use some polishing here, especially since I literally followed through with one of the example queries in the middle of the homepage.

"Legacy" here means that it (substantially) pre-dates the IETF deciding it needs the arrangement described in RFC 4844

Today a document like RFC 768 would most likely be the product of an IETF Working Group (possibly after being initially drafted outside and then adopted). In some cases an Area Director might authorise somebody to write a document without the Working Group process under their direct sponsorship instead. Together these form the IETF stream. This stream is the only means by which the IETF produces "standards track" documents, although it can also produce other documents from this stream.

Two other related groups, the IAB and IRTF, might create documents the RFC Editor cares about, they have their own streams. For example RFC 4844 is from the IAB stream.

Finally there are Individual Submissions. Sometimes these are documents nobody in any Working Group or Area cares about, occasionally they are documents a Working Group abandoned because it was unable to reach consensus and those who favoured the document finished it up as an Individual Submission. In some cases they're documenting a thing the authors would like to be public, just to get it down on paper.

The "Legacy" indication just means RFC 768 is too old to be classified by stream, the whole idea didn't exist back then.

So for most viewers of the site (who don't know and don't care about the IETF process), "legacy" is just misleading as it doesn't have the meaning they expect.

Serious UX work needed.

The leading '0' issue should be fixed; not sure why that happened, it was tested before.

WRT UX - yes, it certainly could be improved. Issues and PRs gladly accepted :)

Now sorted in order of # of citations within the RFC corpus; it's rough, but definitely more usable IMO. Thanks for the suggestion.

I think that's a big improvement, thanks!

This is very cool, but I was sad I can't search by author.

Also I like the "obsolete" tick box.

As the other commenter said, this trashes the back button/history by treating every keypress as a new URL. Make sure you use replace.

Thanks. The back/history feedback has been (hopefully) addressed.

I've been thinking about doing authors. The constraint is performance; the site loads the whole index, so adding author info would bloat the initial page load out (right now the index is about 2.2M, and GitHub Pages gzips it down to ~380k). The solution is probably to put author search, etc. on a separate page.

If this didn't completely ruin my browser history records it would be quite neat!

I searched for “SIP” as RFC3261 is my favorite, but there were hundreds of results in reverse numerical order, so RFC3261 which defines SIP was right at the bottom.

Maybe just reversing the result order would give more useful results?

Very cool! I made an API to assist in RFC searches that’s very similar to this a while ago:

https://github.com/imwally/rfcsearch

https://rfcsearch.herokuapp.com/?q=coffee

I always thought an RFC browser/searcher would make an excellent text editor plugin

It probably would be. Just having a copy of the archive on my hard drive that I can grep whenever I want is pretty handy.

Now if I can comment or discuss on an RFC, or create my own playlist, that would be super useful!

RFC 1149 is missing, weak.

Great design, I only had to click Back about 3000 times.

This isn't very nice feedback. The site obviously needs to be fixed but you don't help OP understand what they should do to fix it.

No at this moment - a search for "1149" yields only:

> RFC1149: Standard for the transmission of IP datagrams on avian carriers

While a search for "avian" yields:

> 3 RFCs

> RFC6214: Adaptation of RFC 1149 for IPv6

> RFC2549: IP over Avian Carriers with Quality of Service

> RFC1149: Standard for the transmission of IP datagrams on avian carriers

11 hours ago this was not the case. Sweet. No rfc db is complete without CPIP!

Reply on news.ycombinator.com