الخلاصة

  • فصلت RFC 2345 بين العثور على معلومات شركة وبين إدارة DNS والنزاع على الحقوق في الاسم؛ فقد عالجت سؤال «أين أبحث؟» فقط.
  • تركت للخادم تعريف اسم الشركة وقواعد الاختصار والتهجئة والمطابقة، ولم تجعل صحة قرار المطابقة جزءاً من مواصفات البروتوكول.
  • احتوى الرد على URL وعبارة عرض حرة، بلا رقم شركة أو ولاية قانونية أو مصدر أو تاريخ تحقق أو دليل على السيطرة على النطاق.
  • كان النموذج يرتب المرشحين ويقتطع النتائج بعد العشرة الأوائل ويفتح المطابقة الوحيدة تلقائياً، ولذلك لم تكن الوحدة الظاهرة ولا المرتبة دليلاً على الاكتمال.
  • احتاج إثبات الهوية والسيطرة والخدمة إلى فحص مستقل للكيان وتسجيل النطاق وDNS وأصالة الصفحة ونتيجة المعاملة.

ثلاثة أسئلة لا سؤال واحد

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

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

هذا التحديد يمنع إعطاء الرد سلطة لم يطلبها المصممون. يمكن للدليل أن يقترح صفحة، لكنه لا يفصل في نزاع على اسم ولا يغيّر تفويض DNS ولا يحدد صاحب الحق القانوني.

استعارة الغلاف البسيط من WHOIS

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

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

وحد الشكل التقني، لا الحقيقة التحريرية. كان بإمكان خادمين استخدام مصادر وقواعد مطابقة وترتيب مختلف، مع التزام كلي بالبروتوكول.

الاسم نص قابل للالتباس وليس معرفاً قانونياً

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

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

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

عبارة «اسم الشركة» لم تكن شهادة

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

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

كان تقليل البنية قراراً مقصوداً لتسهيل التنفيذ. لكنه أزال أيضاً السياق اللازم لتقدير قوة الادعاء.

العنوان يحدد موقعاً ولا يمنح ملكية

عرفت RFC 1738 عنوان URL بوصفه تمثيلاً مختصراً لتحديد مورد على الإنترنت والوصول إليه. كما نبهت إلى عدم وجود ضمان عام بأن يظل العنوان يشير إلى المورد نفسه في المستقبل.

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

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

حتى تسجيل اسم نطاق لا يحسم الحقوق في الاسم. فقد قالت RFC 1591 إن التسجيل لا يمنح وضع علامة تجارية. ونتيجة دليل لا تثبت التسجيل أصلاً لا يمكن أن تحمل حكماً أقوى.

النتيجة الوحيدة خلقت يقيناً محلياً

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

لكن «واحدة» تعني واحدة في قاعدة بعينها وبقواعد بعينها وفي لحظة بعينها. قد يغيب كيان حديث، أو تفشل تهجئة في استرجاع سجل، أو تدمج عملية التطبيع شركتين. وقد يعيد مزود آخر أكثر من مرشح.

سرعة الانتقال لم تضف دليلاً؛ بل سرعت أثر قرار تحريري مخفي.

العشرة الأوائل ليست قائمة كاملة

احتوى خادم العرض على نحو 209 آلاف سجل قدمتها Dun & Bradstreet. وإذا وجد عشرة سجلات أو أكثر أعاد العشرة الأوائل فقط. وعرض العميل من اسمين إلى عشرة مرتبة حسب درجة.

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

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

الجودة صُنعت خارج صيغة النقل

أوضحت RFC 2345 أن جودة النتائج تتوقف على الدليل الأساسي وعلى العمل التحريري والبحثي المبذول في بنائه، وأن كليهما خارج البروتوكول.

يمكن أن يكون الرد صحيح التنسيق وقديم المحتوى. ويمكن للتخزين المؤقت أن يكرر خطأ بسرعة. وفي المقابل يستطيع دليل دقيق استخدام الصيغة البسيطة نفسها.

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

اختيار المزود جزء من أصل النتيجة

لم تشترط الوثيقة مزوداً واحداً أو سجلاً لمزودي الخدمة. وشجعت على أن يتيح العميل اختيار الخادم.

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

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

الوصول إلى الصفحة لا يثبت نجاح الخدمة

حتى لو كانت العلاقة صحيحة، يجب أن ينجح DNS والمسار والاتصال، وأن تكون شهادة TLS مناسبة، وأن تبقى التحويلات ضمن سلسلة سيطرة مقبولة. وبعد ذلك ينبغي أن يعمل المنتج أو الدعم أو المعاملة التي يبحث عنها المستخدم.

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

أجاب الدليل عن مكان النظر. وبقيت الهوية والسيطرة التقنية ونتيجة الخدمة ثلاث وقائع مستقلة.