เอกสารขอความคิดเห็น ( RFC ) เป็นเอกสารชุดหนึ่งจากหน่วยงานหลักด้านการพัฒนาทางเทคนิคและการกำหนดมาตรฐานสำหรับอินเทอร์เน็ตโดยเฉพาะอย่างยิ่งInternet Engineering Task Force (IETF) ^{[ 1 ] [ 2 ]} RFC ถูกเขียนขึ้นโดยบุคคลหรือกลุ่มวิศวกรและนักวิทยาศาสตร์คอมพิวเตอร์ในรูปแบบของบันทึกข้อความที่อธิบายวิธีการ พฤติกรรม การวิจัย หรือนวัตกรรมที่ใช้ได้กับการทำงานของอินเทอร์เน็ตและระบบที่เชื่อมต่อกับอินเทอร์เน็ต โดยจะถูกส่งเพื่อการตรวจสอบโดยผู้เชี่ยวชาญหรือเพื่อถ่ายทอดแนวคิด ข้อมูล หรือบางครั้งก็เป็นเรื่องตลกทางวิศวกรรม^{[ 3 ]}

IETF นำข้อเสนอที่เผยแพร่เป็น RFC บางส่วนมาใช้เป็นมาตรฐานอินเทอร์เน็ตอย่างไรก็ตาม RFC จำนวนมากมีลักษณะเป็นข้อมูลหรือการทดลอง และไม่ใช่มาตรฐาน^{[ 4 ]}ระบบ RFC ถูกคิดค้นโดยSteve Crockerในปี 1969 เพื่อช่วยบันทึกบันทึกย่อที่ไม่เป็นทางการเกี่ยวกับการพัฒนาARPANETตั้งแต่นั้นมา RFC ได้กลายเป็นเอกสารอย่างเป็นทางการของข้อกำหนด อินเทอร์เน็ต โปรโตคอลการสื่อสารขั้นตอน และเหตุการณ์ต่างๆ^{[ 5 ]}ตามที่ Crocker กล่าว เอกสารเหล่านี้ "กำหนดรูปแบบการทำงานภายในของอินเทอร์เน็ตและมีบทบาทสำคัญในความสำเร็จ" แต่ไม่เป็นที่รู้จักอย่างกว้างขวางนอกชุมชน^{[ 6 ]}

นอกเหนือจากชุมชนอินเทอร์เน็ตแล้ว ยังมีการเผยแพร่ เอกสารอื่นๆ ที่เรียกว่า คำขอความคิดเห็น^เช่น งานของ รัฐบาลกลางสหรัฐฯเช่นสำนักงานบริหารความปลอดภัยการจราจรบนทางหลวงแห่งชาติ [ ^{7 ]}

รูปแบบ RFC เริ่มต้นขึ้นในปี พ.ศ. 2512 ซึ่งเป็นส่วนหนึ่งของโครงการARPANET ที่สำคัญ ^{[ 6 ]}ปัจจุบัน RFC เป็นช่องทางการเผยแพร่อย่างเป็นทางการสำหรับInternet Engineering Task Force (IETF), Internet Architecture Board (IAB) และในระดับหนึ่งสำหรับชุมชน นักวิจัย เครือข่ายคอมพิวเตอร์ ทั่วโลก โดยทั่วไป

ผู้เขียน RFC รุ่นแรก ๆพิมพ์งานของพวกเขาและแจกจ่ายสำเนาเอกสารให้กับ นักวิจัย ARPAต่างจาก RFC ในปัจจุบัน RFC รุ่นแรก ๆ หลายฉบับเป็นคำขอความคิดเห็นจริง ๆ และตั้งชื่อเช่นนั้นเพื่อหลีกเลี่ยงการฟังดูเป็นการประกาศมากเกินไปและเพื่อกระตุ้นให้เกิดการอภิปราย^{[ 8 ] [ 9 ]} RFC เปิดโอกาสให้มีการถามคำถามและเขียนในรูปแบบที่ไม่เป็นทางการมากนัก รูปแบบที่ไม่เป็นทางการนี้เป็นลักษณะทั่วไปของ เอกสาร ร่างอินเทอร์เน็ตซึ่งเป็นขั้นตอนเบื้องต้นก่อนที่จะได้รับการอนุมัติเป็น RFC

