الخلاصة

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

ترسل منصة عدادات طاقة قراءةً إلى نظام التسوية. ترويسة الطلب هي application/protobuf، والبوابة تسمح له، والمحلّل يبني كائناً كاملاً. بعد إقفال الدورة المالية، يتبين أن المنتج أرسل MeterCorrection بينما المستهلك قرأ البايتات وفق MeterReading قديم.

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

ينشر RFC 9996، الصادر في يوليو 2026 بوصفه RFC معلوماتياً، تسميةً رسميةً طال انتظارها لتمثيلات Protocol Buffers. فائدته كبيرة عند حد الصيغة؛ وخطورته تبدأ حين تُحمّل هذه التسمية ما لم تسجله.

اسمان رسميان لطبقة تمثيل واحدة

يدل application/protobuf على التمثيل الثنائي، بينما يدل application/protobuf+json على إسقاط JSON. تحتفظ IANA بسجل النوع الثنائي وسجل نوع JSON.

ينطبق التسجيل على serialized objects، لا على ملفات تعريف الواجهات أو تعريفات الكائنات. الترميز الافتراضي للنوع الأول ثنائي. أما صيغة +json فتستخدم JSON وتتطلب UTF-8. يمكن للمعامل الاختياري version أن يعلن إصدار wire encoding في Protobuf؛ القيمة الافتراضية 1، وعلى العميل رفض إصدار لا يدعمه.

بهذا تُستبدل أسماء خاصة قديمة مثل application/x-protobuf وapplication/x-protobuffer وapplication/x-protobuf+json. تستطيع البوابات والمخازن والعملاء وأدوات الرصد الاعتماد على مفردة عامة، وهو ما ينسجم مع وظيفة تسجيل أنواع الوسائط في RFC 6838.

لكن التسجيل لا يقدم magic number أو امتداد ملف قياسياً أو fragment identifier. ولا يضيف سريةً أو سلامةً أو مصادقةً أو ضغطاً أو حمايةً من استنزاف الموارد. إنه يضيق عائلة قواعد فك الترميز، ولا يثبت هوية المرسل أو صلاحية الكائن لهذا المسار.

كلمة «إصدار» لا تعني الشيء نفسه في كل طبقة

قد تسجل المؤسسة عبارة Protobuf version 1 وتظن أنها وثّقت التوافق. في RFC 9996 يخص الرقم wire encoding فقط. أما Proto2 وProto3 وEdition 2023 وEdition 2024 فهي تحولات في لغة المخطط وسلوكها. ولكل تطبيق أيضاً مراجعة .proto، وإصدار كود مولّد، ومكتبة runtime، ونشرة خدمة.

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

لذلك يحتاج سجل الواجهة إلى حقول منفصلة: wire version، والاسم الكامل للرسالة، وبصمة descriptor، وجيل IDL، وإصدار runtime والتطبيق. دمجها في خانة واحدة يمحو الدليل اللازم لمعرفة الطبقة التي غيّرت القرار.

الرقم الميداني لا يحمل اسمه معه

يوضح دليل encoding الرسمي أن التمثيل الثنائي يحمل field numbers وwire types. لا يحمل اسم الحقل في المصدر، كما أن wire type لا يكشف declared type كاملاً. قد يكون varint عدداً أو قيمةً منطقيةً أو enum؛ وقد يكون العنصر length-delimited نصاً أو bytes أو رسالةً مضمنةً أو قيماً مكررةً مضغوطة.

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

نجاح parse يثبت أن runtime وجد تفسيراً قانونياً وفق التعريف المقدم. لا يثبت أن المنتج ومالك API وسياسة النشر اعتمدوا ذلك التعريف. قد تحدد endpoint أو RPC method أو generated client أو profile أو حزمة موقعة أو release manifest أو registry مضبوط نوع الرسالة. المهم أن يكون الربط قابلاً للتدقيق، وألا يستطيع وسيط غير مخول استبداله بمخطط آخر لمجرد أنه يقرأ البايتات.

يبين RFC 9205 أن تطبيق HTTP يتكون من methods وstatus codes وheaders وlink relations وسلوك الموارد وأنواع الوسائط. يشارك نوع الوسائط في العقد ولا يحمل العقد كله. لذا فإن غياب registry عالمي للمخططات في RFC 9996 تركٌ متعمد للسياق حيث يوجد.

