ICANN تسجل تصحيحًا في LGR للخط الجاوي بينما يظل XML النهائي معلقًا

الخلاصة

• يثبت تقرير ICANN المؤرخ 24 أغسطس 2026 أن U+A9B4 ينبغي أن تأتي بعد U+A9BA أو U+A9BB، بدل الجمع الوارد في المسودة بين U+A9BA وU+A9BC.
• الخطأ ليس محصورًا في شرح نثري؛ فهو موجود في مقترح 23 أبريل، وفي عرض HTML، وفي XML حيث تحمل القاعدة المطبقة على U+A9B4 اسم follows-A9BA-A9BC.
• تقول ICANN إن التحديث سيُناقش مع المجتمع الجاوي ثم يُدمج في النسخة النهائية. وفي 1 سبتمبر كانت صفحة LGR المرجعية لا تزال تعرض نسخة 25 أكتوبر 2024 من دون إدراج جاوي نهائي.
• تساعد LGR المرجعية مشغلي السجلات على تصميم جداول IDN وتساعد ICANN على مراجعتها، لكنها ليست جدول المشغل نفسه ولا تثبت التنفيذ التلقائي.
• المطلوب إيصال تصحيح مُعنون بالإصدار يربط المداخلة، وقرار المجتمع، والفرق الدقيق، وبصمات الملفات النهائية، مع إبقاء اعتماد كل سجل حالة منفصلة.

الخطأ موجود في الطبقات الثلاث للمسودة

فتحت ICANN المشاورة في 12 مايو وأغلقتها في 23 يونيو. شملت حزمتها قاعدتين مرجعيتين جديدتين للخط الجاوي ولـUCAS، وستة تحديثات أخرى. ومن بين 33 تعليقًا ذا صلة، أيد 32 الحزمة، بينما ركز تعليق واحد على تصحيح الخط الجاوي وتوضيح العلاقة بين قاعدتين.

أوضح Arif Budiarto، وهو مساهم في المقترح، أن U+A9B4 المسماة JAVANESE VOWEL SIGN TARUNG يمكن أن تتبع U+A9BA المسماة JAVANESE VOWEL SIGN TALING أو U+A9BB المسماة JAVANESE VOWEL SIGN DIRGA MURE. أما إدراج U+A9BC، أي JAVANESE VOWEL SIGN PEPET، فغير صحيح. ووفق المداخلة، لا يغير التصحيح القصد الإملائي؛ بل يعيد تمثيله بدقة.

تظهر صيغة A9BA/A9BC في القاعدة 4 بالصفحة 38 من وثيقة الدعم. ويكرر HTML الشرط نفسه. ثم يربط XML النقطة U+A9B4 بقاعدة follows-A9BA-A9BC ويضع القيمتين داخل فئة السياق. لذلك لا يكفي تعديل فقرة تفسيرية؛ يجب أن يصل التغيير إلى التمثيل الذي تقرؤه الأدوات.

أما القاعدة 3 فتقدم الشرط العام: يجب أن يأتي حرف العلة التابع بعد حرف ساكن، أو ساكن وسطي، أو حرف علة مستقل. وتضيف القاعدة 4 قيدًا أضيق خاصًا بـU+A9B4. أعلن فريق العمل أنه سيحدث النص ومراجع القواعد وشرح الوثيقة الداعمة حتى لا تختلط القاعدة العامة بالقيد الخاص.

ولا يعني ذلك أن U+A9BC غير صالح في الخط الجاوي عمومًا. فهو ما زال ضمن رصيد المسودة. موضوع التصحيح محصور في كونه سابقًا مسموحًا به لـU+A9B4 ضمن هذا الشرط بعينه.

تقرير الملخص ليس ملف القواعد النهائي

سجل تقرير ICANN موقفًا واضحًا: تُناقش الملاحظة مع المجتمع الجاوي ثم تُدرج في النسخة النهائية، وبعد مراجعة التعليقات وإجراء التعديلات اللازمة تُنشر LGR النهائية في صفحة المستوى الثاني.

هذه استجابة فعلية وليست تجاهلًا للمداخلة. لكنها لا تمنح القارئ XML مصححًا. عند الفحص في 1 سبتمبر، كانت الصفحة العامة تسمي 25 أكتوبر 2024 «النسخة الحالية»، ولم تتضمن قائمة القواعد حسب الخط إدخالًا جاويًا. بقيت ملفات أبريل هي الحزمة المرتبطة بالمشاورة.

لا يدعو فاصل ثمانية أيام إلى اتهام بالتأخير. فالتشاور، وتوحيد XML وHTML والوثيقة الداعمة، واختبار النتيجة تحتاج إلى وقت. المهم ألا تُمحى الحالات: العبارة الدقيقة هي «التصحيح مسجل والنسخة النهائية معلقة»، لا «القاعدة تغيرت بالفعل» ولا «ICANN رفضت التصحيح».

توضح إرشادات ICANN سبب مركزية الملف. تُمثل LGR في XML وفق RFC 7940، ومن أسئلة المراجعة ما إذا كان XML يصف النقاط والقواعد المقصودة بدقة. يثبت التقرير اتجاه القرار؛ وتثبت البايتات النهائية تنفيذه.

المرجع لا يحل محل قرار السجل

بعد النشر، يستعين مشغلو السجلات بالقواعد المرجعية عند تصميم جداول أسماء النطاقات المدوّلة، وتستخدمها ICANN عند فحص الجداول المقدمة من سجلات gTLD. هذا تأثير تشغيلي، لكنه ليس آلية تحديث عن بعد.

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

إيصال صغير يكفي لإغلاق المسار

يسجل القسم الأول الحزمة المرصودة: تاريخ 23 أبريل، وروابط وبصمات XML وHTML وPDF، والنقطة U+A9B4، ومعرف القاعدة، وصيغة A9BA/A9BC، والمداخلة التي تطلب A9BA/A9BB. ويحتفظ أيضًا بحدود تفسير القاعدتين 3 و4.

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

ويربط القسم الثالث النشر: الإصدار، والتاريخ، والروابط، والبصمات للملفات الثلاثة. يُظهر فرق قابل للمعالجة خروج A9BC ودخول A9BB في سياق U+A9B4، وتوثق أمثلة المطابقة السلاسل المقبولة والمرفوضة. تبقى المسودة متاحة للتاريخ، لكن بعلامة واضحة تفيد بأنها استُبدلت.

ثم تأتي روابط السجلات منفصلة: نسخة المرجع التي استند إليها الجدول، ونتيجة مراجعة ICANN، وحالة اعتماد المشغل. غياب الرابط يعني «لا دليل علني»، لا أنه يمكن افتراض الاعتماد أو عدمه.

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

ما لا تثبته الأدلة

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

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

المصادر

1. ICANN — تقرير ملخص التعليقات، 24 أغسطس 2026
2. ICANN — مشاورة قواعد LGR الإضافية
3. ICANN — مداخلة Arif Budiarto
4. ICANN — فهرس حزمة 12 مايو
5. ICANN — مسودة LGR الجاوية بصيغة XML
6. ICANN — مسودة LGR الجاوية بصيغة HTML
7. فريق التوليد الجاوي — المقترح الداعم
8. ICANN — قواعد LGR المرجعية للمستوى الثاني
9. ICANN — إرشادات تطوير LGR المرجعية
10. RFC Editor — RFC 7940
11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption