الخلاصة

  • لم تكتف RFC 920 بسرد أسماء المستوى الأعلى؛ بل ربطت كل فئة بمدير ووكيل تسجيل وشروط تفويض.
  • كان ARPA مؤقتًا صراحة. وشكّلت GOV وEDU وCOM وMIL وORG الفئات المؤسسية، بينما بقيت رموز البلدان والفئات متعددة المؤسسات احتمالات لم تُنشأ بعد.
  • كان تجاوز 500 مضيف توقعًا عامًا لنطاق المستوى الأعلى. أما تجاوز 50 مضيفًا في المستوى الثاني فكان إرشادًا مرنًا جدًا، وكان يمكن لمؤسسة كبيرة أن تُقبل بأقل من ذلك.

الاسم لم يكن يكفي للدخول

من السهل أن تُقرأ أسماء النطاقات الأولى بوصفها قائمة خيارات تقنية. لكن RFC 920، التي كتبها Jon Postel وJoyce Reynolds في أكتوبر 1984، كانت بيان سياسة رسميًا من Internet Activities Board وDARPA لإنشاء نطاقات في ARPA-Internet ومجتمع أبحاث DARPA. وهي لم تشرح شكل شجرة الأسماء فقط؛ بل حددت أنواع النطاقات الممكنة، ومن يديرها، وكيف يصل الطلب إلى مرحلة التفويض.

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

جمعت القائمة الأولى اسمًا مؤقتًا وفئات مؤسسية ونوعين لم يكن لهما نطاق قائم بعد:

الموقع في القائمة الأولى الاسم أو الفئة ما ورد في وثيقة 1984
مؤقت ARPA مضيفو ARPA-Internet في ذلك الوقت؛ وُصف الاسم بأنه مؤقت صراحة
فئات مؤسسية GOV وEDU وCOM وORG DARPA مدير، وNIC وكيل
فئة عسكرية MIL DDN-PMO مدير، وNIC وكيل
البلدان رموز ISO alpha-2 الإنجليزية المكوّنة من حرفين لم يكن أي نطاق لبلد قد أُنشئ بعد
مؤسسات متعددة لم يُحدد اسم بعد لم يكن أي نطاق من هذا النوع قائمًا؛ ويمكن النظر في مجموعة دولية لا تلائم الفئات الأخرى

لم تعنِ القائمة أن كل فرع كان مستخدمًا بالفعل. فقد قالت RFC 920 إن نطاقات البلدان والمؤسسات متعددة الأطراف لم تُنشأ بعد. كما لم توزع المسؤولية بالطريقة نفسها على الجميع: أدارت DARPA نطاقات ARPA وGOV وEDU وCOM وORG، وكان Network Information Center وكيلًا عنها؛ أما MIL فكان يديره DDN-PMO، مع قيام NIC بدور الوكيل والمسجل. لم يكن الاسم المعقول كافيًا لإنشاء نطاق أعلى؛ فالتفويض والتسجيل خطوتان صريحتان.

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

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

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

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

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

وتعرض RFC 1032، التي نُشرت عام 1987 كدليل لمديري النطاقات، مرحلة لاحقة. فهي تصف أدوار NIC في التسجيل وإدارة منطقة الجذر، وتذكر أن إدارات CSNET وUUCP كانت تراجع طلبات منظماتها قبل تمرير المعلومات إلى NIC. كما تتضمن قائمتها اللاحقة NET ونطاقات لبلدان. هذه لقطة من عام 1987، فلا ينبغي إسقاطها على القائمة الأولى لعام 1984 أو اعتبارها دليلًا على تنفيذ كل ما توقعته الوثيقة السابقة.

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

المصادر

رُوجعت الوثائق المجاورة التالية لتحديد نطاق المقال؛ ولا تُسقط حالتها اللاحقة على عام 1984.