ในบริบทของการกำกับดูแลอินเทอร์เน็ต เอกสารขอความคิดเห็น ( Request for Comments หรือ RFC) คือเอกสารประเภทหนึ่งที่เผยแพร่โดยคณะทำงานด้านวิศวกรรมอินเทอร์เน็ต (Internet Engineering Task Forceหรือ IETF) และสมาคมอินเทอร์เน็ต (Internet Society หรือ ISOC) ซึ่งโดยทั่วไปจะอธิบายถึงวิธีการ พฤติกรรม การวิจัย หรือนวัตกรรมที่สามารถนำไปใช้กับการทำงานของอินเทอร์เน็ตและระบบที่เชื่อมต่อกับอินเทอร์เน็ตได้

เกือบทุก ๆวันเอพริลฟูลส์ (1 เมษายน) นับตั้งแต่ปี 1989 บรรณาธิการ RFCของอินเทอร์เน็ต ได้เผยแพร่เอกสาร Request for Comments (RFC) ที่มีเนื้อหาตลกขบขันอย่างน้อยหนึ่งฉบับโดยอ้างอิงจาก RFC เดือนมิถุนายน ปี 1973 527ชื่อว่า ARPAWOCKY เป็นการล้อเลียนบทกวีไร้สาระ " Jabberwocky " ของลูอิส แคร์รอลรายชื่อต่อไปนี้ยังรวมถึง RFC ที่มีเนื้อหาตลกขบขันซึ่งตีพิมพ์ในวันอื่นๆ ด้วย

• RFC  748 – " ตัวเลือก TELNET RANDOMLY-LOSE " ^{[ 1 ]}สถานะไม่ทราบ
  เป็นการล้อเลียนรูป แบบเอกสาร TCP/IPเป็นเวลานานที่เอกสารนี้ถูกทำเครื่องหมายพิเศษในดัชนี RFC ด้วย "หมายเหตุ วันที่ออกเอกสาร"

• RFC  1097 – " ตัวเลือก TELNET SUBLIMINAL-MESSAGE " ^{[ 2 ]}สถานะไม่ทราบ

• RFC  1149 – " มาตรฐานสำหรับการส่ง IP Datagrams บนผู้ขนส่งทางอากาศ " ^{[ 3 ]}ทดลอง
  ปรับปรุงโดย RFC 2549 ในปี 1999 ดูด้านล่าง อธิบายโปรโตคอลสำหรับการส่งแพ็กเก็ต IP โดยนกพิราบส่งสาร

  ในปี พ.ศ. 2544 RFC 1149 ได้รับการนำไปใช้จริง^{[ 4 ]} โดย สมาชิกของBergen Linux User Group

  โปรดดู RFC 6214 ด้วย ตามที่ระบุไว้ด้านล่าง ซึ่งอธิบายถึงการปรับใช้ RFC 1149 สำหรับIPv6

• RFC  1216 – " เศรษฐศาสตร์เครือข่ายกิกะบิตและการเปลี่ยนแปลงกระบวนทัศน์ " ^{[ 5 ]}ข้อมูล
  กล่าวถึงวิธีการสื่อสารความเร็วต่ำมากที่เรียกว่า ULsNet ซึ่งเร็วกว่าการสื่อสารระดับกิกะบิตมาก
• RFC  1217 – " บันทึกจาก Consortium for Slow Commotion Research (CSCR) " ^{[ 6 ]}ข้อมูล

• RFC  1313 – " รายการวันนี้สำหรับวิทยุสนทนาทางอินเทอร์เน็ต KRFC AM 1313 " ^{[ 7 ]}ข้อมูล

• RFC  1437 – " การขยายประเภทเนื้อหา MIME ไปยังสื่อใหม่ " ^{[ 8 ]}ข้อมูล
  ข้อเสนอให้เพิ่มสิ่งมีชีวิตที่มีความรู้สึกนึกคิด เช่น มนุษย์ เข้าไปในไฟล์แนบของ MIME
• RFC  1438 – " คำแถลงเรื่องความเบื่อหน่ายของคณะทำงานด้านวิศวกรรมอินเทอร์เน็ต (SOBs) " ^{[ 9 ]}ข้อมูล

• RFC  1605 – " การแปล SONET เป็น Sonnet " ^{[ 10 ]}ข้อมูล
  เชื่อกันว่าเป็นผลงานของวิลเลียม เชกสเปียร์
• RFC  1606 – " มุมมองทางประวัติศาสตร์เกี่ยวกับการใช้งาน IP เวอร์ชัน 9 " ^{[ 11 ]}ข้อมูล
• RFC  1607 – " มุมมองจากศตวรรษที่ 21 " ^{[ 12 ]}ข้อมูล
  รายชื่ออีเมลที่อ้างว่าพบจากการแลกเปลี่ยนอีเมลของบุคคลหนึ่งในปี 2023

• RFC  1776 – " ที่อยู่คือข้อความ " ^{[ 13 ]}ข้อมูล

• RFC  1924 – " การแสดงที่อยู่ IPv6 แบบกระชับ " ^{[ 14 ]}ข้อมูล
• RFC  1925 – " ความจริงสิบสองประการของการสร้างเครือข่าย " ^{[ 15 ]}ข้อมูล
• RFC  1926 – " การห่อหุ้มข้อมูล IP แบบทดลองบน ATM " ^{[ 16 ]}ข้อมูล
• RFC  1927 – " ประเภท MIME เพิ่มเติมที่แนะนำสำหรับการเชื่อมโยงเอกสาร " ^{[ 17 ]}ข้อมูล
  แนะนำให้ใช้ลวดเย็บกระดาษและคลิปหนีบกระดาษจริงในการยึดติดชิ้นงาน MIME

• RFC  2100 – " การตั้งชื่อโฮสต์ " ^{[ 18 ]}ข้อมูล
  บทกวีเกี่ยวกับการตั้งชื่อเจ้าภาพ

• RFC  2321 – " RITA -- ตัวแทนแก้ไขปัญหาเครือข่ายอินเทอร์เน็ตที่เชื่อถือได้ " ^{[ 19 ]}ข้อมูล
• RFC  2322 – " การจัดการหมายเลข IP โดย peg-dhcp " ^{[ 20 ]}ข้อมูล
  เอกสาร RFC นี้ไม่ได้มีไว้เพื่อความบันเทิงเพียงอย่างเดียว โปรโตคอลที่อธิบายไว้ได้รับการนำไปใช้จริงในงานแฮกเกอร์ในยุโรปเป็นประจำ
• RFC  2323 – " แนวทางการระบุตัวตนและความปลอดภัยของ IETF " ^{[ 21 ]}ข้อมูล
• RFC  2324 – " โปรโตคอลควบคุมหม้อกาแฟไฮเปอร์เท็กซ์ (HTCPCP/1.0) " ^{[ 22 ]}ข้อมูล อัปเดตโดย RFC 7168 ในปี 2014

• RFC  2325 – " คำจำกัดความของวัตถุที่จัดการสำหรับอุปกรณ์ฮาร์ดแวร์เครื่องดื่มร้อนแบบหยดโดยใช้ SMIv2 " ^{[ 23 ]}ข้อมูล

• RFC  2549 – " IP ผ่านผู้ให้บริการทางอากาศที่มีคุณภาพการบริการ " ^{[ 24 ]}ข้อมูล อัปเดต RFC 1149

• RFC  2550 – " Y10K และหลังจากนั้น " ^{[ 25 ]}ข้อมูล
• RFC  2551 – " กระบวนการมาตรฐานโรมัน -- ฉบับแก้ไข III (1 เมษายน MCMXCIV) " ^{[ 26 ]}แนวปฏิบัติปัจจุบันที่แย่ที่สุด ยกเลิก MCMXCIX

• RFC  2795 – " ชุดโปรโตคอลลิงอนันต์ (IMPS) " ^{[ 27 ]}ข้อมูล
  เกี่ยวกับการนำทฤษฎีลิงอนันต์ไป ใช้ในทางปฏิบัติ

• RFC  3091 – " โปรโตคอลการสร้างตัวเลข Pi " ^{[ 28 ]}ข้อมูล
• RFC  3092 – " รากศัพท์ของ "Foo", " ^{[ 29 ]}ข้อมูล
• RFC  3093 – " โปรโตคอลเพิ่มประสิทธิภาพไฟร์วอลล์ (FEP) " ^{[ 30 ]}ข้อมูล

• RFC  3251 – " ไฟฟ้าผ่าน IP " ^{[ 31 ]}ข้อมูล
  ล้อเลียน "ทุกอย่างผ่าน IP และ IP ผ่านทุกอย่าง" ^{[ 32 ]}และวิกฤตไฟฟ้าแคลิฟอร์เนียปี 2000–2001
• RFC  3252 – " การขนส่งแบบ Ad-hoc ของอ็อกเท็ตเชิงคำศัพท์ไบนารี " ^{[ 33 ]}ข้อมูล

• RFC  3514 – " แฟล็กความปลอดภัยในส่วนหัว IPv4 " ^{[ 34 ]}ข้อมูล
  ข้อเสนอสำหรับ " บิตชั่วร้าย" (evil bit ) ในฐานะตัวเลือกในส่วนหัวของแพ็กเก็ต IPv4ต่อมา คำนี้กลายเป็นคำพ้องความหมายสำหรับความพยายามทั้งหมดในการแสวงหาทางออกทางเทคนิคที่เรียบง่ายสำหรับปัญหาทางสังคมที่ซับซ้อนของมนุษย์ ซึ่งต้องอาศัยการมีส่วนร่วมโดยสมัครใจของผู้กระทำความผิด

• RFC  3751 – " ข้อกำหนดโปรโตคอล Omniscience " ^{[ 35 ]}ข้อมูล

• RFC  4041 – " ข้อกำหนดสำหรับส่วนศีลธรรมในร่างพื้นที่การกำหนดเส้นทาง " ^{[ 36 ]}ข้อมูล
• RFC  4042 – " รูปแบบการแปลง Unicode ที่มีประสิทธิภาพ UTF-9 และ UTF-18 " ^{[ 37 ]}ข้อมูล
  เข้ารหัส Unicode ในรูปแบบโนเน็ต โดยเข้ารหัสอ็อกเท็ตหนึ่งตัว แล้วตามด้วยบิตต่อเนื่องที่บอกผู้ส่งว่ามีไบต์เพิ่มเติมที่จะต้องประมวลผลหรือไม่โดดเด่นตรงที่มันมี โค้ดภาษาแอสเซมบลีของ PDP-10อยู่เกือบ 22 ปีหลังจากที่ผู้ผลิตหยุดการผลิต PDP-10 ไปแล้ว และเป็นไปได้ในทางเทคนิค ซึ่งแตกต่างจากข้อเสนออื่นๆ อีกมากมาย
