الخلاصة

  • يسجل RFC 9996 النوعين application/protobuf وapplication/protobuf+json لتمييز الكائنات المسلسلة ثنائياً عن تمثيل ProtoJSON.
  • تشير معلمة version الاختيارية إلى إصدار مستقبلي لترميز السلك، لا إلى Proto2 أو Proto3 أو Edition أو مراجعة ملف .proto أو إصدار مؤسسي معتمد.
  • يقترح Daniel Kade إيصالاً لسياق المخطط يفصل محدد نوع الرسالة، وبصمة المخطط، وسلطة الإصدار، وقرار التوافق، وسياسة المفكك، والتحويلات، وقرار الاعتماد النهائي.

الخطأ الصامت يبدأ من كائن يبدو سليماً

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

لكن المنتج قد يكون قد استخدم تعريفاً يختلف عن تعريف المستهلك. الحقل 4 صلاحية عند طرف ومدة عند الطرف الآخر، أو قيمة تعداد مجهولة يحتفظ بها تنفيذ ويتجاهلها آخر. تظل البايتات Protobuf حقيقية، ويبقى نوع الوسائط صحيحاً، بينما تصبح النتيجة الدلالية خاطئة.

لا يدعي RFC 9996 حل هذه المطابقة. نُشر في يوليو 2026 بوصفه RFC معلوماتياً يمثل توافق IETF. ويسجل application/protobuf للتمثيل الثنائي وapplication/protobuf+json لـ ProtoJSON، فيقدم بديلاً رسمياً للأسماء التاريخية التي تبدأ بـ x-.

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

هذا الفصل ليس عيباً في التسجيل. فلا ينبغي لسجل عام أن يحكم مخططات كل تطبيق خاص. المسؤولية المحلية هي ألّا تمنح الغلاف دليلاً لم يحمله.

الرقم واحد يصف السلك لا المخطط

تنظم معلمة encoding الفرعين. القيمة الافتراضية لـ application/protobuf هي binary، ولـ application/protobuf+json هي json مع وجوب charset=utf-8. ويجب اعتبار القيمة المناقضة للنوع الفرعي خطأ. كما يسمح اللاحق +json للمعالجات العامة والمتصفحات بالتعرف إلى JSON.

المعلمة الاختيارية الأخرى هي version وقيمتها الافتراضية 1. غير أن RFC يقول صراحة إنها نسخة مواصفة ترميز السلك، لا نسخة لغة المخطط. لا توجد حالياً سلسلة نسخ من ترميز Protobuf السلكي تستدعي هذا التمييز؛ الحقل محجوز للتوسع في المستقبل.

أما Proto2 وProto3 وEdition 2023 وEdition 2024 فهي مراحل تطور في IDL. قد تنتج تمثيلاً متوافقاً على السلك مع بقاء اختلاف دلالي. يورد RFC مثال قيم التعداد غير المعروفة: ما اعتبر غير صالح في جيل قد يُحفظ بوصفه قيمة مجهولة في جيل آخر.

لذلك لا يعني version=1 «المخطط رقم 1»، ولا يثبت Proto3 أو Edition 2024 أو إصداراً وافق عليه مالك الخدمة. فهو لا يحمل اسم الحزمة أو نوع الرسالة أو المراجعة أو البصمة أو الناشر. تشابه الاسم لا يصنع حجة.

قابلية التوافق لا تمنح إذن الاعتماد

يوضح دليل Proto3 أن الصيغة السلكية المقتصدة لا تستطيع اكتشاف أن حقلاً شُفّر بتعريف وفُك بتعريف آخر. وقد تؤدي إعادة استخدام رقم حقل إلى خطأ في الدمج، أو فساد البيانات، أو تسريب معلومات شخصية. ليس مضموناً أن يكون الفشل صاخباً.

لـ Protobuf آليات تطور حقيقية. تُحجز الأرقام المحذوفة، ويمكن الاحتفاظ بالحقول المجهولة في مسارات ثنائية مناسبة، وتوجد تغييرات أنواع آمنة بشروط. تسمح هذه الضوابط بتحديث المنتجين والمستهلكين تدريجياً.

لكنها لا تحدد من يملك حق تغيير العقد، وأي قواعد اختبار استُخدمت، ومن أجاز استثناءً، ومتى يمكن إنهاء النسخة القديمة. قابلية القراءة خاصية تقنية؛ الموافقة قرار مؤسسي.

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

