طلب تعليقات

ستيف كروكر، جالسًا مع جهاز كمبيوتر محمول
ستيف كروكر ، مؤلف العديد من وثائق طلب التعليقات، بما في ذلك أول وثيقة طلب تعليقات على الإطلاق.

طلب التعليقات ( RFC ) هو منشور ضمن سلسلة منشورات صادرة عن الهيئات الرئيسية المعنية بالتطوير التقني ووضع المعايير للإنترنت ، وأبرزها فرقة عمل هندسة الإنترنت (IETF). [ 1 ] [ 2 ] يُكتب طلب التعليقات من قِبل أفراد أو مجموعات من المهندسين وعلماء الحاسوب في شكل مذكرة تصف الأساليب أو السلوكيات أو الأبحاث أو الابتكارات التي تنطبق على عمل الإنترنت والأنظمة المتصلة به. ويُقدّم إما للمراجعة من قِبل النظراء أو لنقل مفاهيم أو معلومات جديدة، أو أحيانًا، لإضفاء لمسة من الفكاهة الهندسية. [ 3 ]

تتبنى فرقة عمل هندسة الإنترنت (IETF) بعض المقترحات المنشورة في شكل وثائق طلب التعليقات (RFCs) كمعايير للإنترنت . مع ذلك، فإن العديد من وثائق طلب التعليقات ذات طبيعة إعلامية أو تجريبية وليست معايير. [ 4 ] ابتكر ستيف كروكر نظام وثائق طلب التعليقات عام 1969 للمساعدة في تسجيل ملاحظات غير رسمية حول تطوير شبكة أربانت . ومنذ ذلك الحين، أصبحت وثائق طلب التعليقات وثائق رسمية لمواصفات الإنترنت وبروتوكولات الاتصالات والإجراءات والأحداث. [ 5 ] ووفقًا لكروكر، فإن هذه الوثائق "تُشكّل آليات عمل الإنترنت الداخلية ولعبت دورًا هامًا في نجاحه"، لكنها ليست معروفة على نطاق واسع خارج مجتمع الإنترنت. [ 6 ]

خارج نطاق مجتمع الإنترنت، تم نشر وثائق أخرى تسمى أيضًا طلبات التعليقات ، كما هو الحال في أعمال الحكومة الفيدرالية الأمريكية ، مثل الإدارة الوطنية لسلامة المرور على الطرق السريعة . [ 7 ]

تاريخ

بدأ استخدام صيغة RFC في عام 1969 كجزء من مشروع ARPANET الرائد . [ 6 ] واليوم، تُعدّ هذه الصيغة قناة النشر الرسمية لفرقة عمل هندسة الإنترنت (IETF)، ومجلس هندسة الإنترنت (IAB)، وإلى حد ما ، للمجتمع العالمي لباحثي شبكات الحاسوب بشكل عام.  

قام مؤلفو أولى وثائق طلب التعليقات (RFCs) بكتابة أعمالهم على الآلة الكاتبة وتوزيع نسخ ورقية منها على باحثي وكالة مشاريع الأبحاث المتقدمة (ARPA) . وخلافًا لوثائق طلب التعليقات الحديثة، كانت العديد من الوثائق المبكرة عبارة عن طلبات تعليقات فعلية، وقد سُميت بهذا الاسم لتجنب الأسلوب التقريري المفرط ولتشجيع النقاش. [ 8 ] [ 9 ] تترك وثيقة طلب التعليقات الأسئلة مفتوحة وتُكتب بأسلوب أقل رسمية. هذا الأسلوب الأقل رسمية هو الآن سمة مميزة لوثائق مسودات الإنترنت ، وهي الخطوة التمهيدية قبل اعتمادها كوثيقة طلب تعليقات.

في ديسمبر 1969، بدأ الباحثون بتوزيع وثائق RFC الجديدة عبر شبكة ARPANET التي تم تشغيلها حديثًا. وقد كتب ستيف كروكر من جامعة كاليفورنيا في لوس أنجلوس (UCLA) وثيقة RFC 1 ، بعنوان "برمجيات المضيف"، ونُشرت في 7 أبريل 1969. [ 10 ] وعلى الرغم من أن ستيف كروكر هو من كتبها، إلا أن وثيقة RFC انبثقت من نقاش مبكر لمجموعة عمل ضمت ستيف كروكر وستيف كار وجيف روليفسون . 

فيبدأ كروكر، في الوثيقة RFC 3 التي حددت سلسلة وثائق RFC لأول مرة، بنسب هذه السلسلة إلى فريق عمل الشبكة. وبدلاً من أن تكون لجنة رسمية، كانت عبارة عن رابطة غير رسمية من الباحثين المهتمين بمشروع ARPANET. وفي الواقع، شملت هذه الرابطة أي شخص يرغب في الانضمام إلى الاجتماعات والمناقشات المتعلقة بالمشروع. 

صدرت العديد من وثائق طلب التعليقات (RFCs) اللاحقة في سبعينيات القرن الماضي من جامعة كاليفورنيا في لوس أنجلوس (UCLA)، نظرًا لامتلاكها أحد أوائل معالجات رسائل الواجهة (IMPs) على شبكة أربانت (ARPANET). ويُعد مركز أبحاث التوسيع (ARC) في معهد ستانفورد للأبحاث ، بإدارة دوغلاس إنجلبارت ، أحد أوائل أربعة عقد في شبكة أربانت، ومصدرًا لوثائق طلب التعليقات المبكرة. وأصبح مركز أبحاث التوسيع أول مركز معلومات شبكي ( InterNIC )، والذي أدارته إليزابيث ج. فاينلر لتوزيع وثائق طلب التعليقات إلى جانب معلومات الشبكة الأخرى. [ 11 ]

في الأول من أبريل عام 1978، نُشرت وثيقة RFC 748 كمحاكاة ساخرة لأسلوب توثيق بروتوكول TCP/IP . واستؤنف هذا النهج في عام 1989 مع نشر وثيقة RFC 1097 ، التي تصف خيارًا لعملاء Telnet لعرض رسائل خفية . ومنذ ذلك الحين، تُنشر وثائق RFC أخرى في الأول من أبريل سنويًا، أبرزها RFC 2324 ، التي تصف بروتوكول التحكم في إبريق القهوة النصي التشعبي ( HTTP) وتُعرّف حالة HTTP 418 "أنا إبريق شاي". وتعود الوثائق RFC الفكاهية إلى RFC 439 ، التي نُشرت في يناير 1973.    

وظيفة محرر RFC

من عام 1969 حتى عام 1998، شغل جون بوستل منصب محرر RFC . وعند وفاته عام 1998، نُشر نعيه تحت عنوان RFC 2468. [ 12 ] 

بعد انتهاء عقد ARPANET الأصلي مع الحكومة الفيدرالية الأمريكية، تعاقدت جمعية الإنترنت، نيابةً عن فريق عمل هندسة الإنترنت (IETF)، مع قسم الشبكات في معهد علوم المعلومات بجامعة جنوب كاليفورنيا (USC /ISI) لتولي مسؤوليات التحرير والنشر تحت إشراف مجلس هندسة الإنترنت (IAB). انضمت ساندي جينوزا إلى USC/ISI عام 1999 للعمل على تحرير RFC، وانضمت إليها أليس هاغنز عام 2005. [ 13 ] تولى بوب برادن منصب قائد مشروع RFC، بينما استمرت جويس ك. رينولدز في العمل ضمن الفريق حتى 13 أكتوبر 2006.

في يوليو 2007، تم تحديد مسارات لوثائق طلب التعليقات (RFCs) لتقسيم مهام التحرير. كانت وثائق IETF تأتي من فرق عمل IETF أو من مساهمات برعاية مدير منطقة IETF من المجموعة التوجيهية لهندسة الإنترنت . ويحق لمجلس هندسة الإنترنت (IAB) نشر وثائقه الخاصة. ويأتي مسار بحثي من الوثائق من فرقة عمل أبحاث الإنترنت (IRTF)، ومسار مستقل من مصادر خارجية أخرى. [ 14 ] في عام 2008، تم اقتراح نموذج جديد، وتم تحسينه ونشره في أغسطس 2009، حيث تم تقسيم المهمة إلى عدة أدوار، [ 15 ] بما في ذلك المجموعة الاستشارية لسلسلة RFC (RSAG). تم تحديث النموذج في عامي 2012، [ 16 ] و2020. [ 17 ] كما تم تحسين المسارات في ديسمبر 2009، مع تحديد معايير لأسلوبها. [ 18 ] في يناير 2010، نُقلت وظيفة محرر RFC إلى شركة متعاقدة، وهي شركة حلول إدارة الجمعيات، مع تولي غلين كواك منصب محرر السلسلة مؤقتًا. [ 19 ] في أواخر عام 2011، تم تعيين هيذر فلانغان محررةً دائمةً لسلسلة طلبات التعليقات (RSE). وفي ذلك الوقت أيضاً، تم إنشاء لجنة الإشراف على سلسلة طلبات التعليقات (RSOC). [ 20 ]

