الخلاصة

  • فصلت RFC 897 بين جعل الاسم هرمياً وبين نقل حل الاسم من نسخة محلية لجدول مركزي إلى خوادم موزعة؛ لذلك أمكن للاسم المنتهي بـ.ARPA أن يبقى في HOSTS.TXT.
  • أبقت RFC 921 الجدول الزمني الأول مرئياً، وسجلت ما تم في موعده وما تأخر وما ظل غير منجز.
  • وجود الخوادم، وتحميل قاعدة البيانات، وتحويل المكتبة، واعتماد كل تطبيق، وإيقاف الجدول القديم كانت أدلة مستقلة وليست لحظة واحدة.

لم يكن النظام السابق خطوة واحدة أيضاً. وصفت RFC 810 جدول مضيفين مركزياً يديره NIC ويمكن تحويله آلياً. مع ذلك كان على كل موقع أن يحصل على الملف، ويحوّله إلى تمثيله المحلي، ثم يفعّله. وأتاحت RFC 811 خدمة Hostnames Server للسؤال عن سجل واحد أو استرجاع الجدول كله. صحة البيانات في المركز لم تكن دليلاً على النسخة التي قرأها تطبيق بعيد.

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

قدمت RFC 882 وRFC 883 بنية الأسماء والبيانات ذات الأنواع والمناطق والخوادم والإحالات والمحللات والذاكرات المؤقتة. كان ذلك عقداً للبروتوكول، لا إثباتاً بأن برنامج بريد بعينه توقف عن قراءة ملف محلي.

تغير الاسم قبل أن تتغير الآلة التي تجيب

في فبراير 1984 ميزت RFC 897 تغييرين. الأول نقل الأسماء من سلاسل مسطحة وفريدة عالمياً إلى بنية هرمية. والثاني نقل الترجمة من نسخ محلية لجدول كامل تديره جهة مركزية إلى استعلامات ديناميكية لخوادم يحمل كل منها جزءاً من القاعدة.

قسمت الخطة الانتقال إلى أربع خطوات: إضافة .ARPA إلى الاسم القديم، ثم فتح عدد قليل من النطاقات، ثم الانتقال من الجداول إلى الخوادم، ثم السماح بنطاقات كثيرة. وهكذا لم تكن النقطة داخل الاسم دليلاً على استدعاء DNS. أمكن للجدول القديم أن يحمل الصيغة الجديدة.

كان الاحتفاظ بالاسم القديم كلقب مؤقت يخفف الكسر عند المضيف الذي يقبل اللقب. لكنه لا يصلح دفتر عناوين بعيداً، ولا يغير حقول From أوTo أوCc في رسالة سابقة، ولا يحدث قائمة بريد يديرها طرف آخر. بعد نسخ الاسم خرج جزء من حالة الانتقال من سلطة المضيف الذي تغير اسمه.

وكان على القاعدة الموزعة أن تبقي القدرة على الوصول من العنوان إلى الاسم الأساسي. هذه خاصية اتساق بين إدارات متعددة، وليست مصادقة على الهوية ولا برهاناً على قابلية الوصول الحالية.

صيغة مشتركة والتزامان مختلفان

حددت RFC 897 تواريخ واضحة: اعتماد الأسماء الهرمية كأساسية في 14 مارس 1984، إنهاء الأسماء القديمة في 2 مايو، فتح النطاقات العامة متعددة المستويات في 6 يونيو، أسماء المؤسسات في 18 يوليو، الاستغناء عن الجدول الكامل لمجتمع أبحاث ARPA في 5 سبتمبر، وخطة DDN في 3 أكتوبر.

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

بذلك أمكن لاسمين حديثين في الشكل أن يعتمدا سلطتين مختلفتين للبيانات. وحدة مساحة الاسم لم تكن وحدة في التنفيذ.

حولت RFC 921 التأخير إلى سجل قابل للفحص

صدرت RFC 920 في أكتوبر بقواعد إنشاء نطاق جديد وبترتيب معدل للنطاقات العليا، مع أن RFC 897 توقعتها في فبراير. كانت سياسة الدخول نفسها تتشكل أثناء التنفيذ.

أبقت RFC 921 الخطة السابقة وأضافت النتيجة. أنجز جدول الأسماء الأول وتغيير الاسم الأساسي في مارس في الموعد. عملت خوادم ARPA، لكن في سبتمبر بدلاً من أبريل. أما جدول النطاقات العليا والنطاقات الجديدة والأسماء متعددة المستويات وأسماء المؤسسات وإيقاف جدول المضيفين وخطة DDN فلم تكن قد أنجزت.

ثم قسمت المراجعة العمل إلى ثلاث مراحل. machinery تعني الخوادم وresolvers. database تعني تثبيت البيانات. user programs تعني أن mailers وTelnet وFTP وغيرها تستخدم الإجراء الجديد فعلاً. في أكتوبر 1984 كانت الآلات متقدمة وكانت بيانات ARPA موجودة مع تهيئة لنطاقات أخرى، لكن تغيير برامج المستخدم ظل محدوداً.

امتدت المواعيد الجديدة إلى أكتوبر 1985. لم تكن ضماناً لما سيحدث. أهم ما قدمته الوثيقة تاريخياً هو توصيف الماضي بلا دمج: منجز، منجز متأخراً، أو غير منجز بعد.

وصل الانتقال المختلط إلى مستوى التطبيق

في 1987 وصفت RFC 1031 ثلاث حالات متزامنة في MILNET: الجدول وحده، الجدول وDNS معاً، وDNS وحده. كان من الممكن أن ينتقل Telnet وFTP قبل البريد أو يحدث العكس. لم يكن للمضيف الواحد بالضرورة وضع انتقال واحد.

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

وثقت RFC 1034 لاحقاً مشكلة توسيع توزيع HOSTS.TXT، وحافظت على واجهة resolver تشبه النداء القديم. سهلت هذه المطابقة تغيير المصدر من دون إعادة كتابة كل تطبيق، لكنها أخفت مصدر الإجابة عن المراقب الذي ينظر إلى الواجهة فقط.

وجمعت RFC 1401 مراسلات عام 1992 التي قال فيها IAB إن انتقال MILNET ظل غير مكتمل، وربط اختلاف خرائط الجدول وDNS بإخفاقات الوصول. هذه مراسلات ذات هدف سياسي وليست إحصاءً محايداً للتبني، لكنها توثق استمرار أثر المسار المنفصل لسنوات.

المصادر والحدود

يعتمد هذا السرد على RFC 810 و811 و881 و882 و883 و897 و920 و921 و1031 و1034 و1401. تثبت هذه الوثائق التصاميم والالتزامات والتواريخ والمراجعة والملاحظات المنسوبة. ولا تثبت يوماً عالمياً واحداً للانتقال، أو امتثال كل موقع، أو هوية موثقة، أو وصولاً حالياً، أو سلوك منتج معاصر.