الخلاصة

  • يعرّف RFC 10050 الملف بأنه مجموعة مسماة وذات إصدار من القيود على خصائص JSContact وأنواعها وقيمها المسجلة. يمكنه تضييق المعيار الأساسي ولا يستطيع تخفيفه.
  • لا تتضمن Card حقلاً عاماً يعلن الملف المطبق. ولأن البطاقة قد تطابق عدة ملفات، فعلى البروتوكول المحيط تحديد الاسم والإصدار وطريقة نقلهما والقواعد الإضافية.
  • يحفظ سجل IANA الهوية التاريخية لكل زوج من الاسم والإصدار، لكن التسجيل ليس شهادة على سلامة المحتوى أو ملاءمته؛ تظل مسؤولية سياسة القبول عند مصمم البروتوكول ومشغله.

عبارة «البطاقة صالحة» تبدو حاسمة، لكنها قد تختصر ثلاثة أسئلة مختلفة. هل البنية صالحة وفق JSContact؟ هل تطابق ملفاً بعينه؟ وهل يسمح بروتوكول الخدمة بهذه الرسالة؟ يمكن أن تكون الإجابتان الأوليان نعم والثالثة لا.

نُشر RFC 10050 في سبتمبر 2026 بصفة Proposed Standard ليمنح الاستخدامات المقيدة من JSContact هوية قابلة للتتبع. أهم ما يفعله هو أنه لا يحول تلك الهوية إلى تصريح شامل بالقبول.

مجموعة فرعية لا صيغة منافسة

صُمم نموذج Card في RFC 9553 لخدمة حالات كثيرة. قد يحتاج تطبيق محدد إلى جعل خاصية اختيارية إلزامية، أو منع خاصية صحيحة في النموذج العام، أو حصر الأنواع أو القيم. يجمع الملف هذه القيود.

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

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

تجعل هذه القاعدة السجلات قابلة للمراجعة. إذا ذكر سجل أن القرار استخدم الإصدار 2، فيجب أن يشير إلى القيود نفسها بعد ظهور الإصدار 3. وإلا تغير معنى القرارات القديمة من دون تغيير ملفاتها.

المطابقة تحتاج إلى اجتياز متكرر

خصائص JSContact ليست قائمة مسطحة. قد تحتوي الخاصية كائناً متداخلاً، وقد يفتح النوع المسموح خصائص أخرى. لذلك يجب حساب مجموعة الخصائص المدعومة بصورة متكررة حتى الوصول إلى الإغلاق الكامل.

قد تسمح قائمة للطبقة العليا بفرع داخلي محظور. وقد يرفض تطبيق ضيق خاصية متداخلة تصل إليها بنية مسموح بها. تساعد JSON Pointer في RFC 6901 على تحديد المواضع، لكنها لا تثبت أن المدقق سار في الشجرة كلها.

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

لماذا لا تعلن البطاقة ملفها بنفسها

لا يضيف RFC 10050 خاصية عامة إلى Card لإعلان الملف، ولا يفرض حاوية واحدة للاسم والإصدار. يحدد البروتوكول المستخدم طريقة النقل أو التفاوض.

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

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

التسجيل يحفظ المرجع ولا يمنح الاعتماد

تستخدم التسجيلات الجديدة سياسة Specification Required في RFC 8126، وتخضع تحديثات المراجع لمراجعة الخبراء، ويظل IETF جهة التحكم بالتغيير. يفحص الخبراء تميز الاسم وصحة تركيبه، ومعرفة الخصائص والأنواع، واستقرار المواصفة، وزيادة رقم الإصدار.

لكن RFC 10050 لا يلزمهم بتقييم مضمون الملف. لا تعني خانة التسجيل اعتماداً أمنياً أو موافقة على الخصوصية أو ملاءمة لقطاع. يحذر RFC 9553 من حساسية بيانات الاتصال، ويبقى على الجهة التي تتبنى الملف أن تبرر البيانات التي تجمعها.

وقت هذه المراجعة، كانت صفحة IANA الخاصة بـJSContact تعرض قسم الملفات بلا إدخالات، والخبراء المعينين على أنهم غير محددين. أظهرت الصفحة آخر تحديث في 28 مايو 2026 ومرجعاً لمسودة إنترنت، أي حالة تسبق نشر RFC في سبتمبر. هذه ملاحظة مؤرخة وليست اتهاماً بالتقصير؛ قد تختلف دورات التحديث.

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

المصادر