جدول المضيف قبل السوق: من فوّض أول سجل إنترنت؟

الملخص

• اكتسب جدول المضيف المبكر سلطة عملية من خلال سلسلة محدودة: قامت ARPA بتوفير مركز معلومات الشبكة لـ ARPANET، وحافظت SRI على السجل المشترك، وقدمت المواقع المشاركة معلومات المضيف واستهلكتها، ثم قامت DCA لاحقًا بدمج الخدمة في بيئة تشغيلية تابعة لوزارة الدفاع.
• نشرت RFC 810 شرطًا مسبقًا للتسجيل للأسماء والعناوين المستخدمة فيما يتعلق بحركة المرور التي تمر عبر مضيفي وزارة الدفاع، لكن المواصفات الباقية لا تُظهر المراقبة، أو رفض الحزم، أو العقوبات، أو معدلات الامتثال، أو أي اتصال محظور بعينه.
• لا يوفر السجل العام العقود المبكرة الكاملة، أو ملفات طلبات جدول المضيف، أو القرارات المتنازع عليها، أو نتائج التصحيح، أو سجلات التجاوز، أو تقارير الإنفاذ، أو سبل الانتصاف اللازمة لإثبات إما صلاحية غير مقيدة لمركز معلومات الشبكة (NIC) أو تفويض عام يمتد إلى كل شبكة خارجية.

في 8 مارس 1974، طلب مركز معلومات الشبكة من كل موقع ARPANET تغيير جدول المضيف المحلي. ظهرت التعليمات فيRFC 620، "طلب تحديثات جداول مراقبة المضيف"، الصادرة عن بيل فيرغسون من مركز أبحاث التعزيز في SRI. كانت خدمات NIC قد انتقلت إلىOFFICE-1، في موقع الشبكة 53 بالترميز الثماني. بقي الموقع 2SRI-ARC، لكن لقبه أصبحARC؛ وأصبح اللقب المألوفNICيشير بدلاً من ذلك إلى الموقع 53. قدم الإشعار مدخلات دقيقة لجداول مراقبة TENEX وأخبر المواقع التي تشغل أنظمة تشغيل أخرى بإجراء تغييرات مكافئة.

تُسجل RFC 620 تعليمات، وليس حالة امتثال مرصودة. لا تحدد أي مشغل فردي يقوم بالعمل، ولا أي موقع فشل في القيام بذلك، ولا أي انقطاع ناتج. مع ذلك، فإن المشغل هو دور ضروري ينطوي عليه المستند: كان على شخص ما في كل موقع تغيير التعيين المستخدم محليًا بالطريقة المناسبة لنظام التشغيل ذاك. إذا بقي الجدول قديمًا، فسيستمر في ربطNICبالموقع 2 ويمكن أن يوجه محاولة مبنية على الاسم بعيدًا عن خدمة NIC المقصودة. تنتج هذه النتيجة عن تغيير التعيين، لكن RFC لا تبلغ عن فشل بحث فعلي أو اتصال موجّه بشكل خاطئ.

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

في 25 مارس 1974، أعلنتRFC 627عن آلية توزيع أكثر انتظامًا. كان ملف ASCII الإلكتروني لأسماء المضيف الرسمية متاحًا علىOFFICE-1، الذي ظهر عنوانه بـ 43 بالترميز العشري، مكافئًا لـ 53 الثماني المستخدم في RFC 620. كان NIC يحافظ على الملف ويدمج الإضافات أو التغييرات أسبوعيًا. كان كل مضيف شبكة مسؤولاً عن استرجاع المعلومات الجديدة من خلال بروتوكول نقل الملفات (FTP). وكان يمكن توجيه التغييرات والإضافات والتصحيحات والتعليقات إلى إليزابيث "جايك" فينلر عبر بريد الشبكة، أو الهاتف، أو نظام تعريف NIC.

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