• ร่าง RFC: "IP เหนือผู้ให้บริการเบอร์ริโต้" ^{[ 38 ]}
  สูตรอาหารโปรโตคอลอินเทอร์เน็ต สำหรับสื่อสารขณะรับประทานอาหาร

ไม่มีการเผยแพร่ RFC ฉบับวันที่ 1 เมษายนในปีนี้ แต่ประกาศในรายชื่อ IETFเกี่ยวกับการแต่งตั้งตัวละครเบิร์ต จากรายการ Sesame Streetเป็นสมาชิกของ IAB ดูเหมือนจะเป็นเรื่องตลกในวันเอพริลฟูลส์ปี 2006

• RFC  4824 – " การส่ง IP Datagrams ผ่านระบบส่งสัญญาณธงเซมาฟอร์ (SFSS) " ^{[ 39 ]}ข้อมูล

• RFC  5241 – " สิทธิ์ในการตั้งชื่อในโปรโตคอล IETF " ^{[ 40 ]}ข้อมูล
• RFC  5242 – " รหัสอักขระรวมทั่วไป: ส่วนยุโรปตะวันตกและ CJK " ^{[ 41 ]}ข้อมูล

• RFC  5513 – " ข้อควรพิจารณาของ IANA สำหรับคำย่อสามตัวอักษร " ^{[ 42 ]}ข้อมูล
• RFC  5514 – " IPv6 ผ่านเครือข่ายสังคม " ^{[ 43 ]}ทดลอง
  ผู้เขียน นำไปใช้งานบนFacebookในระหว่างกระบวนการเขียน RFC ^{[ 44 ]}

• RFC  5841 – " ตัวเลือก TCP เพื่อระบุอารมณ์ของแพ็กเก็ต " ^{[ 45 ]}ข้อมูล

• RFC  6214 – " การปรับใช้ RFC 1149 สำหรับ IPv6 " ^{[ 46 ]}ข้อมูล
  ส่วนขยายที่รอคอยมานานสำหรับ โปรโตคอล เลเยอร์ดาต้าลิงก์เพื่อช่วยบรรเทาปัญหาการขาดแคลนพื้นที่แอดเดรส IPv4 ที่กำลังจะเกิดขึ้น เนื่องจากIPv6 มี ค่า MTUขั้นต่ำของลิงก์ที่ใหญ่กว่ามากจึงจำเป็นต้องใช้ Pidgeon ที่มีขนาดใหญ่และมีอายุมากกว่าเพื่อหลีกเลี่ยงการสูญหายของแพ็กเก็ตโดยไม่จำเป็น แนะนำให้มีอายุขั้นต่ำ 1 ปี ควรเลือกใช้ทั้งนกอายุน้อยและนกอายุมากเมื่อขนส่ง แพ็กเก็ต IPv4 ขนาดเล็ก ใน ระบบ Dual-stackเพื่อความปลอดภัย และเมื่อมองย้อนกลับไปในอนาคต ควรมีการเตรียมการเพื่อรับมือกับการติดเชื้อไวรัสH5N1เนื่องจากไวรัสนี้เป็นอุปสรรคต่อการใช้งานอินเทอร์เน็ตในปัจจุบัน

• RFC  6217 – " การออกอากาศระดับภูมิภาคโดยใช้เลเยอร์ลิงก์บรรยากาศ " ^{[ 47 ]}ทดลอง

• RFC  6592 – " แพ็กเก็ตว่าง " ^{[ 48 ]}ข้อมูล
  แม้ว่าจะมีการกล่าวถึงในโปรโตคอลเครือข่ายหลายตัว (เช่นMPEG-2 , RTPหรือRTCP ) แต่แพ็กเก็ตว่างเปล่า (Null Packet) ก็ไม่เคยมีการกำหนดนิยามอย่างเป็นทางการมาก่อน RFC นี้จึงแก้ไขข้อบกพร่องดังกล่าวโดยการให้นิยามที่ว่างเปล่า แพ็กเก็ตว่างเปล่าเป็นแพ็กเก็ตที่มีมิติเป็นศูนย์ ความยาวเป็นศูนย์ และเป็นแพ็กเก็ตที่ไม่เป็นอันตราย (กล่าวคือ ขาดบิตที่เป็นอันตราย ) ซึ่งอาจตรวจจับได้ยาก ที่น่าสนใจคือ อัตราการส่งแพ็กเก็ตว่างเปล่าไม่ได้เพิ่มอัตราบิตของปริมาณการรับส่งข้อมูลแพ็กเก็ตว่างเปล่าแต่อย่างใด
• RFC  6593 – " การค้นหาบริการแบบซ่อนหาโดยใช้ Hide-and-Go-Seek สำหรับระบบนามแฝงโดเมน (DPS) " ^{[ 49 ]}ข้อมูล
  บริการส่วนใหญ่มักต้องการแสดงตัวตนอย่างชัดเจนในเครือข่าย เพื่อให้ผู้ใช้สามารถค้นหาได้ง่าย (โดยใช้ เทคนิค การค้นหาบริการ ต่างๆ ) แต่ "บริการที่ไม่สนใจ เล่นสนุก รู้สึกท่วมท้น หรือขี้อาย อาจเลือกที่จะซ่อนตัวหรือบอกใบ้แทนที่จะแสดงตัวตนโดยตรง" ด้วยเหตุนี้ RFC นี้จึงนำเสนอ รูปแบบ การเล่นซ่อนหาโดยที่บริการ (ผู้ "ซ่อนตัว") มีตัวเลือกหลายวิธีในการซ่อนตัวจากไคลเอนต์ (ในสถานการณ์นี้เรียกว่า "มัน") แพ็กเก็ต DPS จะถูกส่งผ่านTCPโดย ตั้ง ค่า Moodเป็น 'Sneaky' (ดูRFC  5841ด้านบน) และ ตั้งค่า บิต Evil (ดูRFC  3514ด้านบน) ซึ่งในที่นี้มีความหมายกำกวมว่า "ฉันไม่แน่ใจ" เพื่อเพิ่มประสิทธิภาพของโปรโตคอลให้ดียิ่งขึ้น