في عام ٢٠٢٠، عقد مجلس هندسة الإنترنت (IAB) برنامج تطوير محرر طلبات التعليقات (RFC) لمناقشة التغييرات المحتملة على نموذج محرر طلبات التعليقات. وشملت نتائج البرنامج نموذج محرر طلبات التعليقات (الإصدار ٣) كما هو مُعرّف في RFC ٩٢٨٠ ، والذي نُشر في يونيو ٢٠٢٢. [ ١ ] يهدف النموذج الجديد عمومًا إلى توضيح المسؤوليات والعمليات المتعلقة بتحديد وتنفيذ السياسات الخاصة بسلسلة طلبات التعليقات ووظيفة محرر طلبات التعليقات. وشملت التغييرات في النموذج الجديد استحداث منصب محرر طلبات التعليقات الاستشاري، وفريق عمل سلسلة طلبات التعليقات (RSWG)، ومجلس اعتماد سلسلة طلبات التعليقات (RSAB). كما أنشأ مسارًا تحريريًا جديدًا لسلسلة طلبات التعليقات، وألغى لجنة مراجعة سلسلة طلبات التعليقات (RSOC). وتم تغيير دور محرر طلبات التعليقات (RSE) إلى محرر طلبات التعليقات الاستشاري (RSCE). وفي سبتمبر ٢٠٢٢، عُيّن أليكسيس روسي في هذا المنصب. [ ٢١ ] 

صيغة نشر جديدة

كانت طلبات التعليقات تُنتج في الأصل بتنسيق نص غير قابل لإعادة التدفق . وفي أغسطس 2019، تم تغيير التنسيق بحيث يمكن عرض المستندات الجديدة على النحو الأمثل على الأجهزة ذات أحجام الشاشات المختلفة. [ 22 ]

الإنتاج والإصدار

يُخصّص مُحرّر طلبات التعليقات (RFC) رقمًا تسلسليًا لكل طلب تعليقات . وبمجرد تخصيص رقم ونشر طلب التعليقات، لا يُلغى أو يُعدّل أبدًا؛ وإذا تطلّب المستند تعديلات، ينشر المؤلفون نسخة مُنقّحة. ولذلك، تحل بعض طلبات التعليقات محلّ طلبات أخرى؛ ويُقال إن طلبات التعليقات التي حلّت محلّها أصبحت مُهملة أو قديمة أو مُلغاة بسبب طلب التعليقات الذي حلّ محلّها. تُشكّل طلبات التعليقات المُسلسلة مجتمعةً سجلًا تاريخيًا مُستمرًا لتطور معايير وممارسات الإنترنت. عملية طلبات التعليقات موثقة في طلب التعليقات رقم 2026 ( عملية معايير الإنترنت، المراجعة 3 ). [ 23 ] 

تختلف عملية إنتاج طلبات التعليقات (RFCs) عن عملية التقييس لدى منظمات المعايير الرسمية مثل المنظمة الدولية للتوحيد القياسي (ISO). يمكن لخبراء تقنية الإنترنت تقديم مسودة إنترنت دون دعم من مؤسسة خارجية. تُنشر طلبات التعليقات (RFCs) الخاصة بمسار المعايير بموافقة فريق عمل هندسة الإنترنت (IETF)، وعادةً ما يُعدّها خبراء مشاركون في مجموعات عمل IETF ، التي تنشر أولًا مسودة إنترنت. يُسهّل هذا النهج جولات المراجعة الأولية من قِبل النظراء قبل أن تتحول الوثائق إلى طلبات تعليقات (RFCs). [ 24 ]