ในเดือนธันวาคม พ.ศ. 2512 นักวิจัยเริ่มเผยแพร่ RFC ใหม่ผ่านทาง ARPANET ที่เพิ่งเปิดใช้งานRFC  1ซึ่งมีชื่อว่า "ซอฟต์แวร์โฮสต์" เขียนโดยSteve Crockerจากมหาวิทยาลัยแคลิฟอร์เนีย ลอสแอนเจลิส (UCLA) และเผยแพร่เมื่อวันที่ 7 เมษายน พ.ศ. 2512 ^{[ 10 ]}แม้ว่าจะเป็นผลงานของ Steve Crocker แต่ RFC นี้เกิดขึ้นจาก การอภิปราย กลุ่มทำงาน ในช่วงแรก ระหว่าง Steve Crocker, Steve Carr และJeff Rulifson

ในใน RFC  3ซึ่งเป็นฉบับแรกที่กำหนดชุด RFC นั้น Crocker เริ่มระบุว่าชุด RFC นี้เป็นของกลุ่มทำงานด้านเครือข่าย (Network Working Group) แทนที่จะเป็นคณะกรรมการอย่างเป็นทางการ แต่เป็นกลุ่มนักวิจัยที่ไม่เป็นทางการที่สนใจในโครงการ ARPANET โดยในทางปฏิบัติแล้ว กลุ่มนี้รวมถึงทุกคนที่ต้องการเข้าร่วมการประชุมและการอภิปรายเกี่ยวกับโครงการ

RFC จำนวนมากในช่วงทศวรรษ 1970 มาจาก UCLA เช่นกัน เนื่องจาก UCLA เป็นหนึ่งในหน่วยประมวลผลข้อความอินเทอร์เฟซ (IMP) แรกๆ บน ARPANET ศูนย์วิจัยเสริมประสิทธิภาพ (ARC) ที่สถาบันวิจัยสแตนฟอร์ดซึ่งกำกับโดยDouglas Engelbartก็เป็นหนึ่งในสี่โหนด แรกของ ARPANET และเป็นแหล่งที่มาของ RFC ในยุคแรกๆ ARC กลายเป็นศูนย์ข้อมูลเครือข่ายแห่งแรก ( InterNIC ) ซึ่งบริหารจัดการโดยElizabeth J. Feinlerเพื่อเผยแพร่ RFC พร้อมกับข้อมูลเครือข่ายอื่นๆ^{[ 11 ]}

ในวันเอพริลฟูลส์เดย์ปี 1978 RFC  748ถูกเผยแพร่เพื่อล้อเลียนรูป แบบเอกสาร TCP/IPและมีการล้อเลียนอีกครั้งในปี 1989 ด้วยการเผยแพร่RFC  1097ซึ่งอธิบายถึงตัวเลือกสำหรับ ไคลเอนต์ Telnetในการแสดงข้อความแฝงหลังจากนั้นก็มีการเผยแพร่RFC ในวันเอพริลฟูลส์เดย์ เป็นประจำทุกปี โดยเฉพาะอย่างยิ่ง RFC  2324ซึ่งอธิบายถึงHyper Text Coffee Pot Control Protocolและกำหนดสถานะ HTTP 418 "ฉันเป็นกาน้ำชา" RFC ที่มีเนื้อหาตลกขบขันนั้นย้อนกลับไปถึงRFC  439ซึ่งเผยแพร่ในเดือนมกราคมปี 1973

ตั้งแต่ปี พ.ศ. 2512 จนถึงปี พ.ศ. 2541 จอน โพสเทลดำรงตำแหน่งบรรณาธิการ RFC เมื่อเขาเสียชีวิตในปี พ.ศ. 2541 บทความไว้อาลัยของเขาได้รับการตีพิมพ์เป็นRFC  2468 ^{[ 12 ]}

