الخلاصة

  • جعلت RFC 3017 «دليل الهاتف» حزمة إعداد: رقم POP ووسيطه ونفقه ونص الاتصال وDNS والوكلاء والبوابة والبادئة أو اللاحقة التي يضيفها العميل إلى اسم المستخدم.
  • كان عداد الكتاب وعداد المدخل إشارة إلى تغير داخل نطاق معروف، لا توقيعاً ولا ساعة عالمية ولا إيصالاً لتطبيق ذري أو لاتصال ناجح.

وجد المسافر نسختين. حملت الأولى الرقم 41، والثانية 73. بدا الاختيار حسابياً: الرقم الأكبر أحدث.

لكن الدليل لم يكن بالضرورة كتاباً واحداً ذا خط نسخ واحد. توقعت RFC 3017 أن يوزع اتحاد التجوال إصدارات مختلفة على مجموعات مختلفة، وأن يستخرج المستخدم مجموعة فرعية لبلد أو وسيط معين. وكان name في phoneBook سلسلة اعتباطية. لذلك لا تصبح 73 أحدث من 41 إلا بعد معرفة الناشر والجمهور والنسخة الأساسية.

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

كان اسمه دليلاً، لكن البرنامج كان يستطيع تنفيذه.

جمع الاتحاد البيانات ولم يلغ اختلاف مصادرها

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

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

سلامة XML في نهاية السلسلة لم تثبت أن كل مساهمة بقيت حديثة خلال المرور بها.

ازداد العداد من دون أن يعرّف معاملة التحديث

كان على phoneBook@version أن يزداد عند تعديل الدليل. يمكن للخادم مقارنة رقم العميل برقمه، ثم يرسل مثلاً URL لملف فروق.

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

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

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

وحمل كل pop عداد entryVersion يمكن أن يفيد الدمج. لكن عنصر POP لم يملك XML ID، بينما ملكت setup وsupport وprovider معرّفات ومراجع. إذا تغير رقم الهاتف، وجب على طبقة أخرى تحديد ما إذا كان POP نفسه تغير أو استُبدل أو أضيف غيره. وإذا اختفى مدخل، لم يفسر DTD هل حُذف أم صُفي من إصدار الجمهور أم فُقد أثناء نقل جزئي.

كان العداد مكوّناً في بروتوكول محتمل، لا البروتوكول كله.

صحة البنية لم تختبر الخط

كانت معظم القيم #PCDATA. قدمت notations نية نوعية مثل FQDN وIPADR والصور المشفرة، لكنها لم تتصل برقم ولم تستعلم DNS ولم تتحقق من سعر.

قد يكون الرقم المتقاعد نصاً صحيحاً. وقد يكون proxy غير المتاح اسماً صحيحاً. ولم يكن maxBitsPerSecond قياساً لهذه الجلسة. كما أن إضافة قيمة extension مسجلة لا تثبت أن عميلاً قديماً يفهم معناها.

كان أثر الخطأ كبيراً لأن العميل يستطيع استخدام البيانات آلياً. يحمل dialScript خطوات الاتصال؛ وتغير البادئة واللاحقة اسم المستخدم؛ وتختار setup خوادم DNS والبريد والوكلاء والبوابة. يمكن لسطر قديم أن يغير وجهة الاتصال والهوية ومسار الحركة معاً.

حفظ التوقيع البايتات ولم يحفظ الخدمة في الزمن

طلبت RFC 3017 توثيق مصدر المعلومات وحماية سلامتها، لكنها أبقت الأمن خارج DTD وذكرت توقيع PGP مثالاً.

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

بعد الاتصال بقيت مرحلة الهوية. عرفت RFC 2486 Network Access Identifier المستخدم في مصادقة PPP والمساعدة في توجيه الطلب إلى المجال الأصلي. قد يقوم الرابط ثم تُرفض الهوية. وقد تنجح المصادقة وتفشل العنونة أو النفق أو DNS أو التطبيق.

لكل مرحلة إيصالها؛ لا يحمل توقيع الملف إيصال خدمة المستخدم.

قد تأتي القيمة نفسها من DHCP

أقرت RFC 3017 بأن بعض قيم setup قد تتوفر بوسيلة أخرى مثل DHCP. فإذا أعطى الدليل خادم DNS وأعطى DHCP خادماً آخر، لم يقرر DTD الأولوية. قررتها سياسة العميل والسياق، وكان لا بد من رصد القيمة المستخدمة فعلياً.

يحتاج التحقيق إلى هوية الناشر واسم الكتاب والجمهور وdigest والنسخة وPOP والعنوان وentryVersion ونتيجة التوقيع وإصدار parser/DTD والامتدادات والقاعدة ونتيجة commit وdigest النشط. ثم يسجل الاتصال والرابط وPPP وNAI والمصادقة والعنوان والنفق وDNS والوكيل والتطبيق أحداثاً منفصلة.

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

كانت محدودية المواصفة انضباطاً لا نقصاً

لم تدع RFC 3017 أن DTD يدير منظومة التجوال كلها. وحدت الشكل وتركت انتقال الحالة لبروتوكول آخر. يظهر الخطر عندما تمنح برمجية لعداد محدود سلطة إثبات لم تمنحه إياها المواصفة.

تقدم Running-Code Primacy لدى Lu Heng عدسة تقارن الإعداد المنشور بالنظام الجاري. وتفصل Reality Layers بين الوثيقة والناشر والحالة المثبتة والنتيجة. وتشرح Minimum Initial Specification لماذا تبقى الطبقة المشتركة رقيقة، مع ضرورة وضع الانتقال والتوافق والتحقق المحلي في مكان صريح.

هذه أطر تحليل، لا ادعاء بأن Lu Heng شارك في RFC 3017.

كان الدليل ضرورياً للمسافر. لكنه أخبره فقط أن سجلاً تغير.

أما حداثة الطريق إلى الشبكة فلم يثبتها إلا الطريق نفسه.

المصادر