Talk:List of RFCs

Latest comment: 2 years ago by 2607:FEA8:FC00:82EE:8529:6AC5:A404:1793 in topic Suggestion #3

Perhaps remove strikethrough for something else

edit

The strike through on the obsolete RFCs make it hard to view what the text actually says. Perhaps if an editor could replace them with another method? eg. Adding a table column. Would be very thankful for it. --86.31.106.190 (talk) 06:11, 7 January 2015 (UTC)Reply

Suggestions

edit

Maybe we need to make a date sortible? Right now it sorts by month name and year, first all april's, last all september's. Looks uncool. SoNick RND (talk) 14:23, 27 January 2016 (UTC)Reply

To the editors of this page, please take a look into MIME, SMTP, ESMTP, Bounce messages, SMTP AUTH (ESMTPA), CRAM MD5, and RFC if you want to list about twenty more RfCs with corresponding articles. -- Omniplex 07:04, 30 March 2006 (UTC)Reply

Would you care to list the RFCs for each? :) Cburnett 02:12, 17 March 2007 (UTC)Reply
Two simple cases are SMTP AUTH RFC 4954 obsoleting RFC 2554, and CRAM-MD5 RFC 2195. The Delivery Status Notification set consists of four draft standards, RFC 3461 obsoletes RFC 1891, RFC 3462 obsoletes RFC 1892, RFC 3463 obsoletes RFC 1893, RFC 3464 obsoletes RFC 1894. I think you don't need the old 189x numbers, the way how Wikipedia links RFCs is much better than it used to be back in 2006. --217.184.142.41 (talk) 02:03, 3 June 2008 (UTC)Reply

Could consider adding RFC 1294 (obsolete), RFC 1490 (obsolete), and RFC 2427 with related article links to Frame Relay / ATM. fonetikli 02:34, 16 May 2006 (UTC)Reply

Done, please review my additions. Cburnett 02:12, 17 March 2007 (UTC)Reply


How about BGP ?? —Preceding unsigned comment added by 213.174.192.217 (talk) 10:45, 19 March 2009 (UTC)Reply

Deflate and such

edit

Can RFC 1950, RFC 1951 and RFC 1952 be in this list? --134.58.253.131 21:06, 14 February 2007 (UTC)Reply

Done, please review my additions. Cburnett 02:12, 17 March 2007 (UTC)Reply


Any special reason why it refers to the obsolute rfc 1889 instead of rfc 3550

Transclusion to other pages?

edit

Given that there are protocol specific pages referencing RFCs for that protocol (SMTP,LDAP,MIME, etc), does it make sense to re-format the topical list so that each protocol specific list of RFCs can be standardized and re-used? This may also make it easier to maintain the list of RFCs as editors interested in those specific protocols could then maintain the specific list. I've coded up an example of what I am talking abou at User:Crkey/Sandbox/List of RFCs and User:Crkey/Sandbox/RFCs for LDAP and User:Crkey/Sandbox/RFCs for IRC. Crkey (talk) 18:46, 16 May 2008 (UTC)Reply

That's a nice idea! I wonder if they could become more proper navboxes (collapsable, with "e" or "edit" link, etc.), so that editors could get to the actual content more easily from whatever page transcludes it? The history of invidivual specs is convoluted sometimes (look at the last section listing them on LDAP!), so having it collapsed-by-default but actually including all relevant ones would make it more reader-friendly when transcluded into that page. DMacks (talk) 19:15, 16 May 2008 (UTC)Reply
Navboxes might be a good idea. I like that you'd be able to collapse them, though for some of the topics, like BEEP, that only have a few RFCs it might be over kill. Then again that's the same argument against my original suggestion. For what it's worth, I've updated my example with a pieced together navbox for the LDAP example. It could probably do for some better styling, but I'll leave that up to others to decide. Crkey (talk) 23:54, 16 May 2008 (UTC)Reply
I was thinking that the table should be left as is, but made into a sortable table. This would mean the reader could decide whether to sort numerically (default, as it is now); or sort by protocol (currently "Related article"). Of course, this would mean that the use of "row-spanning" could not be used (as now). Also, I feel that there should be a column "updated by" for those RFCs that have updates that do not obsolete them. In this case, I would suggest re-using the notes column as such (in any event, there is only one entry for "notes" and that is really a redundant note anyway). Finally, I think both "obsoleted by" and "updated by" items should have Wiki links ... it would be nice if these could be intra-table links (if this is supported by Wiki tables) or, if not possible, links to the appropriate Wiki page. Enquire (talk) 13:57, 3 May 2009 (UTC)Reply
edit

Which is from the lede of this article. What does that mean? Articles RELATED to what? I don't see any organizations of the list, and listed subjects are out of date w/r/t "related" RFC numbers. Kbrose (talk) 01:03, 17 August 2008 (UTC)Reply

Two lists

edit

If the tables are sortable, why do we need two separate tables? Have they just not been merged? - dcljr (talk) 00:26, 7 April 2014 (UTC)Reply

RFC Search and RFC Authors service seems to be unmaintained, remove?

edit

The service behind the external links RFC Search and RFC Authors seems to be unmaintained, and also errors when searching for a known RFC number as recent as 2008. Perhaps these should be removed, as they are probably unhelpful in populating this list--Topperfalkon (talk) 00:07, 4 January 2018 (UTC)Reply

Suggestion #2

edit

2 Years after, I would suggest to re-read such comment:

Maybe we need to make a date sortible? Right now it sorts by month name and year, first all april's, last all september's. Looks uncool. SoNick RND (talk) 14:23, 27 January 2016 (UTC) — Preceding unsigned comment added by G.laurenzi (talkcontribs)

Suggestion #3

edit

Can we link each RFC to the text in rfc-editor.org (or a different equally high-quality source)? — Preceding unsigned comment added by 2607:FEA8:FC00:82EE:8529:6AC5:A404:1793 (talk) 14:03, 20 October 2022 (UTC)Reply