الخلاصة

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

اسم النطاق في المستوى الأعلى قصير، لكن إضافته إلى الجذر تغيّر الوجهات التي يستطيع DNS العام توجيه الناس إليها. في عام 2006، فصلت خطة اختبار ICANN بين سؤالين يسهل الخلط بينهما: هل تستطيع مكوّنات DNS تمرير التسميات الدولية في بيئة تشبه الجذر؟ وهل تجعل التطبيقات والواجهات هذه الأسماء قابلة للاستخدام؟ أُحيل السؤال الأول إلى المختبر. أما الثاني فخُصص لمرحلة لاحقة، ولم يكن من الممكن اعتباره نتيجة للأول.

كانت Tina Dam قريبة من البرنامج، لكن السجل لا ينسب إليها تأليف التجربة. تصفها سيرة ICANN الأرشيفية بأنها المديرة الأولى لملفات IDN، والمسؤولة عن تطوير مشاريعها وإدارتها، بما فيها المسار السريع لنطاقات رموز البلدان. ويذكر إعلان 2007 اسمها جهة اتصال للاختبار، بينما أعدّ Lars-Johan Liman تقرير Autonomica. وعند إطلاق المسار السريع في 2009، تحدثت Dam عن سنوات من المسودات والاختبارات والعمل التطوعي. وهذا يثبت دوراً قيادياً مستمراً في البرنامج، لا أنها صممت أو نفذت كل اختبار بنفسها. (سيرة ICANN؛ إعلان الاختبار لعام 2007؛ إعلان الإطلاق لعام 2009)

كان تصميم الاختبار محدداً، وكذلك حدوده. بعد تكليف Autonomica في أكتوبر 2006، نشرت ICANN خطة أولية لاستقبال التعليقات. وأنشأت الشركة في ستوكهولم بيئة مغلقة تضم خادمي أسماء للجذر، وخادماً لنطاق المستوى الأعلى، ومحلّلات تكرارية، ومولّداً للاستعلامات. واستندت منطقة الجذر إلى نسخة من المنطقة الفعلية أضيفت إليها تفويضات اختبارية. عمل الخادمان ببرمجيتي BIND 9.3.2 وNSD 2.3.5؛ وشملت المحلّلات إصدارات متعددة من BIND وMicrosoft DNS في Windows 2000 و2003. مرّر الفريق استعلامات DNS اعتيادية ورصد الإجابات الخاطئة والتأخير غير المتوقع. وسجّل التقرير أن السلوك وافق المتوقع في الحالات التي اختُبرت، من دون تأخيرات غير متوقعة. (خطة اختبار ICANN في ديسمبر 2006؛ تقرير Autonomica)

قلّصت النتيجة نوعاً واحداً من عدم اليقين: عالجت البرمجيات المختارة التفويضات المضافة داخل تلك البيئة المحاكية. لكنها لم تثبت أن كل محلّل أو جهاز أو متصفح أو جدول أحرف أو إجراء تسجيل سيعمل بالطريقة نفسها. وقد قصر التقرير نطاقه صراحة على التطبيقات التي أمكن اختبارها. وفي مارس 2007، حدد إعلان ICANN حدّين آخرين: لم تُجر التجربة على الجذر الحي ولم تتناول تجربة المستخدم النهائي. وكانت الخطة السابقة قد أفردت مرحلة مستقلة لاختبار التطبيقات والواجهات. لذلك، لا تكشف إجابة الخادم الصحيحة ما يراه الشخص عندما يكتب اسماً دولياً أو يتصفحه. (إعلان اختبار ICANN)

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

للبروتوكول حدّ آخر. يميّز IDNA بين تسمية Unicode من نوع U-label ونظيرتها المتوافقة مع ASCII من نوع A-label. وهما تمثيلان مرتبطان للتسمية نفسها، لكن ذلك لا يضمن عرضها أو قبولها بالطريقة ذاتها في كل واجهة. تحدد وثائق IDNA2008 اللاحقة سلوك التسجيل والاستعلام، فيما تترك بعض إجراءات المسجّلين خارج نطاقها. كما يذكر سجل Dam العام أنها كانت ضمن موظفي ICANN الذين دعموا مجموعة متعددة الأطراف لمراجعة إرشادات IDN في 2010. وتوضح هذه السجلات سبب قصور عبارة «اجتاز اختبار الجذر»: فالتوافق التقني، وأهلية التسمية، والتفويض، وتجربة المستخدم الفعلية حلقات فحص مستقلة. (RFC 5890؛ RFC 5891؛ مسودة مراجعة إرشادات IDN لعام 2010)

المصادر