في عام 1971، اختار مضيف اسمًا رسميًا مفضلاً من خلال منسقه بموجب الإجراء المقترح فيRFC 273. قام المنسق بنقل الاختيار؛ لا يثبت المستند أن المنسق الفني كان يمتلك شخصيًا سلطة اتخاذ كل قرار تنظيمي للموقع. توقع نظام التسمية المقترح أن تكون الألقاب فريدة داخل مجتمع الشبكة وتصور مناقشة إذا تم اختيار أسماء مكررة أو طويلة بشكل استثنائي. ولم يحدد حق النقض (الفيتو) لـ NIC، أو اختبار رفض، أو قاعدة قرار نهائي، أو تجاوز، أو استئناف.

في يناير 1974، وصفتRFC 608اسم المضيف الرسمي كسلسلة يتم الحصول عليها من خلال التفاوض بين المضيف و NIC. وضعت قيودًا على الأحرف والتنسيق، وحددت ملف مصدر NLS الخاص بفينلر، واقترحت توليدًا دوريًا لنسخة ASCII يمكن قراءتها آليًا. لم تشرح كيف انتهت المفاوضات المتنازع عليها أو من كان الغالب عندما فشلت المناقشة.

في مارس 1974، أنشأت RFC 627 الملف المتاح، ودمج التحديثات الأسبوعي، وقناة تصحيح، ومسؤولية كل مضيف عن جلب المعلومات الجديدة. فقط في عام 1982، نصتRFC 810صراحةً على أن مستخدم جدول مضيف وزارة الدفاع كان مسؤولاً عن ترجمته إلى أي تنسيق محلي مطلوب. سيكون من غير الدقيق ضغط تصريحات 1971 و 1974 و 1982 في روتين واحد مرصود أو إسناد كل خطوة إلى نفس المسؤول.

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

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

أربعة جداول متباينة والحجة لصالح ملف مشترك

عالج ملف المضيف الإلكتروني مشكلة تنسيق مرصودة. في ديسمبر 1973، وصفتRFC 606أربعة أنظمة TENEX يمكن الوصول إليها—SRI-ARC، وBBN-TENEX، وUSC-ISI، وPARC-MAXC—التي اختلفت تعييناتها بين أسماء المضيف والعناوين. لم يكن أي منها مكتملاً، ورأى المؤلف أن كل منها يختلف في بعض النواحي عن القائمة الرسمية.

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

اقترحت RFC 606 ملفًا مركزيًا مولّدًا، قابلًا للقراءة آليًا، يحتفظ به NIC. ميزت بين الحقيقتين الأساسيتين في الإدخال—اسم المضيف وعنوان المضيف—عن السمات الاختيارية مثل حالة المضيف، وسلوك البروتوكول، والألقاب. حذر مؤلفها من أن السمات قد لا تكون كاملة ويجب ألا تحل محل تفاوض البروتوكول، أو الكلام الشفهي، أو الطرق الأخرى لاكتشاف خصائص المضيف. كان الاقتراح محددًا عن عمد: سعى إلى حل القوائم المحلية غير المتوافقة، وليس إلى إنشاء دستور شامل للمشاركة في الشبكة.

قبلت RFC 608 فكرة الملف المركزي وذكرت أنها حظيت بدعم من مكتب تقنيات معالجة المعلومات في ARPA. حافظت فينلر على المصدر في تنسيق NLS الخاص بـ SRI، بينما كان هناك برنامج يولد ملف توزيع ASCII بشكل دوري. في البداية، كانت المدخلات المولّدة تحتوي على الاسم الرسمي، وعنوان المضيف العشري، والحالة. وكان يمكن إضافة معلومات أخرى عندما تصبح البيانات متاحة. كما سمحت الوثيقة أيضًا ببادئة شبكة للمضيفين خارج ARPANET، مما يظهر أن المؤلفين كانوا يتصورون بالفعل مجموعة مقارنة أوسع من مجموعة مضيفي ARPANET. لا تحدد كل مضيف خارجي تم تضمينه فعليًا.