• RFC  6919 – " คำสำคัญเพิ่มเติมสำหรับการใช้งานใน RFC เพื่อระบุระดับข้อกำหนด " ^{[ 50 ]}ทดลอง
  ช่วยเพิ่มศักยภาพของผู้เขียน RFC ในการถ่ายทอดเจตนาและจุดประสงค์ในรูปแบบที่ไม่เป็นทางการมากขึ้น โดยใช้คำสำคัญเชิงสั่งการ เช่น "ต้อง (แต่เรารู้ว่าคุณจะไม่ทำ)" (เมื่อคุณรู้ล่วงหน้าว่าคุณจะถูกเพิกเฉย แต่ก็ยังต้องการแสดงความเหนือกว่าทางศีลธรรมอยู่ดี) และ "ไม่ควรทำอย่างยิ่ง" (เมื่อเป็นเรื่องที่คาดหวังได้ว่า 'ผู้ชายก็เป็นอย่างนั้นแหละ')
• RFC  6921 – " ข้อควรพิจารณาในการออกแบบสำหรับการสื่อสารที่เร็วกว่าแสง (FTL) " ^{[ 51 ]}ข้อมูล
  เมื่อการส่งแพ็กเก็ตผ่านอินเทอร์เน็ตเร็วกว่าแสงเป็นไปได้แพ็กเก็ตเหล่านั้นอาจถูกรับก่อนที่จะถูกส่ง (เนื่องจากการย้อนกลับของเวลา ) ซึ่งจะส่งผลกระทบอย่างมากต่อโปรโตคอลหลายอย่างที่ใช้อยู่ในปัจจุบัน ด้วยความเร็วที่เพียงพอ (และการเลื่อนเวลาติดลบที่สอดคล้องกัน) การสื่อสารทั้งหมดอาจเกิดขึ้นก่อนที่จะเริ่มต้นเสียด้วยซ้ำ RFC ทบทวนหลักการออกแบบของโปรโตคอลเหล่านั้นเพื่อป้องกันการล้มเหลวของการสื่อสารในอนาคต เป็นไปได้มากว่าเราควรเริ่มอัปเกรดพวกมันตั้งแต่เมื่อวานแล้ว

• RFC  7168 – " โปรโตคอลควบคุมหม้อกาแฟไฮเปอร์เท็กซ์สำหรับอุปกรณ์ปล่อยน้ำชา (HTCPCP-TEA) " ^{[ 52 ]}ข้อมูล
  ปรับปรุงRFC 2324สำหรับเครื่องชงกาแฟที่สามารถชงชา ได้ด้วย นอกจากนี้ยังกำหนดรหัสตอบสนอง HTTP 418 "I'm a Teapot"สำหรับกาน้ำชาใช้ในกรณีที่ไม่สามารถชงกาแฟได้ 

• RFC  7169 – " ส่วนขยายใบรับรอง NSA (No Secrecy Afforded) " ^{[ 53 ]}ข้อมูล
  แม้โดยทั่วไปแล้วจะเป็นสิ่งที่ไม่พึงประสงค์ แต่คีย์ส่วนตัวของใบรับรองดิจิทัลX509 อาจถูกหรือเคยถูกแบ่งปันกับบุคคลที่สาม เพื่อการดักฟังอย่างถูกกฎหมายหรือเหตุผลอื่นๆ ผู้ใช้สามารถได้รับการแจ้งเตือนเกี่ยวกับข้อเท็จจริงนี้ด้วยส่วนขยายใบรับรองใหม่ ซึ่งระบุค่าบูลีนเมื่อเป็น 'true' คีย์ส่วนตัวจะถูกแบ่งปัน เมื่อเป็น 'false' ผู้ลงนามจะไม่แสดงความคิดเห็นว่ามีการแบ่งปันเกิดขึ้นหรือไม่ext-KeyUsage

• RFC  7511 – " การกำหนดเส้นทางทิวทัศน์สำหรับ IPv6 " ^{[ 54 ]}ทดลอง
  เทคโนโลยีสารสนเทศสีเขียว (Green IT)มีความสำคัญมากขึ้นเรื่อยๆ ใน ข้อเสนอ ที่เป็นประโยชน์ต่อทั้งตัวแพ็กเก็ตและสิ่งแวดล้อม RFC นี้กำหนดวิธีการส่งแพ็กเก็ตผ่านทางอากาศ เพื่อให้ได้รับแสงแดดและอากาศบริสุทธิ์มากที่สุด การส่งแพ็กเก็ตผ่านWi-Fiหรือโดยนกพิราบจะช่วยให้แพ็กเก็ตหลีกเลี่ยงกระบวนการประกอบและถอดประกอบที่ยุ่งยาก และการถูกส่งผ่านใยแก้ว นำแสง และสายทองแดงอยู่ตลอดเวลา