หลังจากการหมดอายุของสัญญา ARPANET เดิมกับรัฐบาลกลางสหรัฐฯ สมาคมอินเทอร์เน็ตซึ่งทำหน้าที่ในนามของ IETF ได้ทำสัญญากับแผนกเครือข่ายของสถาบันวิทยาศาสตร์สารสนเทศ (ISI) มหาวิทยาลัยเซาท์เทิร์นแคลิฟอร์เนีย (USC ) เพื่อรับหน้าที่บรรณาธิการและการเผยแพร่ภายใต้การกำกับดูแลของ IAB แซนดี้ จิโนซา เข้าร่วม USC/ISI ในปี 1999 เพื่อทำงานด้านการแก้ไข RFC และอลิซ ฮาเกนส์ ในปี 2005 ^{[ 13 ]}บ็อบ แบรเดนเข้ามารับบทบาทเป็นหัวหน้าโครงการ RFC ในขณะที่จอยซ์ เค. เรย์โนลด์สยังคงเป็นส่วนหนึ่งของทีมจนถึงวันที่ 13 ตุลาคม 2006

ในเดือนกรกฎาคม พ.ศ. 2550 ได้มีการกำหนด กระแสของ RFC เพื่อให้สามารถแบ่งหน้าที่การแก้ไขได้ เอกสารของ IETF มาจากกลุ่มงานของ IETF หรือการส่งที่ได้รับการสนับสนุนจากผู้อำนวยการพื้นที่ของ IETF จากInternet Engineering Steering Group IAB สามารถเผยแพร่เอกสารของตนเองได้ กระแสเอกสารวิจัยมาจากInternet Research Task Force (IRTF) และกระแสอิสระจากแหล่งข้อมูลภายนอกอื่นๆ^{[ 14 ]}มีการเสนอรูปแบบใหม่ในปี พ.ศ. 2551 ปรับปรุง และเผยแพร่ในเดือนสิงหาคม พ.ศ. 2552 โดยแบ่งงานออกเป็นหลายบทบาท^{[ 15 ]}รวมถึง RFC Series Advisory Group (RSAG) รูปแบบดังกล่าวได้รับการปรับปรุงในปี พ.ศ. 2555 ^{[ 16 ]}และ พ.ศ. 2563 ^{[ 17 ]} กระแสต่างๆ ยังได้รับการปรับปรุงในเดือนธันวาคม พ.ศ. 2552 โดยมีการกำหนดมาตรฐานสำหรับรูปแบบ^{[ 18 ]} ในเดือนมกราคม พ.ศ. 2553 หน้าที่บรรณาธิการ RFC ถูกย้ายไปยังผู้รับเหมา Association Management Solutions โดยมี Glenn Kowack ทำหน้าที่เป็นบรรณาธิการชุดชั่วคราว^{[ 19 ]}ในช่วงปลายปี 2011 เฮเธอร์ แฟลนาแกน ได้รับการว่าจ้างให้เป็นบรรณาธิการชุด RFC (RSE) ถาวร และในเวลาเดียวกันนั้นเอง คณะกรรมการกำกับดูแลชุด RFC (RSOC) ก็ได้ถูกจัดตั้งขึ้น^{[ 20 ]}