كان التمييز بين المصدر والتوزيع مهمًا. كان NLS نظام SRI يُستخدم للحفاظ على المعلومات المهيكلة. صُممت نسخة ASCII للاسترجاع والمعالجة من قبل مضيفين غير متجانسين. كانت SRI-ARC السياق التنظيمي والحوسبي الذي صدرت منه العديد من هذه الإشعارات، بينما أصبحOFFICE-1الآلة التي تخدم مستخدمي NIC وملف المضيف المنشور في مارس 1974. استخدمت وثائق لاحقةSRI-NICللمضيف الذي يقدم جدول وزارة الدفاع وخدمة الأسماء. تمثل هذه التسميات تغييرات تقنية وتنظيمية؛ ولا ينبغي معاملتها كأسماء قابلة للتبادل لآلة واحدة غير متغيرة.

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

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

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

يوضح نقل مارس الافتراض الأضيق. بعد انتقالNICإلىOFFICE-1، فإن الموقع الذي نفذ تغيير RFC 620 سيربط اللقب بالموقع 53. ويمكن لموقع قديم أن يستمر في ربطه بالموقع 2. حدث نقل خدمة SRI بشكل مستقل عن الجدول البعيد، بينما اعتمدت فائدة اللقب المشترك على التبني عن بعد. كان السجل ذا أثر لأن الآلات الأخرى تصرفت بناءً عليه.

بدأت الأسماء من المضيفين، وليس من فيتو NIC غير محدود

لم ينبثق الملف المشترك من قاعدة مستقرة سمحت لـ NIC بتعيين أي اسم تشاء. تسجل مناقشة RFC لعام 1971 خلافًا كبيرًا حول التسمية.

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

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

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

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

فيRFC 289، الصادرة في ديسمبر 1971، ذكرت أن جميع المواقع تقريبًا ردت بأسماء مرغوبة. عنوانها، "ما نأمل أن يكون قائمة رسمية لأسماء المضيفين،" يحافظ على الطابع المؤقت للتمرين. عكست القائمة الناشئة الالتماس واستجابة الموقع داخل مجتمع ARPANET المحدود. لم تكن اختراعًا خاصًا أحادي الجانب ولا نتيجة تفويض عام عالمي.

يتطلب دور المنسق أيضًا عناية. استخدمت RFC 273 المنسقين كقناة يختار من خلالها المضيفون الأسماء ويتواصلون بها. يقولدليل متحف تاريخ الحاسوب لسجلات SRI ARC/NICلاحقًا إن المنسقين التقنيين لم تكن لديهم عمومًا سلطة التحدث باسم إدارة الموقع. يصف دليل الأرشيف الإنشاء اللاحق لدور مدير المضيف الذي يمكن لشاغله أن يأذن بإجراء الموقع. لأن الدليل يغطي فترة أطول، لا يمكن ببساطة إسقاطه إلى الوراء في كل تبادل عام 1971. ومع ذلك، فهو يحذر من معاملة "المنسق" كمرادف للمدير التنفيذي المؤسسي.

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

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

عقد خدمة ARPA وتسليم DCA

بدأت السلسلة المؤسسية ببرنامج بحث فيدرالي، وليس مع الإنترنت الأوسع.

كانت ARPANET شبكة تبديل رزم معينة أنشئت من خلال وكالة مشاريع البحوث المتقدمة (ARPA) داخل وزارة الدفاع الأمريكية. مولت ARPA برنامج البحث، واختارت المقاولين، ودعمت مراكز البحث المشاركة. أصبحت الوكالة وكالة مشاريع البحوث المتقدمة الدفاعية (DARPA) في عام 1972. لذا، فإن "ARPA" مناسب لإنشاء الشبكة والنقاش المبكر حول التسمية، بينما يظهر "DARPA" في سجلات الفترة اللاحقة.

يقولتقرير إكمال ARPANET، الذي أُعد في عام 1978، إن معهد ستانفورد للأبحاث (SRI) تلقى عقدًا لتطوير وتشغيل مركز معلومات الشبكة (NIC) لـ ARPANET. بدأ العمل بالتزامن مع تنفيذ الشبكة في عام 1969. يصف التقرير خدمة حافظت على قوائم المشاركين والتوزيع، وأرشفت الوثائق التقنية، وقدمت معلومات حول موارد المضيف، وأتاحت الوصول إلى نظام NLS الخاص بـ SRI، وحافظت على مواصفات بروتوكول ARPANET.