قد يكون لتقليد RFC المتمثل في صياغة المعايير بشكل عملي، قائم على الخبرة، وبعد وقوع الحدث، والذي يتم إنجازه بواسطة أفراد أو مجموعات عمل صغيرة، مزايا مهمة مقارنة بالعملية الرسمية التي تقودها اللجان والتي تتسم بها المنظمة الدولية للمعايير (ISO) وهيئات المعايير الوطنية. [ 25 ]

تستخدم معظم وثائق RFC مجموعة مشتركة من المصطلحات مثل "إلزامي" و"غير مُوصى به" (كما هو مُعرّف في RFC 2119 و 8174وصيغة باكوس-ناور المُعززة (ABNF) ( RFC 5234 ) كلغة وصفية، وتنسيق نصي بسيط، وذلك للحفاظ على اتساق وثائق RFC وسهولة فهمها. [ 23 ]  

سلسلة فرعية

تتضمن سلسلة RFC ثلاث سلاسل فرعية لـ IETF RFCs: BCP وFYI وSTD. تُعدّ أفضل الممارسات الحالية (BCP) سلسلة فرعية من RFCs الإلزامية لـ IETF غير المدرجة في مسار المعايير. أما For Your Information (FYI) فهي سلسلة فرعية من RFCs المعلوماتية التي تروج لها IETF كما هو محدد في RFC 1150 (FYI 1). في عام 2011، ألغى RFC 6360 سلسلة FYI 1 وأنهى هذه السلسلة الفرعية. كان Standard (STD) سابقًا المستوى الثالث والأعلى من حيث النضج في مسار معايير IETF المحدد في RFC 2026 (BCP 9). في عام 2011، قلّص RFC 6410 (جزء جديد من BCP 9) مسار المعايير إلى مستويين من حيث النضج.        

تيارات

توجد خمسة مسارات لطلبات التعليقات (RFCs): IETF ، و IRTF ، وIAB ، والتقديمات المستقلة ، [ 26 ] والتحريرية . تُعدّ IETF الجهة الوحيدة التي تُنشئ خطط العمل الأساسية (BCPs) وطلبات التعليقات (RFCs) ضمن مسار المعايير. ينشر IAB وثائق إعلامية تتعلق بالسياسات أو البنية. ينشر IRTF نتائج الأبحاث، إما كوثائق إعلامية أو كتجارب. تُنشر التقديمات المستقلة وفقًا لتقدير محرر التقديمات المستقلة. تُراجع مجموعة هندسة الإنترنت (IESG) الوثائق غير التابعة لـ IETF للتأكد من عدم وجود تعارض مع أعمال IETF. تحتوي طلبات التعليقات (RFCs) الصادرة عن IRTF والمستقلة عمومًا على معلومات أو تجارب ذات صلة بالإنترنت بشكل عام، ولا تتعارض مع أعمال IETF. قارن RFC 4846 و 5742 و 5744 . [ 27 ] [ 28 ] يُستخدم المسار التحريري لإجراء تغييرات في السياسة التحريرية عبر سلسلة طلبات التعليقات (RFC) (انظر RFC 9280 ). [ 1 ]   

الحصول على طلبات التعليقات

RFC 2046 أنواع الوسائط نوفمبر 1996 أ. قواعد اللغة المجمعة .................................... 43 1. مقدمة تحدد الوثيقة الأولى في هذه المجموعة، RFC 2045، عددًا من الترويسات الحقول، بما في ذلك نوع المحتوى. يُستخدم حقل نوع المحتوى لـ تحديد طبيعة البيانات في نص كيان MIME، عن طريق إعطاء معرفات نوع الوسائط ونوعها الفرعي، ومن خلال توفير مساعدات المعلومات التي قد تكون مطلوبة لأنواع معينة من الوسائط. بعد ذلك
RFC 2046 ، الذي يحدد نوع MIME النص/plain ، هو نفسه نص عادي. 

المصدر الرسمي لوثائق RFC على شبكة الإنترنت العالمية هو RFC Datatracker . يمكن استرجاع أي وثيقة RFC منشورة تقريبًا عبر عنوان URL بالصيغة التالية: https://datatracker.ietf.org/doc/html/rfc5000 ، كما هو موضح بالنسبة لـ RFC 5000 . 

يتم تقديم كل طلب تعليق (RFC) كنص ASCII عادي ويتم نشره بهذا الشكل، ولكنه قد يكون متاحًا أيضًا بتنسيقات أخرى .

لتسهيل الوصول إلى البيانات الوصفية لطلب التعليقات (RFC)، بما في ذلك الملخص والكلمات المفتاحية والمؤلف (المؤلفين) وتاريخ النشر والتصويبات والحالة، وخاصة التحديثات اللاحقة، يوفر موقع محرر طلبات التعليقات نموذج بحث مزود بالعديد من الميزات. يُحدد رابط إعادة التوجيه بعض المعايير الفعالة، على سبيل المثال: rfc:5000. [ 4 ]

الرقم التسلسلي الدولي القياسي الرسمي (ISSN) لسلسلة RFC هو 2070-1721. [ 18 ]

حالة

ليست جميع طلبات التعليقات (RFCs) معايير. [ 29 ] يُخصص لكل طلب تعليقات تصنيفٌ يتعلق بوضعه ضمن عملية توحيد معايير الإنترنت. ويكون هذا الوضع أحد التصنيفات التالية: معلوماتي ، تجريبي ، أفضل الممارسات الحالية ، مسار المعايير ، أو تاريخي . [ 4 ]

بمجرد تقديم طلب التعليقات (RFC) وقبوله ونشره، لا يمكن تعديله. يمكن تقديم تصحيحات، والتي تُنشر بشكل منفصل. أما التغييرات الأكثر أهمية فتتطلب تقديم طلب جديد يحصل على رقم تسلسلي جديد. [ 30 ]

مسار المعايير

وتنقسم وثائق مسار المعايير إلى وثائق المعايير المقترحة ووثائق معايير الإنترنت . [ 31 ]

لا يمكن الموافقة على طلبات التعليقات (RFCs) الخاصة بمسار المعايير إلا من قبل فريق هندسة الإنترنت (IETF)، الذي يمثله فريق توجيه هندسة الإنترنت (IESG) .

إذا أصبح طلب التعليقات (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     المعيار رقم 1 هو RFC 5000. اعتبارًا من ديسمبر 2013  تم استبدال RFC 5000 بـ RFC 7100 ، مما أدى إلى تحديث RFC 2026 بحيث لم يعد يستخدم STD 1.   

(تعمل أفضل الممارسات الحالية بطريقة مماثلة؛ يشير BCP n إلى RFC معين أو مجموعة من RFCs، ولكن قد يتغير RFC أو RFCs بمرور الوقت).

معلوماتي

يمكن أن تتضمن وثائق RFC المعلوماتية أي شيء تقريبًا، بدءًا من نكات الأول من أبريل وصولًا إلى وثائق RFC الأساسية والمعروفة على نطاق واسع، مثل بنية نظام أسماء النطاقات والتفويض ( RFC 1591 ). وقد شكلت بعض وثائق RFC المعلوماتية سلسلة فرعية تُعرف باسم "للعلم فقط" . 

تجريبي

يمكن أن يكون طلب التعليقات التجريبي وثيقة صادرة عن فريق هندسة الإنترنت (IETF) أو طلبًا فرديًا يُقدَّم إلى محرر طلبات التعليقات. يُصنَّف المسودة على أنها تجريبية إذا لم يكن واضحًا ما إذا كان الاقتراح سيعمل كما هو مُخطط له أو ما إذا كان سيحظى باعتماد واسع النطاق. قد يُنقل طلب التعليقات التجريبي إلى مسار المعايير إذا لاقى رواجًا وثبتت فعاليته. [ 33 ]

أفضل الممارسات الحالية

تجمع سلسلة " أفضل الممارسات الحالية" الوثائق الإدارية والنصوص الأخرى التي تُعتبر قواعد رسمية وليست مجرد معلوماتية ، ولكنها لا تؤثر على البيانات المنقولة عبر الشبكة . غالبًا ما يكون الحد الفاصل بين مسار المعايير ومسار أفضل الممارسات الحالية غير واضح. فإذا كانت الوثيقة تؤثر فقط على عملية معايير الإنترنت، مثل BCP 9 [ 34 ] أو إدارة IETF، فهي بلا شك مسار أفضل الممارسات الحالية. أما إذا كانت تحدد فقط القواعد واللوائح الخاصة بسجلات هيئة الأرقام المخصصة للإنترنت (IANA)، فالأمر أقل وضوحًا؛ فمعظم هذه الوثائق مسارات أفضل الممارسات الحالية، ولكن بعضها يندرج ضمن مسار المعايير.

تغطي سلسلة BCP أيضًا التوصيات الفنية حول كيفية تطبيق معايير الإنترنت؛ على سبيل المثال، التوصية باستخدام تصفية المصدر لجعل هجمات DoS أكثر صعوبة ( RFC 2827 : " تصفية دخول الشبكة: دحر هجمات الحرمان من الخدمة التي تستخدم انتحال عنوان IP المصدر ") هي BCP 38 . 

تاريخي

تُعرَّف وثيقة RFC التاريخية بأنها تلك التي لم يعد يُوصى باستخدام التقنية المُحدَّدة فيها، وهو ما يختلف عن قسم "مُهمل" في وثيقة RFC بديلة. على سبيل المثال، أصبحت وثيقة RFC 821 ( SMTP ) نفسها مُهملة من قِبل العديد من وثائق RFC الأحدث، لكن بروتوكول SMTP نفسه لا يزال يُعتبر "تقنية مُستخدمة حاليًا"، لذا فهو ليس في حالة "تاريخية". [ 35 ] ومع ذلك، نظرًا لأن الإصدار الرابع من بروتوكول BGP قد حلَّ محل الإصدارات السابقة منه تمامًا، فقد تم تصنيف وثائق RFC التي تصف تلك الإصدارات السابقة، مثل RFC 1267 ، على أنها تاريخية.  

مجهول

يُستخدم مصطلح "حالة غير معروفة" لبعض وثائق طلب التعليقات القديمة جدًا، حيث يكون من غير الواضح ما هي الحالة التي ستحصل عليها الوثيقة لو نُشرت اليوم. بعض هذه الوثائق لن تُنشر على الإطلاق اليوم؛ فغالبًا ما كانت وثائق طلب التعليقات المبكرة مجرد طلبات بسيطة للتعليقات، لا تهدف إلى تحديد بروتوكول أو إجراء إداري أو أي شيء آخر تُستخدم سلسلة وثائق طلب التعليقات لأجله اليوم. [ 36 ]

القاعدة العامة هي أن المؤلفين الأصليين (أو أصحاب عملهم، إذا نصت شروط عملهم على ذلك) يحتفظون بحقوق التأليف والنشر ما لم يقوموا بنقل صريح لحقوقهم. [ 37 ]

تحتفظ هيئة مستقلة، هي صندوق IETF Trust، بحقوق النشر لبعض وثائق RFC، بينما تُمنح ترخيصًا من مؤلفي الوثائق الأخرى يسمح لها بإعادة إنتاجها. [ 38 ] وقد ذُكرت جمعية الإنترنت في العديد من وثائق RFC السابقة لـ RFC4714 بصفتها مالكة حقوق النشر، إلا أنها نقلت حقوقها إلى صندوق IETF Trust. [ 39 ]

انظر أيضاً

مراجع

  1. 1 2 3 ب. سانت أندريه، محرر. (يونيو 2022). نموذج محرر RFC (الإصدار 3) . مجلس هندسة الإنترنت . doi : 10.17487/RFC9280 . ISSN 2070-1721 . RFC 9280 . للعلم فقط. تم إلغاؤه بموجب RFC 9920. تم تحديثه بموجب RFC 9720. يلغي RFC 8728. يُحدّث RFC 7841 و 8729 و 8730 .    
  2. "RFCs" . IETF . تم الاطلاع عليه في 5 نوفمبر 2023 .
  3. وايتزمان، ديفيد (1 أبريل 1990). معيار لنقل حزم بيانات بروتوكول الإنترنت على ناقلات الطيور . IETF . doi : 10.17487/RFC1149 . RFC 1149. تم الاطلاع عليه في 29 مارس 2017 .
  4. ١ ٢ ٣ سي. هويتيما ؛ ج. بوستل ؛ س. كروكر (أبريل ١٩٩٥). ليست كل طلبات التعليقات (RFCs) معايير . مجموعة عمل الشبكة. doi : 10.17487/RFC1796 . RFC 1796 .لأغراض إعلامية.
  5. "طلبات التعليقات على الإنترنت (RFC)" . Livinginternet.com . تم الاطلاع عليه في 3 أبريل 2012 .
  6. ١ ٢ "ستيفن د. كروكر، كيف حصل الإنترنت على قواعده ، صحيفة نيويورك تايمز، ٦ أبريل ٢٠٠٩" . صحيفة نيويورك تايمز . ٧ أبريل ٢٠٠٩. تم الاطلاع عليه في ٣ أبريل ٢٠١٢ .
  7. "إشعار وطلب للتعليقات" . السجل الفيدرالي . 16 يناير 2018.
  8. هافنر، كاتي؛ ليون، ماثيو (1996). حيث يسهر السحرة: أصول الإنترنت . كتاب من منشورات تاتشستون. سيمون وشوستر. ISBN 978-0-684-81201-4.
  9. ميتز، كيد (18 مايو 2012). "تعرّف على الرجل الذي اخترع تعليمات الإنترنت" . مجلة وايرد . تم الاطلاع عليه في 18 ديسمبر 2018 .
  10. إس. كروكر ، محرر. (7 أبريل 1969). برمجيات المضيف . مجموعة عمل الشبكة. doi : 10.17487/RFC0001 . RFC 1 .الحالة غير معروفة.
  11. إليزابيث ج. فاينلر (يوليو–سبتمبر 2010). "مركز معلومات الشبكة وأرشيفاته" . حوليات تاريخ الحوسبة . 32 (3): 83–89 . doi : 10.1109/MAHC.2010.54 . S2CID 206443021 . 
  12. ف. سيرف (17 أكتوبر 1998). أتذكر IANA . مجموعة عمل الشبكة. doi : 10.17487/RFC2468 . RFC 2468 .لأغراض إعلامية.
  13. ليزلي دايجل (مارس 2010). "محرر RFC في مرحلة انتقالية: الماضي والحاضر والمستقبل" . مجلة بروتوكول الإنترنت . المجلد 13، العدد 1. سيسكو سيستمز. مؤرشف من الأصل في 20 سبتمبر 2010. تم الاطلاع عليه في 17 أغسطس 2011 .  
  14. ل. دايجل، محرر (أبريل 2007). سلسلة RFC ومحرر RFC . مجموعة عمل الشبكة. doi : 10.17487/RFC4844 . RFC 4844 .قديم. تم إلغاؤه بموجب RFC 8729. تم تحديثه بموجب RFC 5741 .  
  15. ^ أو. كولكمان، أد. (أغسطس 2009). نموذج محرر RFC (الإصدار 1) . مجلس هندسة الإنترنت . دوى : 10.17487/RFC5620 . آر إف سي 5620 .قديم. تم إلغاؤه بموجب RFC 6635 و 6548 . 
  16. أ. كولكمان؛ ج. هالبرن، محرران (يونيو 2012). نموذج محرر RFC (الإصدار 2) . مجلس هندسة الإنترنت . doi : 10.17487/RFC6635 . RFC 6635 .مُلغى. تم إلغاؤه بموجب RFC 8728. يُلغي RFC 5620 .  
  17. أ. كولكمان؛ ج. هالبرن؛ ر. هيندن، محررون. (فبراير 2020). نموذج محرر RFC (الإصدار 2) . مجلس هندسة الإنترنت . doi : 10.17487/RFC8728 . RFC 8728 .للعلم فقط. تم إلغاؤه بموجب RFC 9280. يلغي RFC 6635 .  
  18. 1 2 أ. فالك (ديسمبر 2009). تدفقات RFC، والرؤوس، والقوالب . فريق عمل أبحاث الإنترنت . doi : 10.17487/RFC5741 . ISSN 2070-1721 . RFC 5741 . مُلغى. تم إلغاؤه بموجب RFC 7841. التحديثات RFC 2223 و 4844 .  
  19. غلين كواك (7 يناير 2010). "إعلان انتقال محرر طلبات التعليقات" . مؤرشف من الأصل في 29 يونيو 2011.
  20. "محرر سلسلة RFC وإعادة تنظيم السلسلة" . مؤرشف من الأصل في 5 أبريل 2013. تم الاطلاع عليه في 5 أبريل 2013 .
  21. "تعيين أليكسيس روسي محررًا استشاريًا لسلسلة RFC" . 1 سبتمبر 2022. تم الاطلاع عليه في 19 أغسطس 2023 .
  22. "أسئلة وأجوبة حول تغيير تنسيق RFC" . محرر RFC . 27 يناير 2021. مؤرشف من الأصل في 11 مايو 2026.
  23. 1 2 "فهرس RFC" . محرر RFC. 25 مايو 2008. تم الاسترجاع في 26 مايو 2008 .
  24. إرشادات وإجراءات مجموعة عمل IETF . IETF . doi : 10.17487/RFC2418 . RFC 2418 .
  25. تستند هذه المقالة إلى مواد مأخوذة من Request+for+Comments في Free On-line Dictionary of Computing قبل 1 نوفمبر 2008 وتم دمجها بموجب شروط "إعادة الترخيص" الخاصة بـ GFDL ، الإصدار 1.3 أو أحدث.
  26. "المساهمات المستقلة" . محرر RFC . تم الاطلاع عليه في 5 يناير 2018 .
  27. كلينسين، جون؛ ثالر، ديفيد (يوليو 2007). مساهمات مستقلة إلى محرر RFC . IAB . doi : 10.17487/RFC4846 . RFC 4846 .>
  28. ألفستراند، هارالد؛ هاوسلي، روس (ديسمبر 2009). إجراءات IESG للتعامل مع طلبات التدفق المستقلة وطلبات تدفق IRTF . IETF . doi : 10.17487/RFC5742 . RFC 5742 .
  29. "هل جميع وثائق RFC هي وثائق معايير الإنترنت؟" . محرر RFC . تم الاطلاع عليه بتاريخ 16 مارس 2018 .
  30. نوتنغهام، مارك (31 يوليو 2018). "كيفية قراءة RFC" . تم الاسترجاع في 18 سبتمبر 2023. RFCs عبارة عن سلسلة من الوثائق الأرشيفية؛ لا يمكن تغييرها.
  31. هاوسلي، راسل؛ كروكر، ديف؛ برجر، إريك (أكتوبر 2011). تقليص مسار المعايير إلى مستويين من النضج . IETF . doi : 10.17487/RFC6410 . RFC 6410 .
  32. إلغاء وثيقة ملخص "معايير بروتوكول الإنترنت الرسمية" . IETF . doi : 10.17487/RFC7100 . RFC 7100 .
  33. "7.5. RFCs المعلوماتية والتجريبية" . تاو IETF . تم الاطلاع عليه في 26 نوفمبر 2017 .
  34. برادنر، سكوت أو. (أكتوبر 1996). عملية معايير الإنترنت - المراجعة 3. IETF . BCP 9. تم الاطلاع عليه في 25 أكتوبر 2017 .
  35. "بيان مجموعة هندسة الإنترنت بشأن تصنيف طلبات التعليقات على أنها تاريخية" . فريق هندسة الإنترنت. 20 يوليو 2014. تم الاطلاع عليه في 14 أبريل 2016 .
  36. "معايير IETF مكتوبة من قِبل مساهمي ISC" . اتحاد أنظمة الإنترنت . 10 سبتمبر 2021. مؤرشف من الأصل في 5 أبريل 2022. تم الاطلاع عليه في 11 أبريل 2022. العديد من وثائق RFC المبكرة لها حالة "غير معروفة" لأنها تعود إلى حقبة ولّت منذ زمن بعيد، عندما كانت RFC مجرد طلب للتعليقات.
  37. "إعادة إنتاج RFCs" . IETF Trust . تم الاطلاع عليه بتاريخ 12 أغسطس 2021 .
  38. برادنر، سكوت؛ كونتريراس، خورخي (نوفمبر 2008). حقوق المساهمين المقدمة إلى صندوق IETF الاستئماني . IETF . doi : 10.17487/RFC5378 . RFC 5378 .
  39. "حقوق النشر وسياسات حقوق النشر الخاصة بـ IETF" . صندوق IETF . تم الاطلاع عليه بتاريخ 13 أغسطس 2021 .