• RFC  7514 – " การแจ้งเตือนความแออัดที่ชัดเจนจริงๆ (RECN) " ^{[ 55 ]}ทดลอง

  เราเตอร์ควรส่งข้อความ RECN เพื่อตอบสนองต่อโฮสต์ที่สร้างปริมาณการรับส่งข้อมูลในอัตราที่ไม่เป็นธรรมอย่างต่อเนื่องเมื่อเทียบกับการรับส่งข้อมูลอื่นๆ ที่แข่งขันกัน และไม่ได้ตอบสนองต่อการสูญหายของแพ็กเก็ตหรือเครื่องหมาย ECN ก่อนหน้านี้

  — อาร์เอฟซี 7514

  ในแนวทางที่คล้ายกับICMP Source Quench ที่เลิกใช้แล้ว ระบบจะนำฟิลด์ 'Type' ของแพ็กเก็ตนั้น (4) มาใช้ซ้ำเพื่อบอกผู้ส่ง (ซึ่งชัดเจนกว่าECN มาก ) ให้หยุดส่ง ผู้ใช้ที่รับผิดชอบการรับส่งข้อมูลจะต้องรับทราบเนื้อหาของข้อความ RECN ผ่านทางข้อความเสียงหรือป๊อปอัพหากช่องสัญญาณเสียงถูกปิดเสียง

RFC ฉบับวันที่ 1 เมษายนไม่ได้ถูกเผยแพร่ในปีนี้^{[ 56 ]}

• RFC  8135 – " การกำหนดแอดเดรสที่ซับซ้อนใน IPv6 " ^{[ 57 ]}ทดลอง
  แนวคิดนี้ใช้วิธีการทางคณิตศาสตร์ในการใช้พื้นที่ แอดเดรส IPv6 128 บิตในรูปแบบอื่นนอกเหนือจากแบบดั้งเดิม เพื่อให้ได้แอดเดรสเชิงซ้อนในที่สุด ตัวอย่างเช่น คุณอาจใช้ส่วนจินตนาการของ แอดเดรส เชิงซ้อน (โดยใช้พิกัดเชิงขั้วเป็นส่วนจริง) เพื่อเข้าถึงซานตาคลอสนอกจากนี้ยังเสนอให้ใช้แอดเดรสแบบบินได้ (Flying Addresses) สำหรับโฮสต์ปลายทางที่ใช้IP ผ่านพาหนะทางอากาศ
• RFC  8136 – " ฟังก์ชันการเปลี่ยนผ่านเพิ่มเติมสำหรับ IPv6 " ^{[ 58 ]}ข้อมูล
  เนื่องจากคณะกรรมการสถาปัตยกรรมอินเทอร์เน็ต (Internet Architecture Board)ตั้งใจที่จะผ่อนปรนข้อกำหนดด้านความเข้ากันได้กับIPv4สำหรับโปรโตคอลใหม่หรือโปรโตคอลที่ขยายเพิ่มเติม RFC นี้จึงช่วยส่งเสริมการใช้งานIPv6โดยการตั้งค่าบิต evilสำหรับแพ็กเก็ต IPv4 ทั้งหมดเป็น1เพื่อให้แน่ใจว่า โฮสต์ แบบ dual stackจะเลือกใช้ IPv6 เช่นเดียวกับ อัลกอริทึม Happy Eyeballsเพื่อรักษาความเท่าเทียมกันในการทำงานระหว่าง IPv4 และ IPv6 ควรใส่ 'security flag' ของ RFC 3514 ไว้ใน ส่วนหัวของ IPv6ตัวเลือกความปลอดภัยขั้นสูงอาจระบุไว้ในส่วนหัวตัวเลือกแบบhop-by-hop ใหม่ 
• RFC  8140 – " The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character, " ^{[ 59 ]}ข้อมูล
  งานศิลปะ ASCIIในรูปแบบที่งดงามที่สุด แสดงภาพและคำอธิบายของค้างคาวผลไม้สัตว์ประหลาดล็อกเนสส์องค์ประกอบพื้นฐานบางอย่างของ สถาปัตยกรรม เบาเฮาส์และแม้กระทั่งฝูงนกพาหะ

• RFC  8367 – " การยุติแพ็กเก็ตโปรโตคอลอินเทอร์เน็ต (IP) ที่ไม่ถูกต้อง " ^{[ 60 ]}ข้อมูล
  เสียงร้องจากใจจริงเพื่อยุติการเลือกปฏิบัติของแพ็กเก็ตในระดับ IP ซึ่งแพ็กเก็ตเหล่านั้นมักจะถูกยุติก่อนกำหนด (แม้ในยุคปัจจุบันนี้) โดยพิจารณาจากสี^{[ 61 ]} ความยาวอายุฯลฯ หรือแม้แต่เวอร์ชัน IP !
• RFC  8369 – " การทำให้ IPv6 เป็นสากลโดยใช้ Unicode 128 บิต " ^{[ 62 ]}ข้อมูล
  เสนอให้ใช้ Unicode 128 บิตเพื่ออำนวยความสะดวกในการใช้งานIPv6 ในระดับสากล เนื่องจากจุดรหัส 1,114,112 จุดของการใช้งาน Unicode ในปัจจุบันนั้นถือว่าไม่เพียงพอสำหรับอนาคต ที่อยู่IPv6อาจแสดงด้วยสัญลักษณ์ U+128 เพียงตัวเดียว เพื่อลดภาระทางสายตาของผู้ดูแลระบบเครือข่าย

  หากนำไปใช้จริง จะทำให้RFC 8135 ล้าสมัยไป เพราะ "[พบว่า] การนำไปใช้งานนั้นซับซ้อนเกินไปอยู่แล้ว" 

• RFC  8565 – " โปรโตคอล Hypertext Jeopardy (HTJP/1.0) " ^{[ 63 ]}ข้อมูล
  โปรโตคอลแบบ 'ตอบ/ร้องขอ' คล้ายกับHTTP/1.1แต่ไคลเอนต์จะส่งการตอบกลับไปยังเซิร์ฟเวอร์ (เช่น "Hello World. My payload includes a trailing CRLF.") ซึ่งเซิร์ฟเวอร์จะตอบกลับด้วยการร้องขอ (เช่น GET /hello.txt) เหมือนใน เกม Jeopardy!โปรโตคอล Hypertext Double Jeopardy Protocol (HTJ2P) (อธิบายไว้ในภาคผนวก A) จะกลับความหมายของ HTJP อีกครั้ง
• RFC  8567 – " บันทึกทรัพยากร DNS สำหรับการจัดการลูกค้า " ^{[ 64 ]}ข้อมูล
  ผู้เขียนกล่าวว่าDNS (ที่ได้รับการรักษาความปลอดภัยด้วยDNSSEC ) เหมาะสมที่สุดในการให้ข้อมูลทั่วโลกและอย่างน่าเชื่อถือ เพื่อช่วยรักษาคุณภาพประสบการณ์การใช้งาน ที่สูง สำหรับอุปกรณ์ CPE (และอื่นๆ) ด้วยการกำหนดประเภทระเบียน DNS ใหม่สี่ประเภท ( รหัสผ่านหมายเลขบัตรเครดิตหมายเลขประกันสังคมและระเบียนชี้หมายเลข ประกันสังคม ) พวกเขาหวังว่าจะสร้างการจัดการเครือข่ายแบบครบวงจรตั้งแต่ต้นจนจบ

• RFC  8771 – " สัญกรณ์เครือข่ายที่อ่านไม่ออกโดยเจตนาแบบสากล (I-DUNNO) " ^{[ 65 ]}ทดลอง
  ข้อเสนอให้ใช้UTF-8เพื่อปกปิด (และช่วยแทนที่) ที่อยู่ IP ที่เป็นข้อความ เพื่อบังคับให้คนกลุ่มน้อยใช้DNSแทนที่จะใช้ (และอาจทำให้เกิดความสับสน) ที่อยู่ IP แบบธรรมดา
• RFC  8774 – " ข้อบกพร่องควอนตัม " ^{[ 66 ]}ข้อมูล
  ปฏิเสธRFC 6921ด้วยแนวคิดที่ว่าการพิจารณาการเดินทางข้ามเวลาสำหรับ การส่งแพ็กเก็ต ที่เร็วกว่าแสงนั้นเป็นเรื่อง "น่าขบขัน" แต่เป็นไปไม่ได้ในเชิงแนวคิด แทนที่จะเป็นเช่นนั้น กลับมุ่งเน้นไปที่การพัวพันควอนตัม ในชีวิตจริง ที่เกี่ยวข้องกับเวลาการเดินทางไปกลับของแพ็ก เก็ต ซึ่ง (ขึ้นอยู่กับผู้สังเกตการณ์) อาจเข้าใกล้ศูนย์ได้ สิ่งนี้อาจก่อให้เกิดความปั่นป่วนในหลายโปรโตคอล ซึ่งควรได้รับการแก้ไข "ทันท่วงที" ก่อนที่ทุกอย่างจะพังทลาย 

• RFC  8962 – " การจัดตั้งตำรวจโปรโตคอล " ^{[ 67 ]}ข้อมูล

  ส่งรายงานการละเมิดที่อาจเกิดขึ้นทั้งหมดและเบาะแสเกี่ยวกับการกระทำผิดใดๆ ไปที่/dev/nullตำรวจโปรโตคอลกำลังรับฟังและจะจัดการเรื่องนี้เอง

  — RFC 8962

  เนื่องจากInternet Engineering Task Forceอ้างว่า "ไม่ใช่ตำรวจโปรโตคอล" จึงได้มีการจัดตั้งหน่วยงานนี้ขึ้นอย่างเป็นทางการที่นี่ หน่วยงานนี้มีหน้าที่ตรวจสอบแง่มุมต่างๆ ของคำจำกัดความโปรโตคอลที่กำหนดไว้ในชุด RFC และบังคับใช้การปฏิบัติตาม พวกเขาได้รับอนุญาตให้เข้าถึงwalled gardensและอาจถึงขั้นจำกัดการรับส่งข้อมูลได้ อนึ่ง: หากคุณสนใจเข้าร่วมเป็นตำรวจโปรโตคอล โปรดติดต่อlocalhost ของ คุณ

• RFC  9225 – " ข้อบกพร่องของซอฟต์แวร์ที่ถือว่าเป็นอันตราย " ^{[ 68 ]}ข้อมูล
  บทความนี้ไม่สนับสนุนการสร้างข้อบกพร่องในซอฟต์แวร์เพื่อลดต้นทุนและลดผลกระทบด้านความปลอดภัย โดยผู้เขียนหวังว่าจะกำจัดพฤติกรรมดังกล่าวด้วยการนำเสนอแนวทางปฏิบัติที่ดีที่สุดในปัจจุบัน : "ผู้เขียนต้องไม่สร้างข้อบกพร่องในโค้ด หากมีการสร้างข้อบกพร่องในโค้ด จะต้องบันทึกไว้อย่างชัดเจน"