يؤسس هذا علاقة راعي-مقاول. قامت ARPA بشراء خدمة معلومات للشبكة ومجتمع البحث الذي تدعمه. كان على SRI واجب أداء ما يتطلبه العقد، وكان لـ ARPA الحق المقابل في الأداء المتعاقد عليه. لا يعيد التقرير العام إنتاج بيان العمل المبكر، أو التعديلات، أو معايير القبول، أو العقوبات، أو بنود البيانات، أو قواعد قرار اسم المضيف. لذا، لا يمكنه تحديد المحتوى القانوني الكامل لذلك الواجب.

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

أقوى حساب مباشر لنقل الإدارة من ARPA إلى وكالة اتصالات الدفاع (DCA) هو مُدرج ومؤرخ. يصف تقرير الإكمال مذكرة ARPA-DCA التي بموجبها انتقلت إدارة ARPANET إلى DCA في 1 يوليو 1975. كما يسجل مرحلة انتقالية مدتها ستة أشهر، استمرت حتى 31 ديسمبر 1975، استمرت خلالها ARPA في مساعدة DCA بينما تولت DCA دور الإدارة. كانت خطة انتقال مفصلة قد اكتملت بحلول يونيو.

يقول التقرير إن الشبكة المنقولة كانت ستعمل كمرفق تابع لوزارة الدفاع يُستخدم للأعمال الحكومية. وكانت DCA ستمول التشغيل والصيانة من خلال ترتيب توزيع تكاليف يشمل رعاة ARPANET. وكان على DCA في البداية أن تتعاقد مع BBN و SRI لتشغيل الشبكة، والصيانة، ووظائف NIC. يقول التقرير إنه كان مفهومًا بوضوح أن بإمكان DCA الاحتفاظ بمقاولين آخرين لاحقًا، بالتأكيد بعد السنة الأولى.

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

يعطي منشور لـ DCA من عام 1978 مفهرس باسمكتيب معلومات ARPANETأيضًا 1 يوليو 1975 كتاريخ لنقل الإدارة. يقدم دليل متحف تاريخ الحاسوب اللاحق سردًا استعاديًا متضاربًا: يقول إن تشغيل ARPANET تم تسليمه إلى DCA في عام 1973 وأن تمويل عقد DCA دعم NIC التابع لـ SRI بعد عام 1974.

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

بعد النقل الرسمي، كان بإمكان DARPA الاستمرار في رعاية الأبحاث التي تستخدم ARPANET بينما تدير DCA الشبكة التشغيلية. كانت وزارة الدفاع هي البيئة الحكومية الأم؛ وكان لـ DARPA و DCA وظائف مختلفة داخلها. بقيت SRI مقاولاً يؤدي خدمات NIC بدلاً من أن يصبح الحكومة نفسها. شغلت المواقع المشاركة مضيفين. نقل المنسقون وأدوار الاتصال اللاحقة المعلومات والتعليمات. إبقاء هذه الأدوار متميزة يمنع الخلط بين سلطة الشراء والسلطة الشاملة.

لم يكن القبول في ARPANET قرارًا خاصًا بجدول المضيف

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

وصفدليل ARPANET لشهر ديسمبر 1978فئات المشتركين وعملية الحصول على الخدمة. وضع إطاره القبول والرعاية ضمن هيكل إدارة الشبكة التابع لـ DCA. كان المشترك المحتمل بحاجة إلى غرض حكومي مقبول، ورعاية، وتسهيلات متاحة. تعلقت هذه القرارات بالوصول إلى شبكة مُدارة محددة.

التمييز أساسي. كان بإمكان DCA إدارة أهلية مشتركي ARPANET. وكان بإمكان SRI صيانة الدليل ومعلومات المضيف المستخدمة بعد أو حول القبول. قد يكون إدخال جدول المضيف ضروريًا للاستخدام المشترك المريح، لكن تسجيل المضيف لم يكن نفس الفعل المؤسسي مثل الموافقة على اتصال المنظمة، أو تركيب معالج رسائل الواجهة (IMP)، أو توفير دائرة، أو التصريح بمهمة.

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

