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

من ويكيبيديا، الموسوعة الحرة
اذهب إلى الملاحة اذهب للبحث

و طلب التعليقات ( RFC ) هو نشر مرقمة بشكل فردي في سلسلة من واحدة من مجموعة صغيرة من الهيئات، وأبرزها قوة هندسة الإنترنت المهام (IETF)، وتطوير التقنية الرئيسية وهيئات وضع المعايير ل شبكة الإنترنت .

تم تأليف RFC بواسطة أفراد أو مجموعات من المهندسين وعلماء الكمبيوتر في شكل مذكرة تصف الأساليب أو السلوكيات أو الأبحاث أو الابتكارات المطبقة على عمل الإنترنت والأنظمة المتصلة بالإنترنت. يتم تقديمه إما لمراجعة الأقران أو لنقل مفاهيم أو معلومات جديدة أو أحيانًا دعابة هندسية. [1] تتبنى IETF بعض المقترحات المنشورة باعتبارها RFCs كمعايير للإنترنت . ومع ذلك ، فإن العديد من طلبات التعليقات ذات طبيعة إعلامية أو تجريبية وليست معايير. [2] اخترع ستيف كروكر نظام RFC في عام 1969 للمساعدة في تسجيل الملاحظات غير الرسمية حول تطوير ARPANET. وأصبحت المراجع منذ ثائق رسمية من الإنترنت المواصفات ، بروتوكولات الاتصالات والإجراءات والأحداث. [3] وفقًا لما ذكره كروكر ، فإن الوثائق "تشكل الأعمال الداخلية للإنترنت ولعبت دورًا مهمًا في نجاحها" ، ولكنها غير معروفة جيدًا خارج المجتمع. [4]

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

التاريخ

حدثت بداية تنسيق RFC في عام 1969 كجزء من مشروع ARPANET الأساسي . [4] وهي اليوم قناة النشر الرسمية لفريق عمل هندسة الإنترنت (IETF) ، ومجلس هندسة الإنترنت (IAB) ، وإلى حد ما - المجتمع العالمي لباحثي شبكات الكمبيوتر بشكل عام.

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

في ديسمبر 1969 ، بدأ الباحثون في توزيع RFCs الجديدة عبر ARPANET الذي تم تشغيله حديثًا. RFC  1 ، بعنوان "Host Software" ، كتبه Steve Crocker من جامعة كاليفورنيا ، لوس أنجلوس (UCLA) ، ونُشر في 7 أبريل 1969. [8] على الرغم من كتابته بواسطة Steve Crocker ، إلا أن RFC ظهر منذ وقت مبكر مناقشة مجموعة العمل بين ستيف كروكر وستيف كار وجيف روليفسون .

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

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

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

في يوليو 2007 ، تم تحديد تدفقات RFCs ، بحيث يمكن تقسيم مهام التحرير. جاءت مستندات IETF من مجموعات عمل IETF أو التقديمات التي يرعاها مدير منطقة IETF من مجموعة توجيه هندسة الإنترنت . يمكن لـ IAB نشر مستنداته الخاصة. يأتي تيار البحث من الوثائق من فريق عمل أبحاث الإنترنت (IRTF) ، ومن مصادر خارجية أخرى. [11] تم اقتراح نموذج جديد في عام 2008 ، وتم تنقيحه ونشره في أغسطس 2009 ، حيث قسم المهمة إلى عدة أدوار ، [12] بما في ذلك المجموعة الاستشارية لسلسلة RFC (RSAG). تم تحديث النموذج في عام 2012. [13]تم تنقيح التدفقات أيضًا في ديسمبر 2009 ، مع تحديد معايير لأسلوبها. [14] في يناير 2010 ، تم نقل وظيفة محرر RFC إلى مقاول ، Association Management Solutions ، مع عمل Glenn Kowack كمحرر مؤقت للسلسلة. [15] في أواخر عام 2011 ، تم تعيين هيذر فلاناغان كمحرر دائم لسلسلة RFC. في ذلك الوقت أيضًا ، تم إنشاء لجنة الإشراف على سلسلة RFC (RSOC). [16]

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

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

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

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

يمكن أن يكون لتقليد RFC المتمثل في تأليف المعايير الواقعية والقائمة على الخبرة والذي ينجزه الأفراد أو مجموعات العمل الصغيرة مزايا مهمة [ التوضيح مطلوب ] على العملية الأكثر رسمية التي تقودها اللجنة النموذجية لـ ISO وهيئات المعايير الوطنية. [ بحاجة لمصدر ]

تستخدم معظم طلبات التعليقات (RFCs) مجموعة شائعة من المصطلحات مثل "MUST" و "NOT RECOMMENDED" (على النحو المحدد في RFC 2119 و RFC 8174) ، ونموذج Backus – Naur المعزز (ABNF) (RFC 5234) كلغة وصفية ونص بسيط -تنسيق قائم على أساس الحفاظ على تناسق RFCs وسهولة فهمها. [18]

سلسلة فرعية

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

تيارات

هناك أربعة تيارات المراجع: IETF ، IRTF ، IAB ، و تقديم مستقل . [19] فقط IETF ينشئ BCPs و RFCs على مسار المعايير. و تقديم مستقلة محددا من قبل IESG لليتعارض مع عمل IETF. يتم تقييم الجودة من قبل هيئة تحرير مستقلة . بعبارة أخرى ، من المفترض أن يحتوي IRTF و RFCs المستقلة  على معلومات أو تجارب ذات صلة للإنترنت بشكل عام لا يتعارض مع عمل IETF ؛ قارن RFC 4846 و RFC 5742 و RFC 5744. [ بحاجة لمصدر ]

الحصول على RFCs 

أنواع وسائط RFC 2046 ، نوفمبر 1996


   أ. قواعد مجمعة .................................... 43

1 المقدمة

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

المصدر الرسمي لـ RFCs على شبكة الويب العالمية هو محرر RFC . يمكن استرداد أي RFC منشور تقريبًا عبر عنوان URL للنموذج http://www.rfc-editor.org/rfc/rfc5000.txt ، المعروض لـ RFC 5000.

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

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

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

الحالة

ليست كل طلبات التعليقات هي معايير. [20] [21] يتم تعيين تعيين لكل RFC فيما يتعلق بالحالة داخل عملية توحيد الإنترنت. هذه الحالة هي إحدى الحالات التالية: معلوماتية أو تجريبية أو أفضل الممارسات الحالية أو مسار المعايير أو تاريخية .

كل RFC ثابت ؛ إذا تم تغيير المستند ، يتم إرساله مرة أخرى وتعيين رقم RFC جديد. [ بحاجة لمصدر ]

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

وتنقسم الوثائق المعايير المسار الى مزيد من المعيار المقترح و الإنترنت ستاندرد الوثائق. [22]

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

إذا أصبح RFC معيار إنترنت (STD) ، يتم تعيين رقم STD له ولكنه يحتفظ برقم RFC الخاص به. القائمة النهائية لمعايير الإنترنت هي معايير بروتوكول الإنترنت الرسمية. تم استخدام STD 1 سابقًا للاحتفاظ بلقطة من القائمة. [23]

عند تحديث معيار الإنترنت ، يظل رقمه STD كما هو ، ويشير الآن إلى RFC جديد أو مجموعة من RFCs. قد يكون معيار الإنترنت المحدد ، STD n ، هو RFCs 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 معين أو مجموعة من RFCs ، ولكن قد تتغير RFC أو RFC بمرور الوقت).

إعلامي

و المعلوماتي RFC يمكن أن يكون أي شيء يقرب من 1 أبريل النكات على المراجع الأساسية المعترف بها على نطاق واسع مثل نظام اسم المجال الهيكل ووفد (RFC 1591). شكلت بعض RFCs المعلوماتية سلسلة فرعية لمعلوماتك .

تجريبية

