الخلاصة

  • قسمت RFC 1 المسؤولية: حددت BBN برمجيات Interface Message Processor (IMP)، بينما كان على فرق المضيفات الاتفاق على البرمجيات التي تمكّن حواسيبهم من استخدام الشبكة.
  • وصف Steve Crocker ما كتبه بأنه مؤقت ودعا إلى إبداء الرأي. ثم شرحت RFC 3 أن القارئ قد يعد النص المكتوب ملزمًا لمجرد نشره، في حين أريد لسلسلة المذكرات أن تتيح مناقشة أفكار لم تكتسب بعد صفة المرجع المعتمد.
  • تكشف تعديلات RFC 6 وتنفيذ GORDO في UCLA كما تصفه RFC 11 والتغييرات اللاحقة في RFC 33 عن عمل متواصل. لكنها لا تثبت اعتماد جميع المضيفات RFC 1 من دون تعديل.

بقي الاتفاق الناقص فوق شبكة نقل الحزم

قام تصميم ARPA Network الأول على فصل تقني واضح. فقد حددت Bolt, Beranek and Newman برمجيات IMP، وهي الآلات التي تنقل الرسائل بين المواقع. أما الحواسيب المتصلة بها فاحتاجت إلى أعراف برمجية متفق عليها لفتح الاتصالات وتحديد الروابط ومعالجة البيانات الواردة من مضيف بعيد.

في 7 أبريل 1969، حاول Steve Crocker أن يجمع هذه المسألة بين المضيفات في وثيقة مشتركة. لخّصت RFC 1 صيغة رسائل IMP، ورسمت ملامح برمجيات المضيف اللازمة لطلبات الاتصال والجلسات الشبيهة بالطابعة الكاتبة ونقل الملفات الكبيرة وفحص الأخطاء والتفاعل عن بعد. كما ناقشت واجهة أمامية محلية تستطيع التعامل مع الاستجابات الفورية للطرفية من دون إرسال كل ضغطة مفتاح عبر الشبكة.

لم يكن الأمر قرارًا واحدًا يشمل كل طبقة. فتوجيه IMP للرسائل وسلوك نظام تشغيل المضيف يقعان في نطاقي مسؤولية مختلفين، ولكل منهما نمط إخفاق مختلف. قد تصل الرسالة إلى IMP المقصود، مع أن النظامين لا يعرفان بعد كيف يبدآن جلسة أو يفسران تبادل الرسائل.

تحدد مقدمة Crocker حالة الاقتراح بصراحة: توصلت المجموعة إلى بعض التفاهمات المؤقتة، وواجهت مسائل مفتوحة، ولم يكن كثير مما ورد محسومًا. وتنبع أهمية الوثيقة جزئيًا من احتفاظها بهذه المرحلة غير المستقرة. قراءتها كأنها مواصفة نهائية تمحو العمل الذي تسجله.

ما الذي طرحته المذكرة الأولى

نظمت RFC 1 التواصل عبر روابط منطقية بين كل زوج من المضيفات. واقترحت تخصيص رابط للتحكم بين نظامي التشغيل، واستخدام روابط أخرى لجلسات المستخدمين. وكان يمكن لاتصال أن يحاكي خط طابعة كاتبة، فيما يتيح اتصال موازٍ مخصص للملفات نقل أحجام أكبر من البيانات من دون الاعتماد على التخزين المؤقت ومقاطعات الطرفيات.

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

وكانت التجارب الأولى محدودة النطاق بدورها. وصف Crocker عمل SRI على نظام للاسترجاع وواجهة DEL، كما أشار إلى خطة لاستخدام NLS في UCLA وUtah. وهذا يدل على ما حاول المشاركون بناءه. لكنه ليس سجلًا لتركيب البرمجيات في كل موقع، ولا يثبت أن المضيفات الأربعة الأولى نفذت كل الاقتراحات.

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

جعلت السلسلة توثيق الخلاف أيسر

بعد يومين من RFC 1، كتب Bill Duvall المذكرة RFC 2، وكان عنوانها أيضًا «Host Software». ثم وضعت RFC 3 بعض أعراف التوثيق: يستطيع أي شخص في أي موقع إعداد مذكرة؛ والأولوية للتوقيت لا للصقل؛ ولا يشترط أن يكون العنوان فريدًا. وكان Bill Duvall في SRI يخصص الأرقام التسلسلية.