ในปี 2020 IAB ได้จัดการประชุมโครงการพัฒนาในอนาคตของบรรณาธิการ RFC เพื่อหารือเกี่ยวกับการเปลี่ยนแปลงที่อาจเกิดขึ้นกับแบบจำลองบรรณาธิการ RFC ผลลัพธ์ของโครงการนี้รวมถึงแบบจำลองบรรณาธิการ RFC (เวอร์ชัน 3) ตามที่กำหนดไว้ในRFC  9280ซึ่งเผยแพร่ในเดือนมิถุนายน 2022 ^{[ 1 ]}โดยทั่วไป แบบจำลองใหม่นี้มีจุดประสงค์เพื่อชี้แจงความรับผิดชอบและกระบวนการในการกำหนดและดำเนินการนโยบายที่เกี่ยวข้องกับชุด RFC และหน้าที่ของบรรณาธิการ RFC การเปลี่ยนแปลงในแบบจำลองใหม่นี้รวมถึงการจัดตั้งตำแหน่งบรรณาธิการที่ปรึกษา RFC กลุ่มทำงานชุด RFC (RSWG) และคณะกรรมการอนุมัติชุด RFC (RSAB) นอกจากนี้ยังได้จัดตั้งกระแสการแก้ไขใหม่สำหรับชุด RFC และยุติ RSOC บทบาทของ RSE เปลี่ยนเป็นบรรณาธิการที่ปรึกษาชุด RFC (RSCE) ในเดือนกันยายน 2022 Alexis Rossi ได้รับการแต่งตั้งให้ดำรงตำแหน่งดังกล่าว^{[ 21 ]}

คำขอความคิดเห็นเดิมทีจัดทำในรูปแบบข้อความที่ไม่สามารถปรับขนาดได้ในเดือนสิงหาคม พ.ศ. 2562 รูปแบบดังกล่าวได้รับการเปลี่ยนแปลงเพื่อให้สามารถดูเอกสารใหม่ได้อย่างเหมาะสมในอุปกรณ์ที่มีขนาดหน้าจอแตกต่างกัน^{[ 22 ]}

บรรณาธิการ RFC จะกำหนดหมายเลขลำดับ ให้กับ RFC แต่ละฉบับ เมื่อกำหนดหมายเลขและเผยแพร่แล้ว RFC จะไม่ถูกยกเลิกหรือแก้ไข หากเอกสารต้องการการแก้ไข ผู้เขียนจะเผยแพร่เอกสารฉบับแก้ไข ดังนั้น RFC บางฉบับจึงแทนที่ RFC อื่นๆ RFC ที่ถูกแทนที่นั้นเรียกว่าล้าสมัยหมดสภาพหรือถูกแทนที่โดย RFC ที่มาแทนที่ RFC ที่มีหมายเลขลำดับเหล่านี้รวมกันเป็นบันทึกทางประวัติศาสตร์อย่างต่อเนื่องของการวิวัฒนาการของมาตรฐานและแนวปฏิบัติของอินเทอร์เน็ต กระบวนการ RFC ได้รับการบันทึกไว้ในRFC  2026 ( กระบวนการมาตรฐานอินเทอร์เน็ต ฉบับแก้ไข 3 ) ^{[ 23 ]}

กระบวนการผลิต RFC แตกต่างจาก กระบวนการ มาตรฐานขององค์กรมาตรฐานอย่างเป็นทางการ เช่นองค์การมาตรฐานสากล (ISO) ผู้เชี่ยวชาญด้านเทคโนโลยีอินเทอร์เน็ตอาจส่งร่างมาตรฐานอินเทอร์เน็ตโดยไม่ได้รับการสนับสนุนจากสถาบันภายนอก RFC ที่อยู่ในเส้นทางมาตรฐานจะได้รับการเผยแพร่โดยได้รับอนุมัติจาก IETF และมักจะผลิตโดยผู้เชี่ยวชาญที่เข้าร่วมในกลุ่มทำงานของ IETFซึ่งจะเผยแพร่ร่างมาตรฐานอินเทอร์เน็ตก่อน วิธีการนี้ช่วยอำนวยความสะดวกในการตรวจสอบโดยผู้เชี่ยวชาญในรอบแรกก่อนที่เอกสารจะพัฒนาเป็น RFC ^{[ 24 ]}

ธรรมเนียมปฏิบัติของ RFC ในการจัดทำมาตรฐานตามประสบการณ์จริงและดำเนินการภายหลังโดยบุคคลหรือกลุ่มทำงานขนาดเล็กสามารถมีข้อดีที่สำคัญเหนือกระบวนการที่เป็นทางการมากขึ้นซึ่งขับเคลื่อนโดยคณะกรรมการซึ่งเป็นเรื่องปกติของ ISO และหน่วยงานมาตรฐานแห่งชาติ^{[ 25 ]}

RFC ส่วนใหญ่ใช้ชุดคำศัพท์ทั่วไป เช่น "ต้อง" และ "ไม่แนะนำ" (ตามที่กำหนดโดยRFC  2119และ8174 ) รูปแบบ Backus–Naur เสริม (ABNF) ( RFC  5234 ) เป็นภาษาเมตา และการจัดรูปแบบตามข้อความอย่างง่าย เพื่อให้ RFC มีความสอดคล้องและเข้าใจง่าย^{[ 23 ]}

ชุดเอกสาร RFC ประกอบด้วยชุดย่อยสามชุดสำหรับ เอกสาร RFC ของ IETFได้แก่ BCP, FYI และ STD Best Current Practice (BCP) เป็นชุดย่อยของเอกสาร RFC ของ IETF ที่บังคับใช้แต่ไม่ได้อยู่ในเส้นทางมาตรฐาน For Your Information (FYI) เป็นชุดย่อยของเอกสาร RFC ที่ให้ข้อมูลซึ่งได้รับการส่งเสริมโดย IETF ตามที่ระบุไว้ในRFC  1150 (FYI 1) ในปี 2011 RFC  6360ได้ยกเลิก FYI 1 และยุติชุดย่อยนี้ Standard (STD) เคยเป็นระดับความสมบูรณ์ระดับที่สามและสูงสุดของเส้นทางมาตรฐานของ IETF ตามที่ระบุไว้ในRFC  2026 (BCP 9) ในปี 2011 RFC  6410 (ส่วนใหม่ของ BCP 9) ได้ลดระดับความสมบูรณ์ของเส้นทางมาตรฐานเหลือเพียงสองระดับ

มี RFC อยู่ 5 สาย ได้แก่IETF , IRTF , IAB , การส่ง เอกสารอิสระ^{[ 26 ]}และสายบรรณาธิการมีเพียง IETF เท่านั้นที่สร้าง BCP และ RFC บนเส้นทางมาตรฐาน IAB เผยแพร่เอกสารข้อมูลที่เกี่ยวข้องกับนโยบายหรือสถาปัตยกรรม IRTF เผยแพร่ผลการวิจัย ไม่ว่าจะเป็นเอกสารข้อมูลหรือการทดลอง การส่งเอกสารอิสระจะได้รับการเผยแพร่ตามดุลยพินิจของบรรณาธิการการส่งเอกสารอิสระ เอกสารที่ไม่ใช่ของ IETF จะได้รับการตรวจสอบโดยIESG เพื่อ หาข้อขัดแย้งกับงานของ IETF โดยทั่วไป RFC ของ IRTF และ RFC อิสระ จะมีข้อมูลหรือการทดลองที่เกี่ยวข้องกับอินเทอร์เน็ตโดยรวมซึ่งไม่ขัดแย้งกับงานของ IETF เปรียบเทียบRFC  4846 , 5742และ5744 ^{[ 27 ] [ 28 ]}สายบรรณาธิการใช้เพื่อดำเนินการเปลี่ยนแปลงนโยบายบรรณาธิการในชุด RFC (ดูRFC  9280 ) ^{[ 1 ]}

RFC 2046 ประเภทสื่อ พฤศจิกายน 1996 ก. ไวยากรณ์รวม .................................... 43 1. บทนำ เอกสารฉบับแรกในชุดนี้คือ RFC 2045 ซึ่งกำหนดส่วนหัวจำนวนหนึ่ง ฟิลด์ต่างๆ รวมถึงฟิลด์ Content-Type ฟิลด์ Content-Type ใช้สำหรับ ระบุลักษณะของข้อมูลในส่วนเนื้อหาของเอนทิตี MIME โดย โดยการให้ตัวระบุประเภทและประเภทย่อยของสื่อ และโดยการให้ข้อมูลเพิ่มเติม ข้อมูลที่อาจจำเป็นสำหรับสื่อบางประเภท หลังจากนั้น 

