الخلاصة

  • يفرض RFC 3722 تسلسلاً من تحويلات Unicode وتطبيع NFKC وفحوص المحارف المحظورة كي تتمكن تطبيقات iSCSI من مقارنة بايتات UTF-8 بعد إعدادها.
  • عالجت القاعدة صعوبة النسخ البشري وبساطة الأجهزة، لا انتحال الهوية: تظل المحارف المتشابهة مختلفة، ويستند الملف إلى Unicode 3.2.

قد يبدو اسمان متماثلين في لوحة إدارة التخزين، بينما يتعامل الهدف معهما كسلسلتين مختلفتين. تظهر أهمية هذا الفرق حين ينسخ مسؤول اسماً من ملصق أو إجراء تشغيلي، ثم يقرر بادئ صغير ما إذا كانت البايتات المستلمة تطابق الهدف المضبوط. صدر RFC 3722 في أبريل 2004 ليعالج هذا الحد تحديداً في أسماء واجهة الأنظمة الصغيرة للحاسوب عبر الإنترنت (iSCSI).

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

اختار RFC 3722 ملفاً محدداً بدلاً من تنظيف حر للنص. حدد مجموعة Unicode 3.2، واستخدم تحويلات Stringprep في الجدولين B.1 وB.2، ثم تطبيع NFKC. بعد ذلك يفحص المخرجات المحظورة في الجداول C.1.1 إلى C.9 ويطبق اختبارات النص ثنائي الاتجاه. ترتيب الخطوات يمنع التطبيق من ابتكار علاقة تكافؤ مناسبة له بعد استقبال الاسم.

تُزال بعض الفروق وتبقى أخرى. يجب تحويل أحرف ASCII الكبيرة التي يدخلها المستخدم عبر الواجهة إلى أحرف صغيرة. تشمل مجموعة ASCII المسموح بها الحروف الصغيرة والأرقام والشرطة والنقطة والنقطتين؛ أما المسافات فغير مسموح بها. ومن الحالات الدقيقة U+3002، النقطة الأيديوغرافية: يحظرها RFC 3722 حتى لو عاملتها بعض أنظمة إدخال أسماء النطاقات كأنها النقطة ASCII U+002E. لذلك لا يرث ملف iSCSI تلقائياً الاستبدالات التي تجريها تطبيقات أخرى.

لا يعني ذلك أن «كل Unicode أصبح آمناً». فالناتج تمثيل محدد وفق مجموعة وجداول مؤرخة بوضوح. لترميز UTF-8 مواصفته المنفصلة، كما أن قواعد تركيب اسم iSCSI وسلطة التسمية تحتاج إلى فحوص مستقلة. يشرح RFC 3721 سياق الأسماء والاكتشاف، بينما يحدد RFC 3722 إعداد السلسلة. نجاح الإعداد لا يثبت وجود إذن بالوصول، ولا أن مؤسسة ما ما زالت تسيطر على الاسم، ولا أن الهدف متاح على عنوان معين.

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

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

يرتبط Nameprep في RFC 3491 بالموضوع لأنه ملف Stringprep آخر للأسماء الدولية، لكنه ليس ملف iSCSI. يضع RFC 3454 الإطار العام ويختار RFC 3722 قواعد غرضه المحدد. كما أن تجميع بروتوكول iSCSI لاحقاً في RFC 7143 لا يجعل أساس Unicode 3.2 توصية راهنة لكل نظام معرّفات جديد.

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

المصادر