و التجريبية RFC يمكن أن يكون وثيقة IETF أو تقديم الفردي إلى محرر RFC. تعتبر المسودة تجريبية إذا كان من غير الواضح أن الاقتراح سيعمل على النحو المنشود أو من غير الواضح ما إذا كان سيتم اعتماد الاقتراح على نطاق واسع. يمكن ترقية RFC التجريبية إلى مسار المعايير إذا أصبحت شائعة وتعمل بشكل جيد. [24]

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

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

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

التاريخية

A التاريخي RFC واحد هو أن التكنولوجيا التي حددها RFC لم يعد ينصح للاستخدام، والذي يختلف عن رأس "Obsoletes" في RFC الاستبدال. على سبيل المثال ، RFC 821 ( SMTP ) نفسها قد عفا عليها الزمن من قبل العديد من RFCs الأحدث ، لكن SMTP نفسها لا تزال "تقنية حالية" ، لذلك فهي ليست في حالة "تاريخية". [26] ومع ذلك ، نظرًا لأن BGP الإصدار 4 قد حل بالكامل محل إصدارات BGP السابقة ، فإن RFCs التي تصف تلك الإصدارات السابقة ، مثل RFC 1267 ، تم تصنيفها على أنها تاريخية.

غير معروف

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

حقوق النشر

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

تمتلك هيئة مستقلة ، IETF Trust ، حقوق الطبع والنشر لبعض طلبات التعليقات (RFCs) وبالنسبة لجميع الآخرين ، يتم منحها ترخيصًا من قبل المؤلفين يسمح لها بإعادة إنتاج طلبات التعليقات (RFC). [28] تمت الإشارة إلى جمعية الإنترنت في العديد من طلبات التعليقات (RFCs) قبل RFC4714 باعتبارها مالك حقوق النشر ، ولكنها نقلت حقوقها إلى IETF Trust. [29]

انظر أيضا