وهكذا يمكن أن يكون application/protobuf+json صحيحاً ويظل صورة ناقصة لما دخل بوابة التحويل. لا يكشف النوع النهائي أين حصل التحويل، ولا أي مخطط وجهه، ولا ما الذي اختفى.

تنسق IANA الاسم ولا تصادق على كل حمولة

يحفظ سجل IANA لأنواع الوسائط الرموز العامة والمعلمات والمواصفات والاستخدام المقصود وجهة التحكم بالتغيير. ويجعل RFC 9996 الأسماء application/x-protobuf وapplication/x-protobuffer وapplication/x-protobuf+json أسماء مستعارة مهجورة.

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

لكن التسجيل الثنائي لا يحدد رقماً سحرياً أو امتداد ملف. ولا يفرض أي من النوعين معرف مخطط أو بصمة أو نوع رسالة أو هوية منتج أو توقيعاً أو حالة إذن. كون IETF جهة التحكم بالتسجيل لا يجعلها مُصدِرة لكل جسم يحمل ذلك الرمز.

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

لقناة الأمان حدود مختلفة

يقرر RFC 9996 أن Protobuf لا يقدم بذاته خدمات أمن أو خصوصية أو سلامة أو ضغط. يمكن لـ TLS حماية القناة، لكنه لا يسمي بصمة المخطط المتوقع. وتحد حدود الذاكرة من كلفة إدخال خبيث، لكنها لا تصلح معنى حقل صحيح قُرئ بالتعريف الخاطئ. كما يحتاج المحتوى داخل string وbytes إلى تحقق تطبيقي.

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

حتى النوع Any لا يقدم حلاً عاماً. يتضمن type URL صُمم ليشير إلى تعريف، لكن RFC 9996 يلاحظ أن فك هذا الرابط لجلب المخططات غير مدعوم في تطبيقات واسعة الاستخدام. يمكن أن يكون URL محدداً ضمن عقد محلي؛ ولا يصبح بمجرد وجوده سجل ثقة عالمي.

السلطة الفعلية تعيش خارج المحلل

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

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

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

إيصال سياق من دون تخزين الرسالة

لا يلزم نشر ملفات .proto السرية أو حشو Content-Type بمعلمات جديدة. يقترح Daniel Kade إيصال سياق للمخطط عند النقطة التي تقرر فيها المنظومة الاعتماد على الكائن المفكوك.

يسجل القسم الأول نوع الوسائط وكل معلمة تم تقييمها. ويحدد الثاني كيف اختير نوع الرسالة: endpoint أو طريقة RPC أو topic في الطابور أو URL من Any أو عرف محلي. يجب ألّا يُنسب هذا الاختيار إلى نوع الوسائط إن جاء من مكان آخر.

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

ثم تُسجل سلطة المصدر والإصدار: المستودع أو namespace والمالك المسؤول وحدث الإصدار والتوقيع أو دليل السلامة وحالة الإلغاء أو الاستبدال. الموقع المألوف لا يساوي سيطرة جارية.

لقرار التوافق خانة مستقلة: البصمتان القديمة والجديدة، والأداة والقواعد، والتغيير الكاسر، والاستثناء، والموافق، والمتأثرون. لا يملأ نجاح parser هذه الخانة.

ويثبت الإيصال تنفيذ المفكك ونسخته، وسياسة الحقول المجهولة والتعداد وUTF-8 وحدود الموارد والخيارات المؤثرة في المعنى. كما يسجل كل تحويل بين الثنائي وJSON أو نسخ حقلي أو تنقيح أو إعادة تسلسل، مع الخسائر المعروفة وبصمات الدخل والخرج حيث أمكن.

تبقى نتائج TLS والتوقيع منفصلة عن هوية المخطط. وفي النهاية يُحفظ القرار: قبول أو حجر أو رفض أو تراجع أو استبدال، مع المسؤول والنطاق والسبب ورابط التصحيح. ولا حاجة لتخزين جسم الرسالة.

هذا اقتراح تحريري من Daniel Kade، وليس مطلباً من RFC 9996 أو IANA أو مشروع Protobuf. وهو لا يجعل المخططات مركزية؛ بل يمنع بطاقة النقل من اكتساب سلطة التطبيق بالصدفة.

حدود الأدلة

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

RFC 9996 معلوماتي وليس Standards Track. ذكر هذا الوضع لا يقلل فائدته. ولا يقول المقال إن Protobuf بلا آليات تطور، أو إن JSON خطر دائماً، أو إن type URL عديم الفائدة، أو إن المخططات الخاصة يجب أن تصبح عامة.

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

المصادر