الخلاصة

  • فرض RFC 3454 ترتيب التحويل ثم التطبيع ثم الحظر ثم فحص الاتجاه، لكن البروتوكول المستخدم ظل مسؤولاً عن تحديد profile كامل.
  • لم يعن تساوي المخرجات سوى التساوي وفق ذلك profile وإصدار Unicode؛ ولم يثبت الإملاء أو الشكل أو القصد أو السيطرة على الحساب أو التفويض أو الشخص.

المقارنة سبقت سؤال الهوية

سمح Unicode للبروتوكولات بتجاوز ASCII، لكن نصاً يبدو واحداً قد يتكون من تسلسلات مختلفة أو أحرف توافق أو علامات خفية. نشر RFC 3454 في ديسمبر 2002 إطار stringprep لإعداد السلسلة قبل تخزينها أو مقارنتها.

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

كان profile هو السياسة الفعلية

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

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

كان الترتيب جزءاً من العقد

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

وسع تقرير Unicode رقم 36 لاحقاً تحليل التشابه المرئي. لا يمحو التطبيع كل المتشابهات، ولا يثبت تطابق المخرجات وحدة المالك.

الإصدار جزء من الإيصال

ثبت RFC 3454 جداوله على Unicode 3.2 ورفض تطبيقها آلياً على الإصدارات اللاحقة. جعل ذلك الحساب قابلاً للإعادة، لكنه جعل عبارة «السلسلة صالحة» ناقصة بلا profile وإصدار.

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

حفظ المخرج النهائي وحده يمحو الإدخال والجداول والتحويلات والفرق بين التخزين والاستعلام. بعد التحديث يصبح من المستحيل التمييز بين تغيير المستخدم وتغيير البرنامج.

أظهر Nameprep المنفعة وكلفة التحديث

جعل RFC 3491 Nameprep ملفاً لنظام IDNA الأصلي، وأدخله RFC 3490 في المسار. سجل RFC 4690 مشكلات لاحقة، ولم يستخدم IDNA2008 المعرّف في RFC 5890 stringprep.

لم تصبح المقارنة غير لازمة؛ بل شاخ الإطار المرتبط بإصدار ثابت. صاغ RFC 6885 مشكلة PRECIS، وحل RFC 7564 محل RFC 3454، ثم استبدل RFC 8264 إطار PRECIS الأول. تثبت السلسلة مراجعة مستمرة، لا تغير معنى كل معرّف قديم فوراً.

تفصل منهجية طبقات الواقع لدى Heng Lu بين الإدخال وprofile والجداول والمراحل والمخرج أو الخطأ والمقارنة وربط الحساب والتفويض. تسمح أولوية الشفرة العاملة للبرنامج بإثبات حسابه لا بتعيين المالك. وتفسر المواصفة الأولية الدنيا ترك الهوية والسلطة للبروتوكول المستخدم. هذه قراءة تحريرية لاحقة.

جعل RFC 3454 التطبيع قوياً داخل حد مسمى. لكن المقارنة الحتمية ظلت غير الهوية.

المصادر