الخلاصة

  • ربطت RFC 2158 بين JPEG وGIF عبر أسماء أجزاء الجسم ومعرّفات الكائن وأنواع MIME والبايتات المنقولة بلا تحويل؛ وهي إشارات مترابطة وليست قابلة للاستبدال.
  • تطبع فقرة FTAM EMA GIF القيمة image/jpeg، مع أن العنوان واسم الجزء ومعرّف gif-image(4) تشير كلها إلى GIF.
  • يرجح السياق خطأ نسخ، لكن RFC Editor لا يسجل حالياً أي تصويب لـ RFC 2158؛ كما أن القصد المرجح أو الملصق المنشور لا يثبتان ما أصدرته أو فكّته أي بوابة منشورة.

صف واحد قطع سلسلة هويته

نُشرت RFC 2158 في يناير 1998، ووصفت مسارين قصيرين للصور بين MIME وX.400. عرّفت أجزاء الجسم الموسعة mime-jpeg-body تحت { mixer-bp-data 3 } وmime-gif-body تحت { mixer-bp-data 4 }، من دون معاملات. وسجلت أيضاً معرّفين لمرفقات FTAM خصصتهما Electronic Messaging Association.

تتبع ثلاث حالات من أصل أربع نسقاً واضحاً: يقترن جزء JPEG الموسع بـ image/jpeg؛ ويقترن FTAM EMA JPEG أيضاً بـ image/jpeg ومعرّف ينتهي بـ jpeg-image(6)؛ ويقترن جزء GIF الموسع بـ image/gif. أما القسم الرابع فعنوانه «image/gif - FTAM EMA GIF»، ويسمي الجزء FTAM EMA GIF، ويعرض مسار OID ينتهي بـ gif-image(4). لكن السطر الواقع بين هذه العلامات يطبع MIME Content-Type: image/jpeg، ثم يصف السطر التالي المعرّف بأنه مخصص لـ JPEG.

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

«لا تحويل» جعل خطأ الملصق أعلى كلفة

تقول كل خرائط RFC 2158: Conversion: None. لم يكن مطلوباً من البوابة فك صيغة نقطية ثم إعادة ترميزها إلى أخرى؛ بل ربط تمثيل X.400 بنوع MIME مع تمرير البايتات من دون تغيير. لذلك لا يحول رأس JPEG بايتات GIF إلى JPEG، ولا يحول فرع OID يحمل اسم GIF بايتات JPEG إلى GIF.

ترسم RFC 2046 الحد المهم: تحت النوع الأعلى image يحدد النوع الفرعي صيغة الصورة بعينها. ويحتفظ سجل IANA لأنواع الوسائط بإدخالين منفصلين لـ image/gif وimage/jpeg. قد يختار المستقبل مفكك الترميز انطلاقاً من الملصق، لكن الملصق يظل ادعاءً بشأن البايتات. اختيار القاعدة الصحيحة، وثبات التجزئة، ونجاح العرض ملاحظات منفصلة.

وتعزز الوثيقة المصاحبة RFC 2157 النسق؛ فجداولها تربط mime-jpeg-body بـ image/jpeg وmime-gif-body بـ image/gif. لا يعني ذلك أنها تعدّل RFC 2158 ضمناً، لكنه يوضح لماذا كان على المنفذ مطابقة أكثر من حقل.

التصحيح الواضح يظل استنتاجاً

أقوى قراءة نصية هي أن فقرة FTAM EMA GIF كان ينبغي أن تقول image/gif وأن تصف معرّفاً مخصصاً لـ GIF. يؤيد ذلك العنوان واسم الجزء وورقة OID والمداخل المجاورة. كما يربط مشروع MIXER الأسبق جزء GIF الموسع بـ image/gif، لكنه سبق فقرات FTAM، ولذلك لا يحتوي نسخة مصححة من السطر المتنازع عليه.

هنا يجب أن يتوقف التدقيق. لا تعرض نتيجة البحث عن تصويبات RFC 2158 لدى RFC Editor أي تطابق حالياً. عبارة «خطأ تحريري مرجح» تحليل مدعوم؛ أما «صُحح رسمياً» فليست مدعومة.

ولا يخبرنا النص بما نُشر في البرمجيات. ربما اتبع مورد حقل MIME حرفياً، أو فضل العنوان وOID، أو طبق تصحيحاً خاصاً، أو فحص توقيع البايتات، أو لم ينفذ مسار FTAM قط.

سطر المواصفة لا يشهد نيابة عن البوابة

لإثبات السلوك نحتاج نسخة جدول الربط، ومعرّف جزء X.400 المختار، وOID كاملاً، وحقل MIME وبايتات الإدخال، وحقول وبايتات الإخراج، والمعالج المختار، ونتيجة فك الترميز. تثبت التجزئة المتطابقة استمرارية البايتات في الخطوة المرصودة، لا صحة الملصق. ويثبت ظهور الصورة أن معالجاً واحداً قبلها، لا أن كل مستقبل سيختار المعالج نفسه.

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

المصادر