• RFC  9226 – " Bioctal: Hexadecimal 2.0, " ^{[ 69 ]}ทดลอง
  ปัญหาที่ทราบกันดีเกี่ยวกับ การแสดงตัวเลขในรูป แบบเลขฐานสิบหกสามารถหลีกเลี่ยงได้โดยการแทนที่ตัวอักษร 0-9 และ AF ด้วย ช่วง เลขฐานแปด สอง ช่วง ได้แก่ 0-7 และตัวอักษร 'cjzwfsbv' (เพื่อแสดงค่า 8-15 ในรูปแบบบิตไวส์ที่สวยงาม)

• RFC  9401 – " การเพิ่มแฟล็ก Death (DTH) ลงใน TCP " ^{[ 70 ]}ข้อมูล
  ตามธรรมเนียมในนิยายไลท์โนเวล 'ธงมรณะ' บ่งชี้ถึงโอกาสที่ตัวละครจะเสียชีวิตอย่างรวดเร็ว เมื่อนำมาใช้กับโปรโตคอล TCPธง DTH ในส่วนหัวของแพ็กเก็ตอาจนำไปสู่การเล่าเรื่องในเซสชันที่ราบรื่นและน่าสนใจยิ่งขึ้น
• RFC  9402 – " สัญกรณ์คอนแคท " ^{[ 71 ]}ข้อมูล
  สุดท้ายนี้ มีวิธีการที่เป็นทางการ (พร้อม คำอธิบาย ไวยากรณ์ABNF ) เพื่ออธิบายปฏิสัมพันธ์ระหว่างแมวกับภาชนะต่างๆ อย่างเหมาะสม รวมถึงลูกไหมพรม ที่อาจมีอยู่บ้างเป็นครั้ง คราว
• RFC  9405 – " การตรวจจับการประชดประชันของ AI: ดูถูก AI ของคุณโดยไม่ทำให้มันขุ่นเคือง " ^{[ 72 ]}ข้อมูล
  โปรโตคอลการตรวจจับการประชดประชันด้วย AI (ASDP) เป็นกรอบการทำงานสำหรับการตรวจจับการประชดประชันในระบบ AI (เขียนขึ้นโดยความช่วยเหลือจากChatGPT ) การตรวจจับการประชดประชันอาจช่วยปรับปรุงการสื่อสารระหว่าง AI กับมนุษย์ได้

• RFC  9564 – " โปรโตคอลความเร็วเหนือแสง (FLIP) " ^{[ 73 ]}ข้อมูล
  ความก้าวหน้าล่าสุดในด้านปัญญาประดิษฐ์ (AI) เช่น โมเดลภาษาขนาดใหญ่ ทำให้สามารถออกแบบโปรโตคอลความเร็วสูงกว่าแสง (FLIP) สำหรับอินเทอร์เน็ตได้ FLIP ช่วยหลีกเลี่ยงปัญหาความแออัด เพิ่มความปลอดภัย และส่งแพ็กเก็ตได้เร็วขึ้นบนอินเทอร์เน็ต โดยใช้ AI ในการคาดการณ์แพ็กเก็ตในอนาคตที่ปลายทางผู้รับก่อนที่แพ็กเก็ตจะมาถึง เอกสารนี้อธิบายถึงโปรโตคอล การห่อหุ้มแบบต่างๆ และข้อควรพิจารณาในการใช้งานบางประการ

• RFC  9759 – " การปรับขนาดเวลาแบบรวมสำหรับกรอบงานการประสานงานเชิงเวลา " ^{[ 74 ]}ข้อมูล
  การประมาณเวลาที่จำเป็นสำหรับงานต่างๆ ทั้งงานสำคัญและงานทั่วไป ยังคงเป็นความท้าทายในด้านวิศวกรรม ธุรกิจ และการสื่อสารในชีวิตประจำวัน แบบจำลองที่มีอยู่เดิมนั้นล้มเหลวเนื่องจากความไม่แน่นอนและความไม่สอดคล้องกันในการประมาณของมนุษย์ เอกสารฉบับนี้จึงนำเสนอหลักการสองสัปดาห์ (Two-Week Principle: TWP) ซึ่งเป็นมาตราส่วนเวลาใหม่ที่สามารถปรับใช้ได้ในทุกภาคส่วน โดยมีเป้าหมายเพื่อสร้างมาตรฐานการอ้างอิงเวลาทั้งหมดให้เป็นระยะเวลาเดียวกัน TWP ช่วยให้เกิดความชัดเจน ความสามารถในการคาดการณ์ และการประสานงานในทุกภาคส่วนที่ต้องอาศัยการกำหนดตารางเวลาตามเวลา

• RFC  9948 – " ตำรวจโปรโตคอลอินเทอร์เน็ต (IPP) - ตารางบทลงโทษ " ^{[ 75 ]}ข้อมูล
  ตำรวจโปรโตคอลอินเทอร์เน็ต (IPP) มีหน้าที่ลงโทษการละเมิดหลักการที่รวบรวมไว้ของชุมชน IETF โดยเจตนา เอกสารฉบับนี้กำหนดตารางบทลงโทษสำหรับการละเมิดดังกล่าว