بحلول سبتمبر 1981، أدرجتRFC 790أرقام شبكات الإنترنت المعينة لشبكات مسماة عديدة، بما في ذلك ARPANET، و UCLNET، و CYCLADES، و TELENET، و EPSS مكتب البريد البريطاني، و DATAPAC، و TRANSPAC، و LCSNET، و TYMNET، ومجموعة من أنظمة الراديو الرزمي، والأقمار الصناعية، والشبكات المحلية، والتجريبية. حددت جون بوستل في معهد علوم المعلومات بجامعة جنوب كاليفورنيا كجهة اتصال لتعيينات أرقام الشبكات.

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

كما أنها تفصل وظائف تطمسها التواريخ اللاحقة أحيانًا. تعلق دور بوستل في الأرقام المعينة في USC-ISI بأرقام الشبكات ومعلمات البروتوكولات. حافظت SRI على جدول المضيف وخدمة الأسماء. أدارت DCA شبكة ARPANET وكلفت خدمة NIC. واصلت DARPA رعاية البحث. لا شيء من هذه الحقائق يجعل فاعلاً واحدًا المؤلف الوحيد للإنترنت الناشئ بأكمله.

لذا، تحتاج عبارة "أول سجل إنترنت" إلى مقارنة محددة. لم يكن جدول المضيف أول دليل تحتفظ به منظمة حاسوبية على الإطلاق، ولا كان ملف 1974 سجلاً لإنترنت عام عالمي. كان مرجعًا مبكرًا مشتركًا، قابلًا للقراءة آليًا، للأسماء والعناوين في سلالة ARPANET إلى الإنترنت. بحلول عام 1982، أدرج تنسيقه اللاحق الشبكات، والبوابات، وعناوين الإنترنت ووصفه مشغّلوه بأنه قاعدة بيانات عالمية لأسماء وعناوين المضيفين. تكمن أهميته التاريخية في النطاق المتوسع والاعتماد عبر المؤسسات لذلك المرجع، وليس في تفويض مثبت على كل شبكة.

قاعدة وزارة الدفاع لعام 1982: شرط مسبق منشور، وليس إنفاذًا مثبتًا

شكلت RFC 810 تغييرًا في النطاق واللغة المؤسسية. صدرت في 1 مارس 1982 عن فينلر، وكين هارنستين، وزاو-سينغ سو، وفيك وايت من مركز معلومات الشبكة في SRI International، وقالت إن جدول مضيف ARPANET السابق لم يعد يلبي احتياجات مجتمع وزارة الدفاع أو التشبيك. تضمن التنسيق الجديد إدخالات للشبكات، والبوابات، والمضيفين، وعناوين الإنترنت، وأنظمة التشغيل، ومعلومات البروتوكول.

كان الجدول متاحًا من المضيفSRI-NICعبر FTP ومن خلال خادم أسماء المضيفين. حددت RFC الخادم كخدمة يحتفظ بها NIC التابع لـ ARPANET نيابة عن DCA. كما أسندت مسؤولية الترجمة صراحةً إلى المستخدم: أياً كان من يستهلك الجدول، كان عليه تحويله إلى التنسيق المطلوب محليًا.

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

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

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

كان للتنسيق الجديد أيضًا تقديم مرحلي. حددت RFC 810 الأول من مايو 1982 كتاريخ التحول. خلال مايو، كان مسارHOSTS.TXTالحالي لا يزال يحمل الطبعة القديمة بينما كان ملف اختبار بالتنسيق الجديد متاحًا بشكل منفصل. خلال يونيو ويوليو، احتوى المسار الرئيسي على التنسيق الجديد، بينما بقيت المواد بالتنسيق القديم متاحة عبر مسار آخر. بعد الأول من أغسطس، لن يكون تنسيقHOSTS.TXTالقديم المحدد في RFC 608 مدعومًا بعد الآن.

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

حددتRFC 811، الصادرة في نفس اليوم، خادم أسماء المضيفين الإلكتروني. كان بإمكان برنامج أن يستفسر عن اسم مضيف أو عنوان أو يطلب الجدول بأكمله. وكان بإمكان الخادم إرجاع سجلات مضيف، أو بوابة، أو شبكة. إذا كان الاسم المطلوب غائبًا، كان الخطأ المعرّف يأخذ الشكلERR: NAMNFD: Name not found:. كانت أخطاء أخرى ممكنة، بما في ذلكTMPSYS، التي تعني فشل نظام مؤقت وطلب بالمحاولة لاحقًا.

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

