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

ملخص

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

في 8 مارس 1974، طلب مركز معلومات الشبكة (NIC) من كل موقع من مواقع 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 على الملف وأدرج الإضافات أو التعديلات كل أسبوع. كان كل مضيف في الشبكة مسؤولاً عن استرداد المعلومات الجديدة عبر بروتوكول نقل الملفات. يمكن توجيه التعديلات والإضافات والتصحيحات والتعليقات إلى إليزابيث «Jake» فينلر عبر البريد الشبكي أو الهاتف أو من خلال نظام تعريف NIC.

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

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

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

في مارس 1974، أنشأت RFC 627 الملف المتاح، والإدراج الأسبوعي للتحديثات، وقناة التصحيح، ومسؤولية كل مضيف لاسترداد المعلومات الجديدة. لم يكن حتى عام 1982 أن صرحت RFC 810 صراحةً بأن مستخدم جدول مضيف DoD مسؤول عن ترجمته إلى التنسيق المحلي المطلوب. سيكون من غير الدقيق ضغط هذه التصريحات من 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للمضيف الذي يوفر جدول DoD وخدمة الأسماء. تشير هذه التسميات إلى تغييرات تقنية وتنظيمية؛ لا ينبغي التعامل معها كأسماء قابلة للتبديل لآلة لم تتغير.

حولت 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) تلقى عقدًا لتطوير وتشغيل مركز معلومات الشبكة لـ 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 الشبكة التشغيلية. كانت وزارة الدفاع هي البيئة الحكومية الأم؛ وكان لداربا و DCA وظائف مختلفة داخلها. ظل SRI متعاقدًا ينفذ خدمات NIC بدلاً من أن يصبح الحكومة نفسها. قامت المواقع الكيانات بتشغيل المضيفين. قام وكلاء اتصال المضيفين وأدوار الاتصال اللاحقة بنقل المعلومات والتعليمات. الحفاظ على تميز هذه الأدوار يمنع الخلط بين سلطة التعاقد والسلطة العالمية.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لم يحدد كل إدخال غير تابع لـ DoD تم تضمينه بالفعل ولا فرض نفس الشرط المسبق الصريح على جميع المشغلين الخارجيين.

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

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

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

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

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

في أوائل الثمانينيات، أصبح NIC مرتبطًا بشكل متزايد ببيئة شبكة البيانات الدفاعية، وتستخدم المجموعات التاريخية لاحقًا اسم DDN-NIC للخدمة. لا ينبغي إرجاع هذه التسمية اللاحقة إلى عقد 1969 أو نقاش اسم المضيف لعام 1971. تصف SRI-ARC و SRI NIC و 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 رفض الإدخالات دون تفسير ولا توجد مراجعة من الراعي، فإن نفس الملف سيحمل معنى حوكمة مختلفًا. لا تدعم الأدلة العامة أيًا من الطرفين كسرد عام.

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

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

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

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

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

توفر 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 و 608 الاقتراح وتصميم المصدر. وثقت RFC 620 و 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 جدول مضيف أوسع لإنترنت DoD ونشرت التسجيل المسبق كشرط للأسماء والعناوين المستخدمة فيما يتعلق بحركة المرور الموجهة بواسطة مضيفي DoD. معالجتها المؤقتة المنفصلة للمعلومات غير التابعة لـ DoD ميزت حدودًا. كانت القاعدة صريحة؛ يظل تنفيذها غير مثبت. أظهر التبديل من مايو إلى أغسطس أيضًا أن المواصفات والانتقال والتنفيذ المحلي المكتمل كانت خطوات مختلفة.

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

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

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

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

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

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

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

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