المراجع

  1. ^ وايتزمان ، ديفيد (1 أبريل 1990). معيار لإرسال مخططات بيانات IP على ناقلات الطيور . IETF . دوى : 10.17487 / RFC1149 . RFC 1149 . تم الاسترجاع 29 مارس ، 2017 .
  2. ^ هيتيما ، كريستيان ؛ بوستل ، جون ؛ كروكر ، ستيف (أبريل 1995). ليست كل طلبات التعليقات هي معايير . IETF . دوى : 10.17487 / RFC1796 . RFC 1796 . تم الاسترجاع 15 مايو ، 2018 .
  3. ^ "RFC's ، طلب الإنترنت للتعليقات" . Livinginternet.com . تم الاسترجاع 3 أبريل ، 2012 .
  4. ^ أ ب "ستيفن دي كروكر ، كيف حصلت الإنترنت على قواعدها ، نيويورك تايمز ، 6 أبريل 2009" . Nytimes.com . 7 أبريل 2009 . تم الاسترجاع 3 أبريل ، 2012 .
  5. ^ إشعار وطلب التعليقات ، في Federal Register (16 يناير 2018).
  6. ^ هافنر ، كاتي ؛ ليون ، ماثيو (1996). حيث يبقى السحرة متأخرين: أصول الإنترنت.
  7. ^ ميتز ، كادي (18 مايو 2012). "تعرف على الرجل الذي اخترع التعليمات للإنترنت" . سلكي . تم الاسترجاع 18 ديسمبر 2018 .
  8. ^ كروكر ، ستيف (7 أبريل 1969). "RFC 1" .  يتطلب الاستشهاد بمجلة |journal=( مساعدة )
  9. ^ إليزابيث ج.فينلر (يوليو-سبتمبر 2010). "مركز معلومات الشبكة ومحفوظاته". حوليات تاريخ الحوسبة . 32 (3): 83-89. دوى : 10.1109 / MAHC.2010.54.007 . S2CID 206443021 . 
  10. ^ ليزلي دايجل (مارس 2010). "محرر RFC في الانتقال: الماضي والحاضر والمستقبل" . مجلة بروتوكول الإنترنت . 13 (1). أنظمة سيسكو . تم الاسترجاع 17 أغسطس ، 2011 .
  11. ^ ديجل ، ليزلي (يوليو 2007). سلسلة RFC ومحرر RFC . IETF . دوى : 10.17487 / RFC4844 . RFC 4844 .
  12. ^ كولكمان ، أولاف (أغسطس 2009). نموذج محرر RFC (الإصدار 1) . IETF . دوى : 10.17487 / RFC5620 . RFC 5620 .
  13. ^ كولكمان ، أولاف. هالبيرن ، جويل (يونيو 2012). نموذج محرر RFC (الإصدار 2) . IETF . دوى : 10.17487 / RFC6635 . RFC 6635 .
  14. ^ أ ب دايجل ، ليزلي ؛ كولكمان ، أولاف (ديسمبر 2009). RFC Streams ، Headers and Boilerplates . IETF . دوى : 10.17487 / RFC5741 . RFC 5741 .
  15. ^ جلين كواك (7 يناير 2010). "إعلان انتقال محرر RFC" . مؤرشفة من الأصلي في 29 حزيران 2011.
  16. ^ محرر RFC. "محرر سلسلة RFC وإعادة تنظيم السلسلة" . تم الاسترجاع 5 أبريل ، 2013 .
  17. ^ الأسئلة الشائعة حول تغيير تنسيق RFC
  18. ^ أ ب " مؤشر RFC " . محرر RFC. 25 مايو 2008 . تم الاسترجاع 26 مايو ، 2008 .
  19. ^ "الطلبات المستقلة" . محرر RFC . تم الاسترجاع 5 يناير ، 2018 .
  20. ^ "هل كافة مستندات معايير الإنترنت الخاصة بـ RFCs؟" . محرر RFC . تم الاسترجاع 16 مارس ، 2018 .
  21. ^ هيتيما ، كريستيان ؛ بوستل ، جون ؛ كروكر ، ستيف (أبريل 1995). ليست كل طلبات التعليقات هي معايير . IETF . دوى : 10.17487 / RFC1796 . RFC 1796 . ... كل RFC له حالة ...: مسار إعلامي أو تجريبي أو معايير (معيار مقترح أو مسودة قياسية أو معيار إنترنت) أو تاريخي.
  22. ^ هوسلي ، راسل ؛ ديف كروكر. برجر ، إريك (أكتوبر 2011). تخفيض مسار المعايير إلى مستويين من النضج . IETF . دوى : 10.17487 / RFC6410 . RFC 6410 .
  23. ^ RFC 7100 تقاعد وثيقة ملخص "معايير بروتوكول الإنترنت الرسمية"
  24. ^ "7.5. المعلوماتية والتجريبية RFCs" ، Tao of IETF ، استرجاعها 26 نوفمبر ، 2017
  25. ^ برادنر ، سكوت أو. (أكتوبر 1996). عملية معايير الإنترنت - المراجعة 3 . IETF . BCP 9 . تم الاسترجاع 25 أكتوبر ، 2017 .
  26. ^ "بيان IESG حول تعيين RFCs على أنها تاريخية" . IETF. 20 يوليو 2014 . تم الاسترجاع 14 أبريل ، 2016 .
  27. ^ "إعادة إنتاج RFCs" . ثقة IETF . تم الاسترجاع 12 أغسطس ، 2021 .
  28. ^ برادنر ، سكوت ؛ كونتريراس ، خورخي (نوفمبر 2008). يقدم المساهمون في الحقوق إلى صندوق IETF . IETF . دوى : 10.17487 / RFC5378 . RFC 5378 .
  29. ^ "إعادة إنتاج RFCs" . ثقة IETF . تم الاسترجاع 13 أغسطس ، 2021 .

روابط خارجية

تم الاسترجاع من " https://en.wikipedia.org/w/index.php؟title=Request_for_Comments&oldid=1049164023 "
0.095598936080933