وضوح ProtoJSON يغيّر المخاطر ولا يلغيها

في application/protobuf+json تظهر أسماء الحقول والقيم التعدادية. يتيح suffix +json في RFC 6839 معالجة JSON عامة وفق RFC 8259 عندما لا يحتاج المعالج إلى الدلالة الخاصة.

لكن دليل ProtoJSON يحذر من أن دعم unknown fields أضعف من الصيغة الثنائية. إضافة حقل جديد قد تجعل عميلاً قديماً يرفض الوثيقة. ظهور الأسماء على السلك يجعل تغيير الاسم كسراً محتملاً. والتحويل من binary إلى JSON ثم العودة قد يمحو معلومات لم يفهمها الوسيط وكان المستهلك اللاحق قادراً على فهمها.

لذلك يوصي دليل تحديث Proto3 بحجز أرقام الحقول المحذوفة وأسمائها. إعادة استخدام الرقم قد تعطي السجلات القديمة معنى جديداً؛ وإعادة استخدام الاسم قد تربك مسارات JSON والكود المولد. لا يفرض media type هذه السياسة.

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

Any يعرّف عنواناً، ولا ينشئ جذر ثقة

يجمع نوع Any bytes مع type URL، فيبدو أنه يحمل هوية الرسالة. يسجل RFC 9996 قيداً عملياً: الفكرة الأصلية أتاحت dereference للمخطط عبر الرابط، إلا أن تطبيقات واسعة الاستخدام لا تدعم ذلك. غالباً ما يُستعمل الرابط مفتاحاً في registry محلي.

حتى مع resolver شبكي، يبقى الاكتشاف غير الاعتماد. تثبت DNS وTLS والاستجابة الناجحة جوانب من القناة، لكنها لا تثبت أن الـdescriptor هو النسخة التي أجازها المنتج ومالك الواجهة للعملية. يمكن للمحتوى أن يتغير، وللنطاق أو المستودع أن ينتقل، وللاستعلام أن يكشف أنواع الرسائل التي يعالجها العميل.

وحدة الضبط الصحيحة تجمع type URL، وبصمة الـdescriptor، والناشر أو trust root، وقناة الاقتناء، وحالة الموافقة، ونطاق العقد. يقدم discovery مرشحاً؛ ويحتاج المرشح إلى قرار آخر قبل أن يصبح مصدراً معتمداً.

deterministic لا يساوي canonical

توضح وثيقة Serialization Is Not Canonical أن رسالتين تحملان المعنى المجرد نفسه قد تنتجان بايتات مختلفة، وأن ترتيب الحقول ليس ضماناً عاماً.

يزيد deterministic serialization قابلية التكرار داخل سياق محدود، لكنه لا يصنع شكلاً canonical عبر اللغات والـbuilds وإصدارات المكتبات والمخططات. تصلح البصمة لتعريف artifact محدد؛ ولا تصلح وحدها لهوية كائن أعمال مستقلة عن المخطط.

على الأرشيف والتوقيع حفظ نوع الرسالة وبصمة الـdescriptor والـruntime وقاعدة التسلسل مع البايتات. من دون ذلك يمكن إثبات أن الأثر لم يتغير، ولا يمكن إثبات الشيء الذي كان يعنيه عند الموافقة.

أربع طبقات من الوقائع لا واقعة واحدة

يقدم إطار Heng Lu عن الحد الأدنى للمواصفة الأولية قراءةً مفيدةً لضيق RFC 9996. الاسم المشترك وإصدار السلك هما ما يحتاج الجميع إلى تنسيقه. تبقى taxonomy الرسائل وسلطة النشر والتحقق المهني قرارات محلية حتى تظهر حجة لتوحيد أوسع.

ويفصل نص طبقات الواقع بين إعلان media type، وقاعدة تفسير الـdescriptor، والكائن الذي ينتجه runtime، وتغير الحالة الذي قبله النظام. قد تكون طبقة صحيحةً وتكون التالية خاطئةً.

ثم تضع أولوية الكود العامل الدليل الأخير في الخدمة التي تحلل وتتحقق وتفوّض وتغير الحالة. ينسق السجل ما ينبغي؛ ويكشف التنفيذ ما اكتسب أثراً فعلياً.