إعلان القدرة على الضغط ليس تفويضاً ولا إيصال معالجة

الخلاصة

• يفرض RFC 5402 دعم ZLIB ويطلب قيمة إصدار 1.1 أو أعلى في AS2 أو AS3 عند استخدام الضغط، لكن هذه الإشارات لا تثبت التفويض الثنائي ولا نجاح رسالة بعينها.
• يمكن أن يقع الضغط داخل التوقيع أو خارجه، ويختلف تبعاً لذلك نطاق البايتات الذي يغطيه التوقيع وMIC.
• يجب فصل القدرة المعلنة، والسياسة المتفق عليها، والإعداد الفعلي، وإيصال الاستلام، وفك الضغط، والقبول التجاري.

أربع حقائق اختصرها النظام إلى خانة واحدة

في سجل الشريك ظهر compression-supported=true. استخدم فريق التكامل القيمة كما لو أنها تجيب عن أربعة أسئلة: هل يملك الطرف الآخر مفكك ZLIB؟ هل يسمح الاتفاق باستعمال الضغط؟ هل تم ترتيب MIME والتوقيع بالطريقة المتوقعة؟ وهل نجحت هذه الرسالة؟

الحقل يجيب، في أحسن الأحوال، عن السؤال الأول في لحظة معينة. أما البقية فتحتاج إلى عقد وإعداد وملاحظة. حين تختلط هذه الطبقات، تتحول قدرة قديمة إلى إذن دائم، ثم يتحول الإذن إلى نجاح مفترض.

نُشر RFC 5402 في فبراير 2010 كوثيقة Informational في Independent Stream. وتوضح ملاحظة IESG أنها ليست مواصفة في Standards Track، وأن على القارئ توخي الحذر في تقدير قيمتها للتنفيذ والنشر. يضيف النص طبقة ضغط CMS إلى رسائل EDIINT في AS1 وAS2 وAS3؛ لا يشهد بأن منتجاً أو شريكاً طبقها الآن.

ترتيب الطبقات جزء من الاتفاق

إذا كانت الوثيقة ستوقّع، يجوز للمرسل ضغط جسم MIME الداخلي ثم توقيع الكيان المضغوط. ويجوز له أيضاً توقيع الجسم أولاً ثم ضغط بنية multipart/signed كاملة. لا يجوز الجمع بين الطريقتين في وثيقة واحدة، وعلى المستقبل دعم فك كلتيهما.

في الطريقة الأولى يغطي التوقيع CMS CompressedData. وفي الثانية يغطي MIME غير المضغوط ثم يدخل التوقيع والمحتوى معاً في طبقة ضغط خارجية. يطلب RFC 5402 أن يحسب MIC في الرسالة الموقعة على البيانات نفسها التي وُقعت أصلاً.

لذلك لا تكفي عبارة «MIC الوثيقة». يجب تسجيل ترتيب الطبقات، والنطاق الموقع، وقواعد canonicalization، والخوارزمية، والمرحلة التي تخصها القيمة. قد تكون قيمتان مختلفتان صحيحتين لتمثيلين مشروعين للمعاملة نفسها.

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

الإصدار يعلن ملفاً لا نتيجة

ينص RFC 5402 على أن التطبيق الذي يستخدم طرق الضغط المحددة يجب أن يضع قيمة 1.1 أو أعلى في حقل إصدار AS2 أو AS3. تساعد القيمة الطرف المقابل على تفسير الميزات المتوقعة.

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

يعرّف RFC 3274 نوع CMS CompressedData ومعرف خوارزمية ZLIB. لا يلزم إرسال مستوى الضغط لأن المستويات المختلفة متوافقة مع خوارزمية الفك. ومع ذلك، قد تظهر معاملات AlgorithmIdentifier محذوفة أو على شكل ASN.1 NULL بسبب تاريخ الصياغة. على التطبيقات توقع الشكلين.

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

ترميز النقل يحدد التمثيل المشاهد

إذا ظهر جسم مضغوط ثنائي في طبقة خارجية تمر عبر بروتوكول سباعي البتات مثل SMTP، يحتاج إلى base64 Content-Transfer-Encoding. وإذا كان الجسم المضغوط داخل غلاف مشفر، تنتقل الحاجة إلى الجسم المشفر الخارجي.

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

في حالات الضغط غير الموقعة، يحدد RFC 5402 MIC على المحتوى بعد فك الضغط، شاملاً رؤوس MIME وأي ترميز نقل مطبق وفق القاعدة. كما يضيف RFC 4130 قواعد canonicalization في AS2. حساب بصمة لملف XML النهائي لا يعيد بالضرورة حساب MIC.

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

إيصال الفشل يثبت الفشل المحدد

عندما يطلب إيصال ويفشل فك الضغط، يحدد RFC 5402 القيمة Error: decompression-failed داخل MDN الموقع. بعد التحقق من التوقيع، يصبح لدينا تقرير منسوب إلى الشريك عن طبقة لم يستطع تجاوزها.

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

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

ينبغي أن يفتح الخطأ مسار إعادة تشغيل يحتفظ بالبايتات وترتيب الطبقات والسياسة. تحويله فوراً إلى «رفض تجاري» قد يشغّل تعويضاً أو إعادة طلب من دون أساس.

الحزمة المتعددة لا تلغي القرارات الفردية

يسمح RFC 6362 بإرسال مرفقات متعددة داخل multipart/related. في الرسالة المضغوطة غير الموقعة، يحسب MIC على جسم multipart كله بعد فك الضغط وتطبيق canonicalization الخاصة بالنقل. إذا اختلفت القيمة، تعتبر كل المرفقات غير صالحة وتحتاج إلى إعادة إرسال.

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

يجب أن يملك السجل أصلاً أباً للتبادل وأصولاً فرعية للمرفقات من دون خلط حقول الإثبات. في الأب توجد MIME وMIC وMDN؛ وفي كل فرع Content-ID والبصمة المستخرجة والتحقق وقرار التطبيق. لا ينتقل الأخضر تلقائياً من الأب إلى الأبناء.

من القدرة إلى القبول عبر سلسلة معلنة

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

بعد ذلك يسجل توقيع MDN وشهادة الشريك ومعرف الرسالة الأصلية وdisposition. ثم تأتي المرفقات والتحقق البنيوي ومنع التكرار والسلطة التجارية والقبول.

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