الخلاصة

  • تقول صفحة W3C إن w3.org/2026/08/xmldsig-more# خُصص لـ XML Security، لكنها تربطه بأحدث نسخة من المسودة لا بنسخة مرقمة وبصمة محددة.
  • بقيت -08 تستخدم w3.org/tbd#، ثم استبدلت -09 الحقل المؤقت بالنطاق الجديد في 21 أغسطس وأضافت مواد أخرى. أما صفحة W3C فتسبقها بيومين.
  • تطلب إرشادات W3C نفسها بيان كيفية تعريف الأسماء أو إزالتها ومن يقرر ذلك. الصفحة الجديدة لا تعرض هذه السياسة، وصمتها لا يثبت قابلية التغيير ولا عدمها.
  • ينبغي لدستور تغيير النطاق أن يربط التخصيص بالنسخة والبصمة، ويصنف التعديلات المسموحة قبل التجميد، ويحدد معالجة التوافق وسلطة التجميد، ويفصل حالات W3C وIETF وIANA.
  • لا دليل على تخصيص باطل أو اعتماد خوارزمية أو تبني IETF للمسودة أو تأخر IANA أو فشل التعاون. المشكلة في وضوح سلسلة النسخ والسلطة.

العنوان الدائم لا يحفظ تلقائيًا حالة الوثيقة

تقول صفحة نطاق W3C إن العنوان خُصص لـ XML Security وإنه يقابل مواصفة، وتحيل إلى صفحة RFC 9231bis في Datatracker، وتسجل آخر مراجعة باسم Simone Onofri في 19 أغسطس 2026. ولا تعرض رقم نسخة أو بصمة أو قرار تخصيص علنيًا أو قاعدة لتعديل الأسماء المحلية.

ليس قصر الصفحة عيبًا بذاته. فالحصول المبكر على URI مستقر يزيل الأسماء المؤقتة، ويحد من التصادم، ويتيح اختبارًا مشتركًا بين المواصفات قبل اكتمال المسار المؤسسي. ويمكن لـ W3C أن يوفر هذه البنية من دون أن يعتمد المحتوى التقني.

لكن رابط «الأحدث» يؤدي وظيفة الاكتشاف فقط. يبين نص اليوم، ولا يبين النص الذي شمله الإذن يوم التخصيص. كما لا يوضح ما إذا كانت تعديلات لاحقة تقع ضمن الإذن أو تحتاج قرارًا جديدًا.

تغير شكل التنسيق العلني مع تغير المسودة

فُتحت القضية 484 في مستودع Strategy لدى W3C في 17 نوفمبر 2024 بوصفها مقترح ورشة حول التشفير ما بعد الكمي في XML Signature وXML Encryption. وهي دليل على تنسيق مفتوح، وليست Recommendation أو ميثاقًا أو قرار انتقال رسميًا.

في 21 نوفمبر 2024، عرض مؤلف المسودة الفردية إضافة خوارزميات إلى RFC 9231bis. وفي 14 يونيو 2025، سُجلت HSS/LMS وML-DSA وSLH-DSA وML-KEM، مع اقتراح أن تحل القضية نفسها محل الورشة. العرض والقائمة يسهمان في العمل، لكنهما لا يصنعان توافق W3C أو تبني IETF.

في 17 أغسطس 2026، قيل إن -08 تشمل العائلات الأربع وإن -09 قيد الإعداد بمواد إضافية. تحمل صفحة النطاق تاريخ 19 أغسطس. ثم أُعلن نشر -09 في 21 أغسطس. وفي 26 أغسطس، أعيد وصف الغرض العام للقضية: لم تعد لتنظيم ورشة، بل لتتبع احتياجات تحديث XML Signature وXML Encryption.

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

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

نية المؤلف ليست حالة IETF

أظهر Datatracker النسخة -09، عند حد الأدلة، بوصفها Internet-Draft فردية نشطة في حالة I-D Exists، من دون RFC stream محدد أو Area Director مسؤول. نشر مسودة فردية عمل مشروع ومفتوح، لكنه ليس تبنيًا أو اعتمادًا من IETF.

أما رأس الوثيقة فيقول Independent وObsoletes: 9231 (if approved)، ويذكر Standards Track بوصفها الحالة المقصودة، ويحدد الانتهاء في 22 فبراير 2027. يعبر الرأس عن هدف المؤلف وأثر مشروط؛ وتعرض البيانات الوصفية الوضع المؤسسي القابل للإسناد. لا تعارض لازمًا بينهما.

ما زالت النسخة المؤرشفة -08 المؤرخة في 26 مايو تستخدم w3.org/tbd#. وبصمتها SHA-256 هي cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

أما -09 المؤرخة في 21 أغسطس فتستبدل الحقول المؤقتة بـ w3.org/2026/08/xmldsig-more#، وتضيف schema للجيل الجديد، وتتضمن تغييرات أخرى. وبصمتها 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

ويؤكد سجل المراجعات العام تاريخي 26 مايو و21 أغسطس، من دون إظهار تبني Working Group أو تعيين stream أو Area Director.

إذًا تثبت الوقائع الترتيب: حقل مؤقت في -08، صفحة W3C في 19 أغسطس، URI فعلي في -09 يوم 21. ولا تثبت تاريخ قرار التخصيص أو النص الدقيق الذي روجع أو امتداد الإذن إلى كل تعديل آخر.