وصفت RFC 811 قاعدة بياناتها بأنها امتداد لملفHOSTS.TXTالقديم لـ ARPANET ووصفت الإدارة المركزية بأنها حل مؤقت في الطريق إلى خدمة ترجمة أسماء وعناوين لامركزية وموزعة. هذا الادعاء المؤسسي مهم لسببين. إنه يظهر أن SRI فهمت الخدمة كآلية انتقالية بدلاً من بنية دائمة، ويؤكد أن تعداد الجدول والغرض منه قد توسعا إلى ما وراء قائمة ARPANET الأصلية. لا يثبت بشكل مستقل تغطية شاملة.

بحلول أوائل الثمانينيات، كان NIC مرتبطًا بشكل متزايد ببيئة شبكة بيانات الدفاع (DDN)، واستخدمت المجموعات التاريخية لاحقًا اسم DDN-NIC للخدمة. لا ينبغي حمل هذه التسمية اللاحقة إلى الوراء في عقد 1969 أو نقاش اسم المضيف لعام 1971. تصف SRI-ARC، و NIC التابع لـ SRI، و SRI-NIC، و DDN-NIC سياقات تنظيمية ومضيفة متصلة لكن متميزة زمنيًا.

ما يمكن أن يظهره الأرشيف—وما يبقى مفقودًا

سلسلة RFC غنية بشكل غير عادي بالمقترحات والمواصفات والإعلانات. إنها أضعف بكثير كسجل للحالات الإدارية الفردية.

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

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

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

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

قام تحليل لاحق بكثيرلمكتب محاسبة الحكومة (GAO) لترتيبات وظائف الإنترنت الفيدراليةبالتمييز بعناية بين حقوق الأداء، وحقوق استخدام البيانات، وحق الملكية، والملكية. تعلق ذلك الرأي لعام 2016 بترتيبات DNS و IANA اللاحقة ولا يوفر الشروط المفقودة لعقود SRI في السبعينيات. قيمته هنا منهجية. التمويل الفيدرالي وحده لا يمكن استخدامه لاستنتاج كل حق ملكية أو نقل.

يدعم تقرير الإكمال استنتاجًا واحدًا أضيق: أن DCA كانت تنوي في البداية الإبقاء على SRI لوظيفة NIC وكان بإمكانها لاحقًا استخدام مقاول آخر. هذا يظهر قابلية استبدال المزود المتوخاة. لا يثبت أن الاستبدال كان يمكن أن يحدث دون تأخير، أو نزاعات على البيانات، أو تحويل برمجي، أو فقدان ذاكرة مؤسسية، أو انقطاع خدمة.

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

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

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

بديل القائمة المحلية وتكاليفه الحقيقية

لم يكن البديل الممكن تاريخيًا للملف المشترك هو نظام أسماء النطاقات الحديث (DNS). بل كان الممارسة المرئية بالفعل قبل RFC 606: كل موقع يحافظ على تعييناته الخاصة، ويحصل على التغييرات من خلال الاتصال الشخصي، ويترجم المعلومات البعيدة إلى نظام تشغيله الخاص.

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

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

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

تقدم RFC 606 التحذير المرصود: الأنظمة الأربعة المسماة TENEX كان لديها بالفعل جداول غير مكتملة ومتباينة. لا تحدد كمياً الإخفاقات التي تسببها تلك الاختلافات. يظهر التباين نفسه صيانة مكررة وإجابات غير متسقة.

قلل مصدر مشترك من ذلك العبء. يمكن للمضيف المتأثر توصيل المعلومات من خلال قناة واحدة معترف بها. ويمكن لـ SRI توليد طبعة واحدة. ويمكن للمواقع جلب نفس الملف ومقارنة حالتها المحلية بمرجع مؤرخ. وكان لدى مشغل دعم يحقق في تباين نقطة محورية يبدأ منها.

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

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

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

