الخلاصة

  • أبقت RFC 3490 نظام DNS في نطاق ASCII، وجعلت IDNA تعمل داخل التطبيق. كان بوسع ToASCII رفض الوسم، أما ToUnicode فلم تكن تعلن الفشل، بل تعيد المدخل الأصلي إذا تعثرت أي خطوة.
  • لذلك لم يكن النص الظاهر دليلاً على صلاحية الوسم، أو قبول السجل له، أو إدخاله في المنطقة، أو حله، أو توثيقه عبر DNSSEC، أو سيطرة جهة عليه. لكل مرحلة إيصال مستقل.

تبدو عبارة «لا تفشل أبداً» كأنها وعد بالصحة. لكن RFC 3490 استخدمتها لوصف استمرارية العرض، لا صحة الاسم. كان على ToUnicode أن تعيد سلسلة من نقاط Unicode في كل الأحوال. وإذا أخفق التحضير أو فك الترميز أو اختبار الرجوع، أعادت المدخل كما هو. بقي لدى التطبيق شيء يعرضه، من دون أن تمنحه المواصفة صفة اسم دولي صالح.

ينبع هذا الاختيار من هندسة عام 2003. لم تغيّر IDNA خوادم DNS أو المحللات أو عناصر البروتوكول على السلك. كانت طبقة رقيقة داخل التطبيق بين واجهة بشرية تتعامل مع Unicode وبنية DNS قديمة تتوقع ASCII. حدث التدويل عند الطرف، فيما بقيت خدمة الأسماء الأساسية مطابقة دقيقة.

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

في الاتجاه نحو DNS كان الفشل مطلوباً. عالجت ToASCII كل وسم على حدة. مرّ المدخل غير ASCII عبر Nameprep، وكان ممكناً فرض قيود الحروف والأرقام والواصلة، ورفضت السلسلة غير ASCII إذا بدأت بالبادئة المحجوزة، ثم استخدمت Punycode وأضافت xn-- وتحققت من أن الطول النهائي بين نقطة واحدة و63 نقطة ترميز. فشل أي خطوة يعني فشل العملية، وفشل وسم واحد يمنع استخدام الاسم كله بوصفه IDN.

أما الاتجاه نحو القارئ فكان له غرض آخر. تحققت ToUnicode من بادئة ACE، وحذفتها، وفكت Punycode، ثم أعادت تمرير الناتج عبر ToASCII. لم تعرض صيغة Unicode المفكوكة إلا إذا طابقت صيغة ASCII المعاد بناؤها المدخل المحفوظ، مع تجاهل حالة أحرف ASCII. كان اختبار الذهاب والعودة حاجزاً يمنع سلسلة تشبه ACE من اكتساب تكافؤ لم تثبته.

إذا لم ينجح الاختبار، لم تتحول النتيجة الوسيطة إلى اسم صحيح بحكم سهولة العرض. عاد المدخل الأصلي. وأوضحت RFC 3490 أن الوسم الذي يظل بادئاً ببادئة ACE بعد ToUnicode ليس وسم ACE صالحاً، ولا يكافئ سلاسل Unicode الوسيطة. وجود قيمة راجعة إيصال من وظيفة العرض، لا قرار قبول.

تكشف هذه الآلية سلماً من الأدلة. القدرة على إظهار سلسلة لا تثبت نجاح ToASCII. نجاح التحويل لا يلزم السجل بقبولها وفق قواعد اللغة والكتابة المحلية. القبول لا يثبت أن A-label أُدخل في المنطقة. إجابة DNS قد تأتي من wildcard. وDNSSEC يوثق بيانات DNS للاسم ASCII الموقع، لا صورة Unicode ولا معنى الصورة في ذهن المستخدم. كما أن الحل لا يثبت ملكية الاسم أو هوية الجهة المقصودة.

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

سجلت RFC 4690 لاحقاً تعقيدات التشابه البصري وسياسة التسجيل وتطور Unicode والانتقال. ثم أعادت RFC 5890 وRFC 5891 بناء المصطلحات حول A-label وU-label، وفصلتا بوضوح بين بروتوكول التسجيل وبروتوكول البحث. يستطيع التسجيل طلب تطابق دقيق ورفض الاختلاف، بينما يكون البحث أوسع قليلاً مع احتفاظه بالتحقق. ونصت RFC 5891 على أن نجاح المقارنة لا يعني الصلاحية.

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

استُبدل نظام RFC 3490 لاحقاً، لكن حكمته في اتجاهي الفشل باقية. الوظيفة التي تعيد قيمة دائماً مفيدة حتى لا يختفي ما ينبغي عرضه، لكنها ليست محكماً للصلاحية. أعطت ToUnicode التطبيق مادة للعرض؛ وقررت ToASCII هل توجد صيغة مقبولة للقناة القديمة. أما التسجيل والوجود والحل والتوثيق والسيطرة فظلت وقائع تحتاج أدلتها الخاصة.

المصادر