ثلاث سلطات لا موافقة واحدة

يبقى RFC 9231 المرجع المعتمد. وهو يوثق الجيل السابق ويفصل بين المعرّف وأي صفة رسمية للخوارزمية لدى W3C أو IETF.

وما زال سجل XML Security URIs لدى IANA يشير بصورة صحيحة إلى RFC 9231، ويعمل وفق Specification Required وبخبراء معينين. هذا هو الوضع المتوقع ما دامت المسودة اللاحقة غير معتمدة، وليس تأخرًا أو رفضًا.

يحرس W3C عنوانًا في فضائه على الويب. ويمكن لمسار وثائق IETF أن يطور مواصفة أو يتبناها أو يراجعها ثم يعتمدها. وتطبق IANA سياسة السجل. يملك مؤلف المسودة تحرير النص، لا سياسة نطاق W3C. ويخصص W3C العنوان، لا RFC. وتسجل IANA المعرّفات، ولا تأمر المشغلين بنشرها.

ينبغي لسجل التسليم أن يصل هذه السلطات من دون دمجها.

وضعت W3C السؤال الصحيح في سياستها العامة

تعترف إرشادات W3C للنطاقات بالصيغ المؤرخة، وتقول إن @w3c/transitions يخصصها ويأذن بها من خلال pull requests في w3c/ns. كما تشرح فائدة المعرفات المستقرة أثناء النقاش، وتفصل التخصيص عن التأييد.

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

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

ولا يجوز قلب القاعدة: غياب التصريح لا يمنح حقًا مفتوحًا في التعديل. تبقى الحالة غير قابلة للاستنتاج من السجل العام.

تشمل سياسة W3C لاستمرارية URI الموارد المؤرخة، مع السماح بالتعديل وحفظ الحالات السابقة. استمرار العنوان ليس تجميدًا لكل اسم تحته.

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

الأجيال السابقة تملك حدث تجميد معلومًا

تصف -09 بادئة 2000 بأنها “Frozen by W3C”، وتربط تجميد أجيال 2001 و2007 و2021 بالوثائق RFC 4051 وRFC 6931 وRFC 9231. فالتجميد انتقال له مصدر، لا انطباع بصري.

أما جيل 2026 فلا يوضح علنًا إمكان إضافة اسم قبل RFC أو إزالته، وكيف يعامل اسم استُخدم بالفعل، وهل اعتماد RFC يجمده تلقائيًا، وهل يحتاج W3C إلى فعل منفصل، وهل تتطلب الإضافات اللاحقة تاريخًا جديدًا.

ليس على مراقب خارجي اختيار الأجوبة. لكن ينبغي ألا تفرضها التبعيات المثبتة قبل نشرها.

URI ليس حكمًا على الخوارزمية

توضح XML Signature 1.1 وXML Encryption 1.1 سبب أهمية المعرفات المتوافقة لبنى XML. ولا تعتمدان تلقائيًا كل خوارزمية قد تحمل معرفًا في المستقبل.

يشرح RFC 8126 أن Specification Required تتطلب مواصفة دائمة ومتاحة علنًا ومراجعة خبير. إنها سياسة قبول لسجل، لا شهادة أمن عامة ولا أمر نشر.

لا يقارن هذا المقال الخوارزميات، ولا يصف أيًا منها بالآمن أو غير الآمن أو النهائي أو المطبق أو واسع الانتشار. تنشأ المسألة نفسها مع أي مفردات دائمة تعتمد على وثيقة متغيرة.

دستور قصير لتغيير النطاق

يبدأ الدستور بالـ URI ونوعه المؤرخ وقرار التخصيص والجهة والتاريخ وسجل pull request أو transition العلني. ويعرض نسخة المسودة وبصمتها عند التخصيص منفصلتين عن النسخة المرتبطة اليوم.

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

ويحدد حدث التجميد وصاحبه وتوقيته. أما قاعدة ما بعد التجميد فتقول هل تستخدم الإضافة البادئة نفسها، أم Expert Review لدى IANA، أم errata، أم RFC لاحقًا، أم نطاقًا مؤرخًا جديدًا.

وتعرض حقول مستقلة حارس صفحة W3C؛ وفئة وثيقة IETF ومجموعتها وstream وحالة التبني وArea Director عند وجودها؛ وحالة سجل IANA وسياسته ونطاق الخبراء. ويجب فصل مصدر صياغة المعرّف عن مصدر دلالة الخوارزمية، مع سجل للتصحيح والخلافة والانتهاء والمراجعة التالية.

تخصيص النطاق، ونشر المسودة، وتبني IETF أو تعيين stream، واعتماد RFC، وتحديث IANA، ونشر التقنية ستة أفعال مختلفة. لا يغني أحدها عن الآخر.

لا حاجة لنشر المداولات الخاصة أو تقارير التنفيذ الحساسة. تكفي النسخة والسلطة وفئة التغيير والانتقال.

القضية في الوضوح لا في سوء السلوك

في السجل عناصر قوية: نقاش مفتوح، نسخ محفوظة، URI مستمر، سجل IANA صحيح، وتنبيه صريح ضد التأييد الضمني. لا دليل على سوء نية أو استحواذ أو تسجيل غير مخول أو تعاون منهار.

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