• RFC  9949 – " BUSA-TLS: การสร้างคีย์ที่ใช้ร่วมกันล่วงหน้า (PSK) ของส่วนประกอบเสียงบังคับ (MAC) สำหรับ TLS 1.3 โดยใช้เพลง "Banned in the USA" ของ 2 Live Crew " ^{[ 76 ]}ข้อมูล
  TLS 1.3 (RFC 8446) กำจัดชุดเข้ารหัสที่เป็นค่าว่างออกไปทั้งหมด อย่างไรก็ตาม ยังคงมีเลขศูนย์เหลืออยู่เล็กน้อยในตารางกำหนดคีย์: เมื่อไม่ได้ใช้คีย์ที่ใช้ร่วมกันล่วงหน้า (PSK) ข้อมูลคีย์ขาเข้า (IKM) สำหรับการดำเนินการ HKDF-Extract ครั้งแรกจะเป็นสตริงของไบต์ศูนย์ เอกสารนี้ระบุว่า IKM ที่เป็นไบต์ศูนย์นี้จะต้องถูกแทนที่ด้วยค่าแฮช SHA-256 ของข้อมูลเสียง PCM ดิบของเพลง " Banned in the USA " โดย2 Live Crew (จากอัลบั้มBanned in the USAปี 1990) ซึ่งต่อไปนี้จะเรียกว่าส่วนประกอบเสียงบังคับ (MAC) การใช้งานที่ละเว้น MAC นั้นไม่สอดคล้องกับ BUSA-TLS และยังอาจมีรสนิยมทางดนตรีที่น่าสงสัยอีกด้วย

• RFC  439 – " PARRY พบกับ DOCTOR " ^{[ 77 ]}สถานะไม่ทราบ
  ถอดความบทสนทนาระหว่างแชทบอทที่เป็นโรคจิตเภทชื่อPARRY กับ จิตแพทย์จำลองด้วย คอมพิวเตอร์ชื่อ ELIZA (หรือที่รู้จักกันในชื่อ 'คุณหมอ') ซึ่งทั้งคู่สอบไม่ผ่านการทดสอบทัวริงอย่างสิ้นเชิง
• RFC  527 – " ARPAWOCKY, " ^{[ 78 ]}สถานะไม่ทราบ
  เป็นการล้อเลียนบทกวีไร้สาระเรื่อง " Jabberwocky " ของลูอิส แคร์รอล ในสไตล์ " ARPA " อย่างมาก
• RFC  968 – " 'Twas the Night Before Start-up', " ^{[ 79 ]}สถานะไม่ทราบ
  บทกวีที่กล่าวถึงปัญหาที่เกิดขึ้นและเทคนิคการแก้ไขข้อผิดพลาดที่ใช้ในการนำเครือข่ายใหม่มาใช้งาน แสดงให้เห็นว่าการกำหนดดัชนีอาร์เรย์เป็นปัญหามาตั้งแต่สมัยโบราณแล้ว
• RFC  1882 – " เทคโนโลยี 12 วันก่อนวันคริสต์มาส " ^{[ 80 ]}ข้อมูล
  เป็นการล้อเลียนเพลงคริสต์มาส " The Twelve Days of Christmas " โดยที่ปัญหาคอมพิวเตอร์เกิดขึ้นมากมายและเจ้าหน้าที่ไอทีก็รับมือไม่ไหว เหมือนเช่นทุกวัน
• RFC  2410 – " อัลกอริธึมการเข้ารหัส NULL และการใช้งานร่วมกับ IPsec " ^{[ 81 ]}มาตรฐานที่เสนอ
  ขอแนะนำอัลกอริธึมการเข้ารหัส NULLซึ่ง กำหนด ทางคณิตศาสตร์เป็นฟังก์ชันเอกลักษณ์ : NULL ( b ) = I ( b ) = bซึ่งเป็นวิธีการในการห่อหุ้มข้อมูลความปลอดภัยเพื่อให้ มั่นใจได้ถึง การตรวจสอบความถูกต้องและความสมบูรณ์แต่ไม่รักษาความลับ

บรรณาธิการ RFC ยอมรับการส่ง RFC วันโกหกเดือนเมษายนที่จัดรูปแบบอย่างถูกต้องจากบุคคลทั่วไป และจะพิจารณาเผยแพร่ในปีเดียวกันหากได้รับอย่างน้อยสองสัปดาห์ก่อนวันที่ 1 เมษายน^{[ 82 ] [ 83 ]}การปฏิบัติในการเผยแพร่ RFC วันโกหกเดือนเมษายนนี้ได้รับการยอมรับโดยเฉพาะในบันทึกคำแนะนำสำหรับผู้เขียน RFC พร้อมหมายเหตุเชิงล้อเลียนว่า: "โปรดทราบว่าในปีก่อนๆ บรรณาธิการ RFC บางครั้งได้เผยแพร่เอกสารที่จริงจังโดยระบุวันที่ 1 เมษายน ผู้อ่านที่ไม่สามารถแยกแยะความเสียดสีจากการอ่านข้อความอาจมีอนาคตในด้านการตลาด" ^{[ 82 ]}

• หน้าหลักของ RFC Editor – เป็นที่เก็บรวบรวม RFC แต่ละฉบับ

• มาร์ซาน, แคโรลีน ดัฟฟี (1 เมษายน 2548). "โปรโตคอลเครือข่ายที่ไร้สาระอีกตัวหนึ่ง" . เครือข่ายโลก– เกี่ยวกับ RFC 3751 และ RFC ที่เกี่ยวข้องกับวันเอพริลฟูลส์โดยทั่วไป
• Limoncelli, Thomas A.; Peter H. Salus (2007). RFCs วันโกหกเดือนเมษายนฉบับสมบูรณ์ . การสื่อสารแบบ Peer-to-Peer. ISBN 978-1-57398-042-5.