แหล่งข้อมูลอย่างเป็นทางการสำหรับ RFC บนเวิลด์ไวด์เว็บคือ RFC Datatracker สามารถเรียกดู RFC ที่เผยแพร่แล้วเกือบทุกฉบับได้ผ่านURL ในรูปแบบ https://datatracker.ietf.org/doc/html/rfc5000 ดังแสดงในตัวอย่าง สำหรับRFC  5000

เอกสาร RFC ทุกฉบับจะถูกส่งมาในรูปแบบข้อความ ASCIIธรรมดาและเผยแพร่ในรูปแบบนั้น แต่ก็อาจมีให้ใช้งานในรูปแบบ อื่น ๆ ด้วยเช่น กัน

เพื่อให้เข้าถึงข้อมูลเมตาของ RFC ได้ง่ายขึ้น รวมถึงบทคัดย่อ คำสำคัญ ผู้เขียน วันที่เผยแพร่ ข้อผิดพลาด สถานะ และโดยเฉพาะอย่างยิ่งการอัปเดตในภายหลัง เว็บไซต์ RFC Editor มีแบบฟอร์มค้นหาที่มีคุณสมบัติมากมาย การเปลี่ยนเส้นทางจะตั้งค่าพารามิเตอร์ที่มีประสิทธิภาพบางอย่าง เช่น rfc:5000 ^{[ 4 ]}

หมายเลขมาตรฐานสากลอย่างเป็นทางการ(ISSN) ของชุด RFC คือ 2070-1721 ^{[ 18 ]}

ไม่ใช่ว่า RFC ทั้งหมดจะเป็นมาตรฐาน^{[ 29 ]} RFC แต่ละรายการจะได้รับการกำหนดสถานะภายในกระบวนการมาตรฐานอินเทอร์เน็ต สถานะนี้เป็นหนึ่งในสถานะต่อไปนี้: ข้อมูล , การทดลอง , แนวปฏิบัติที่ดีที่สุด ^ในปัจจุบัน , เส้นทางมาตรฐานหรือประวัติศาสตร์ [ ^{4 ]}

เมื่อส่ง RFC แล้ว ได้รับการยอมรับและเผยแพร่แล้ว จะไม่สามารถเปลี่ยนแปลงได้ สามารถส่งคำแก้ไขเพิ่มเติมได้ ซึ่งจะได้รับการเผยแพร่แยกต่างหาก การเปลี่ยนแปลงที่สำคัญกว่านั้นจำเป็นต้องมีการส่งใหม่ ซึ่งจะได้รับหมายเลขลำดับใหม่^{[ 30 ]}

เอกสารมาตรฐานยังแบ่งออกเป็นเอกสารมาตรฐานที่เสนอและเอกสารมาตรฐานอินเทอร์เน็ต อีกด้วย ^{[ 31 ]}

มีเพียง IETF ซึ่งเป็นตัวแทนโดยInternet Engineering Steering Group (IESG) เท่านั้นที่สามารถอนุมัติRFC ที่นำไปสู่มาตรฐาน ได้

หาก RFC กลายเป็นมาตรฐานอินเทอร์เน็ต (STD) จะได้รับหมายเลข STD แต่ยังคงหมายเลข RFC ไว้ รายการมาตรฐานอินเทอร์เน็ตที่แน่นอนคือมาตรฐานโปรโตคอลอินเทอร์เน็ตอย่างเป็นทางการ ก่อนหน้านี้ STD 1 ใช้เพื่อบันทึกภาพรวมของรายการ^{[ 32 ]}

