الخلاصة

  • وضع RFC 1394 أسماء البلدان والمناطق، وأكواد الهاتف، وأكواد telex، وإشارات answerback، ونطاقات Internet في جدول مؤرخ واحد. كان السطر يصف علاقة معروفة، لا خدمة عاملة.
  • لم يخفِ الدليل نقصه: ميّز بين نوعين من البيانات الغائبة، وحذر من احتمال خطأ بعض الأكواد، وطلب التصحيحات بالبريد والبريد الإلكتروني وtelex.
  • لم يثبت الرمز الصحيح تفويض DNS أو وجود دائرة مسموح بها أو هوية الطرف أو وصول الرسالة أو الاعتراف السياسي ببلد ما.

حمل كل عمود سلطة مختلفة

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

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

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

ظهر المجهول بدل أن يُملأ

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

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

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

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

لم ينشئ حرفان تفويضًا في DNS

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

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

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

والعكس غير صحيح أيضًا. استجابة ccTLD لا تحدث تلقائيًا رمز الهاتف أو telex المطبوع بجواره. لكل عمود مشغله وساعته.

تشابه اللاحقة مع النطاق لم يكن كافيًا

شرحت الملاحظات الخاصة بـ BITNET وUUCP حدًا آخر. استُخدمت أسماء مثل System.BITNET وhost.UUCP داخل مجتمعاتها، لكنها لم تكن أسماء مسجلة في DNS. احتاج البريد القادم من Internet إلى إعادة كتابة وتمرير عبر بوابة، وفق صيغة علامة النسبة المستخدمة آنذاك.

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

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

قد يوجد الرمز وتغيب الدائرة أو الإباحة

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

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

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

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

الإدراج لم يكن اعترافًا بدولة

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

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

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

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

أشار الدليل الرقيق إلى الشاهد التالي

لم يناقش RFC 1394 مسائل الأمن. لم يصادق على الصفوف، ولم يثبت الموافقة، ولم يضمن التسليم. لا يلغي ذلك فائدته، بل يمنع استعماله كوثيقة تفويض.

كانت مهمته أن يرتب الأسئلة: من يؤكد الرمز؟ هل اللاحقة مفوضة حقًا؟ أي خادم يجيب بسلطة؟ هل تعمل البوابة والطريق؟ هل الاستخدام مسموح؟ هل قبلت الوجهة الرسالة؟ لكل سؤال شاهد مختلف.

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