وسجلت RFC 3 مشكلة مألوفة حتى الآن في حوكمة التقنية: قد يظن القارئ أن العبارة المنشورة ذات سلطة لمجرد أنها كُتبت. وكان الهدف من الصيغة المرنة تشجيع تبادل أفكار لم تكتسب صفة الحجية. فالرقم التسلسلي يساعد على العثور على المذكرة؛ لكنه لا يحسم السؤال الذي تطرحه.

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

التعديل والتنفيذ نوعان مختلفان من الأدلة

سجلت RFC 6، وهي تدوين Crocker لمحادثة مع Bob Kahn في 10 أبريل، تعديلًا في حقل الرابط بين Host وIMP: أصبح الحقل خمسة بتات، مع بت إضافي للإشارة إلى التحويل. التفصيل صغير، لكن توقيته مهم: فبعد أيام فقط من RFC 1، ظل أحد عناصرها موضع نقاش وتعديل.

وفي أغسطس، وصفت RFC 11 التي كتبها Gerard Deloche إجراءات الاتصال بين المضيفات وتنفيذها في GORDO، نظام مشاركة الوقت لدى UCLA على SDS Sigma 7. وسجلت أنواع الاتصال ورسائل التحكم والمجاميع الاختبارية والمخازن والبرامج التي تمرر الرسائل بين المستخدمين وواجهة IMP. وفي الشهر نفسه، أحالت RFC 13 إلى RFC 11 واقترحت استخدام رسالة ذات طول صفري للدلالة على نهاية نقل ملف عبر اتصال مساعد.

توضح هذه السجلات انتقال الأفكار إلى تنفيذ محدد الاسم، ثم ظهور اقتراح مركز لمعالجة حاجة بعينها. لكنها لا تثبت أن جميع المضيفات استخدمت إجراءات GORDO أو أن تصميم الشبكة توقف عن التغير. التنفيذ الفعلي أقوى من الاقتراح لإثبات التشغيل في موقع واحد، لكنه لا يخبرنا بعدد المواقع التي اعتمدته.

وتوضح RFC 33 الفرق مباشرة. ففي فبراير 1970، ذكرت وجود تعديلات كثيرة مقارنة بالبروتوكول الأقدم في RFC 11، وربطتها باجتماع للشبكة في ديسمبر. وقالت إن الورقة المرفقة لا تتضمن معلومات تكفي لكتابة Network Control Program، وطلبت الردود. كانت الاتصالات قيد التشغيل والاستخدام قد بدأ، لكن بروتوكول المضيفات ظل موضع مراجعة وتوثيق.

أهمية RFC 1 لا تعني أنها الكلمة الأخيرة

لا تكمن أهمية RFC 1 التاريخية في بقاء كل حقل أو إجراء ورد فيها إلى الأبد. تكمن في جعل مشكلة تصميم مشتركة قابلة للنقاش قبل أن تتوافر لكل المضيفات تطبيقات مستقرة. فقد وزعت المسؤوليات، وقدمت خيارات، وأبقت مسائل الشك ظاهرة.

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

لذلك تتيح السجلات المبكرة رواية أدق عن نشأة التنسيق. حددت BBN طبقة IMP، وعالجت مجموعات المضيفات البرمجيات التي تعلوها، وقدمت RFC مساحة نقاش مرقمة قابلة للتداول. ثم وثقت التنفيذات والمذكرات اللاحقة ما جُرب وما تغير. بدأ الرقم الأول العملية، ولم ينهها.

المصادر

تعد RFC 1 المصدر الأساسي لمقترح Crocker المؤقت. وتسجل RFC 2 مذكرة Bill Duvall «Host Software»، بينما تشرح RFC 3 أعراف التوثيق الأولى. وتوثق RFC 6 مناقشة لاحقة لواجهة Host–IMP. وتصف RFC 11 لـDeloche الإجراءات وتنفيذ GORDO، وتقترح RFC 13 لـCerf علامة نهاية للنقل المساعد. وتسجل RFC 33 لـCrocker وزملائه تغييرات لاحقة ومسائل لم تحسم. ويقدم فهرس RFC 170 لعام 1971 قائمة بالمذكرات الأولى وتواريخها.