เมื่อมาตรฐานอินเทอร์เน็ตได้รับการอัปเดต หมายเลข STD ของมาตรฐานนั้นจะยังคงเหมือนเดิม โดยจะอ้างอิงถึง RFC ใหม่หรือชุด RFC ใหม่ มาตรฐานอินเทอร์เน็ตที่กำหนด STD nอาจเป็น RFC xและyในช่วงเวลาหนึ่ง แต่ต่อมามาตรฐานเดียวกันนั้นอาจได้รับการอัปเดตเป็น RFC zแทน ตัวอย่างเช่น ในปี 2007 RFC  3700เป็นมาตรฐานอินเทอร์เน็ต—STD 1—และในเดือนพฤษภาคม 2008 ได้ถูกแทนที่ด้วยRFC  5000ดังนั้นRFC  3700จึงเปลี่ยนเป็นสถานะประวัติศาสตร์ RFC  5000กลายเป็นมาตรฐานอินเทอร์เน็ต และตั้งแต่เดือนพฤษภาคม 2008 STD 1 คือRFC  5000 และ ตั้งแต่เดือนธันวาคม 2013 RFC  5000ถูกแทนที่ด้วยRFC  7100ซึ่งเป็นการอัปเดตRFC  2026ให้ไม่ใช้ STD 1 อีกต่อไป

(แนวปฏิบัติที่ดีที่สุดในปัจจุบันทำงานในลักษณะเดียวกัน โดย BCP nอ้างอิงถึง RFC เฉพาะฉบับหรือชุดของ RFC แต่ RFC เหล่านั้นอาจเปลี่ยนแปลงไปตามเวลา)

เอกสาร RFC ที่ให้ข้อมูลนั้นอาจเป็นอะไรก็ได้ ตั้งแต่เรื่องตลกในวันเอพริลฟูลไปจนถึงเอกสาร RFC ที่ได้รับการยอมรับอย่างกว้างขวางและมีความสำคัญ เช่นโครงสร้างและการมอบหมายระบบชื่อโดเมน ( RFC  1591 ) เอกสาร RFC ที่ให้ข้อมูลบางส่วนได้ถูกนำมาจัดทำเป็นชุดย่อย FYI ( Failure for Information)

RFC ทดลองอาจเป็นเอกสาร IETF หรือการส่งส่วนบุคคลไปยังบรรณาธิการ RFC ร่างจะถูกกำหนดให้เป็นการทดลองหากไม่ชัดเจนว่าข้อเสนอจะทำงานได้ตามที่ตั้งใจไว้หรือไม่ หรือไม่ชัดเจนว่าข้อเสนอจะได้รับการยอมรับอย่างกว้างขวางหรือไม่ RFC ทดลองอาจได้รับการเลื่อนขั้นเป็นมาตรฐานหากได้รับความนิยมและทำงานได้ดี^{[ 33 ]}

ชุดย่อย แนวปฏิบัติที่ดีที่สุดในปัจจุบัน (Best Current Practice)รวบรวมเอกสารการบริหารและข้อความอื่นๆ ที่ถือว่าเป็นกฎอย่างเป็นทางการ ไม่ใช่เพียงแค่ข้อมูลแต่ไม่มีผลกระทบต่อข้อมูลผ่านสายส่งขอบเขตระหว่างเส้นทางมาตรฐานและ BCP มักไม่ชัดเจน หากเอกสารมีผลกระทบต่อกระบวนการมาตรฐานอินเทอร์เน็ตเท่านั้น เช่น BCP 9 ^{[ 34 ]}หรือการบริหาร IETF ก็ถือว่าเป็น BCP อย่างชัดเจน หากเอกสารนั้นกำหนดกฎและข้อบังคับสำหรับหน่วยงานทะเบียน Internet Assigned Numbers Authority (IANA) เท่านั้น ก็จะไม่ชัดเจนนัก เอกสารส่วนใหญ่เหล่านี้เป็น BCP แต่บางส่วนก็อยู่ในเส้นทางมาตรฐาน

ชุดเอกสาร BCP ยังครอบคลุมถึงคำแนะนำทางเทคนิคเกี่ยวกับวิธีการปฏิบัติตามมาตรฐานอินเทอร์เน็ต ตัวอย่างเช่น คำแนะนำให้ใช้การกรองแหล่งที่มาเพื่อทำให้การโจมตี DoSทำได้ยากขึ้น ( RFC  2827 : " การกรองขาเข้าเครือข่าย: การเอาชนะการโจมตีแบบปฏิเสธการให้บริการที่ใช้การปลอมแปลงที่อยู่ IP ต้นทาง ") คือBCP 38