سجل مشترك مع أكثر من موزع واحد

كان بديل ثانٍ ممكن في تلك الفترة ليحافظ على ملف قانوني واحد مع توزيع التخزين والاسترجاع على نطاق أوسع.

ظهرت الفكرة في وثائق معاصرة. اقترحتRFC 623أن يحتفظ NIC بالسيد بينما يحافظ مضيف آخر على نسخة ثانوية محدثة بشكل متكرر. تطوع مؤلفها بـ UCSB واقترح مزامنة يومية. كان الغرض هو التوفر: إذا لم يستطع مضيف NIC تقديم الملف، يمكن للمستخدمين تجربة الثانوي.

قبلتRFC 625مبدأ أن أكثر من مضيف واحد يجب أن يحتفظ بنسخة ورحبت بـ UCSB كثانوي محتمل. اختلفت مع استبدال FTP ببروتوكول استرجاع مخصص. دعت RFC 627، التي صدرت لاحقًا في مارس، أي مضيف يرغب في الاحتفاظ بنسخة ثانوية للاتصال بـ NIC.

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

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

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

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

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

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

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

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

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

سلسلة سلطة مؤرخة، وليس تفويضًا عالميًا

بين عامي 1969 و 1983، تراكمت سلطة جدول المضيف من خلال سلسلة من العلاقات المختلفة.

في عام 1969، قامت ARPA بشراء مركز معلومات الشبكة لـ ARPANET. أنشأ ذلك عميلاً فيدراليًا، ومقاولاً هو SRI، ومجتمع خدمة محدد. لم يجعل SRI ممثلاً لكل شبكة حاسوبية.

في عام 1971، تمت دعوة المضيفين لاختيار أسماء من خلال المنسقين ضمن اصطلاحات منشورة. قدم النقاش والاستجابة بين مشاركي ARPANET قبولاً محدودًا من الأقران. تم تضييق دور NIC المقترح بالاختيار المحلي، بينما كان فضاء الأسماء المشترك لا يزال يتطلب نتائج متوافقة.

في عام 1973 وأوائل 1974، دفعت الجداول المحلية المتباينة إلى ملف مشترك قابل للقراءة آليًا. وثقت RFC 606 و RFC 608 الاقتراح وتصميم المصدر. وثقت RFC 620 و RFC 627 تعليمات تغيير محددة على مستوى الموقع، وملف ASCII المتاح، والتحديثات الأسبوعية، ومسؤولية الاسترجاع المحلي، وقنوات التصحيح. لم توثق حق نقض عام لـ NIC أو نظام نزاعات كامل.

في 1 يوليو 1975، وفقًا لمذكرة ARPA-DCA الموصوفة في تقرير الإكمال، انتقلت إدارة ARPANET إلى DCA، تلاها انتقال تدريجي حتى 31 ديسمبر. احتفظت DCA بـ SRI في البداية لوظائف NIC وكان بإمكانها التفكير في مقاول آخر. بقي بيان النقل التشغيلي لعام 1973 في دليل الأرشيف وحساب التمويل لما بعد 1974 دون حل.

بحلول عام 1978، وضع إطار المشتركين لـ DCA قبول ARPANET ضمن إدارة الشبكة الحكومية بدلاً من صيانة جدول مضيف SRI. فصل هذا سلطة قبول مشترك عن الخدمة التي سجلت ووزعت معلومات المضيف.

بحلول عام 1981، أدرجت بيئة الأرقام المعينة شبكات عديدة خارج ARPANET، بينما تم تحديد تعيين رقم الشبكة مع بوستل في USC-ISI. لم يثبت الظهور في تلك القائمة أن كل شبكة شاركت علاقة قانونية أو تشغيلية واحدة مع DCA أو NIC.

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

جعل خادم RFC 811 الإجابة المُصانة متاحة من خلال استعلامات على الخط ووصف قاعدة البيانات المركزية كجسر مؤقت إلى التسمية الموزعة. زادت تلك الخدمة الاعتماد على SRI-NIC مع الاعتراف بأن البنية لم تكن مقصودة أن تبقى مركزية بشكل دائم.

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

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

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

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

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

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

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