الخلاصة

  • استخدمت RFC 3982 الوسمين private وdenied لتفسير قيمتين فارغتين مختلفتين: الأولى قد لا تُنشر أبداً، والثانية تحجبها السياسة عن مستوى الوصول الحالي.
  • أما القيمة الظاهرة فكان يمكن أن تحمل specialAccess وdoNotRedistribute، بحيث لا يتحول امتياز الاطلاع تلقائياً إلى حرية إعادة النشر.

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

وضعت RFC 3982 هذا السبب داخل بنية البروتوكول. تسجل صفحة الحالة وصفحة التصحيحات وتاريخ Datatracker وثيقة المسار القياسي الصادرة في يناير 2005. عرّفت الوثيقة نوع سجل النطاقات في IRIS، بما يشمل استعلامات ونتائج منظمة للنطاقات والمضيفين وجهات الاتصال والمسجلين وسلطات التسجيل.

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

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

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

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

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

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

لم تكن الوسوم آلية إنفاذ. وضعت RFC 3981 وحالتها رفض الإذن وفحص الصلاحيات مسبقاً في نواة IRIS، وتركتا المصادقة والخصوصية لطبقة النقل. وحددت RFC 3983 وصفحة حالتها النقل فوق BEEP. لا يشفر الوسم قيمة، ولا يصادق مستخدماً، ولا يمنع النسخ مادياً، ولا ينشئ وحده واجباً قانونياً. وظيفته أن يحمل قرار السياسة كي لا يختفي بين الأنظمة.

عاد الغموض نفسه في RDAP. تعرّف RFC 9083، مع حالتها وتصحيحاتها وتاريخها، نموذج استجابة JSON. وتضيف RFC 9537 وحالتها وتصحيحاتها وسجل IETF امتداداً صريحاً للحقول المنقحة.

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

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

المصادر