RFC ทางประวัติศาสตร์คือ RFC ที่เทคโนโลยีที่กำหนดโดย RFC นั้นไม่แนะนำให้ใช้อีกต่อไป ซึ่งแตกต่างจากส่วนหัว "ล้าสมัย" ใน RFC ทดแทน ตัวอย่างเช่นRFC  821 ( SMTP ) เองก็ล้าสมัยไปแล้วเนื่องจาก RFC รุ่นใหม่กว่าหลายฉบับ แต่ SMTP เองยังคงเป็น "เทคโนโลยีปัจจุบัน" ดังนั้นจึงไม่ได้อยู่ในสถานะ "ประวัติศาสตร์" ^{[ 35 ]}อย่างไรก็ตาม เนื่องจากBGP เวอร์ชัน 4ได้เข้ามาแทนที่ BGP เวอร์ชันก่อนหน้าทั้งหมดแล้ว RFC ที่อธิบายเวอร์ชันก่อนหน้าเหล่านั้น เช่นRFC  1267จึงถูกกำหนดให้เป็นประวัติศาสตร์

สถานะไม่ทราบใช้สำหรับ RFC เก่าบางฉบับ ซึ่งไม่ชัดเจนว่าเอกสารจะได้รับสถานะใดหากได้รับการเผยแพร่ในปัจจุบัน RFC บางฉบับเหล่านี้จะไม่ได้รับการเผยแพร่ในปัจจุบันเลย RFC ในยุคแรกมักจะเป็นเพียงคำขอความคิดเห็นธรรมดา ไม่ได้มีจุดประสงค์เพื่อระบุโปรโตคอล ขั้นตอนการบริหาร หรือสิ่งอื่นใดที่ใช้ชุด RFC ในปัจจุบัน^{[ 36 ]}

โดยทั่วไปแล้ว ผู้เขียนต้นฉบับ (หรือนายจ้างของพวกเขา หากเงื่อนไขการจ้างงานระบุไว้เช่นนั้น) จะยังคงเป็นเจ้าของลิขสิทธิ์ เว้นแต่พวกเขาจะโอนสิทธิ์ของตนโดยชัดแจ้ง^{[ 37 ]}

หน่วยงานอิสระ IETF Trust ถือครองลิขสิทธิ์สำหรับ RFC บางฉบับ และสำหรับ RFC อื่นๆ ทั้งหมด ได้รับอนุญาตจากผู้เขียนให้สามารถทำซ้ำ RFC ได้^{[ 38 ]} Internet Societyถูกอ้างอิงใน RFC หลายฉบับก่อน RFC4714 ในฐานะเจ้าของลิขสิทธิ์ แต่ได้โอนสิทธิ์ให้กับ IETF Trust แล้ว^{[ 39 ]}

• แนวปฏิบัติที่ดีที่สุดในปัจจุบัน
• หมายเหตุการทดลองทางอินเทอร์เน็ต
• รายชื่อ RFC

วิกิดาต้ามีคุณสมบัติดังนี้:

• รหัส RfC (P892) (ดูรายละเอียดการใช้งาน )

• บรรณาธิการ RFC
• ฐานข้อมูล RFC
• RFC Errata
• คำถามที่พบบ่อยเกี่ยวกับ RFC
• ดัชนี RFC (ข้อความ)
• มาตรฐานโปรโตคอลอินเทอร์เน็ตอย่างเป็นทางการ
• หน้า RFC ของ IETF
• ดัชนี RFC (HTML) ประกอบด้วยเนื้อหาของ RFC แต่ละฉบับ พร้อมทั้งระบุว่า RFC ฉบับนี้ "ปรับปรุง" หรือ "ได้รับการปรับปรุงโดย" RFC ใดบ้าง