الخلاصة

  • كان المسار القديم جزء جسم ممتداً بلا معاملات، يحمل OCTET STRING ويستخدم المعرّف mime-postscript-body؛ أما المسار الموصى به فكان جزء FTAM تُثبت هويته قيمة id-mime-ftbp-postscript في application-reference.
  • وصف المعيار المسارين إلى application/postscript بأنهما بلا تحويل. هذا يخص نسخ الحمولة، ولا يثبت قدرة المتلقي أو اعتماد FTAM أو سياسة مفسر PostScript أو نجاح الإخراج.

يمكن أن تصل وثيقتان متطابقتان داخل صندوقين بقفلين مختلفين. تطابق البصمة يثبت أن الورق لم يتغير، لكنه لا يمنح المستودع مفتاح الصندوق الآخر. بهذه الصورة يمكن قراءة الحد الذي رسمه RFC 2160.

صدر النص في يناير 1998 لتنظيم نقل PostScript بين X.400 وMIME. لم يمحُ التمثيل السابق، بل أبقاه موثقاً وفضّل FTAM. وهكذا عبّر عن مرحلة انتقال، لا عن انتقال مكتمل.

موضعان مختلفان للهوية

جاء التمثيل القديم من RFC 1494. كان Extended Body Part بلا معاملات، وبياناته OCTET STRING، ومعرّفه mime-postscript-body تحت { mixer-bp-data 2 }. وسمى النص القديم الربط مع application/postscript نسخاً للبايتات.

أما FTAM Body Part فكانت تُعرّف في FileTransferParameters.environment.application-reference بالقيمة id-mime-ftbp-postscript تحت { mixer-bp-data 6 }.

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

يفصل RFC 2157 بين أجزاء الجسم الممتدة وFTAM وقواعد تعريفها. ويضع RFC 2156 ذلك ضمن أهداف MIXER الأوسع: اتساق البوابات، تقليل فقد المعلومات، وقابلية الرجوع حيثما أمكن. تلك مبادئ تصميم، وليست قياساً لمسار محدد.

ما الذي تعنيه عبارة «بلا تحويل»؟

كتب RFC 2160 للمسارين Conversion Type: No conversion. والسبب أن كلاً من تمثيل X.400 وتمثيل MIME يحتوي تدفقاً واحداً من البايتات يمكن نسخه مباشرة.

إذا تطابقت البصمات قبل البوابة وبعدها، ثبت أن payload لم يُكتب من جديد. لكن التمثيل الخارجي تغيّر فعلاً من نوع جسم X.400 إلى media type في MIME، وكان على النظام أن يميّز بين نوعي X.400 قبل ذلك.

حفظ تدفق PostScript وحده يصون المحتوى ويمحو في الوقت نفسه دليل الحامل. ومن دون الجسم الأصلي أو بياناته الوصفية، لا يمكن لاحقاً إثبات ما إذا كانت الرسالة وصلت عبر FTAM أو عبر المسار القديم أو بعد fallback صامت.

النوع الصحيح قد يقود إلى رفض صحيح

أحال RFC 2160 تعريف النوع إلى RFC 1521. ويوضح RFC 2046 أن application/postscript برنامج PostScript، ويوصي بقوة باتفاقيات DSC. فمن دون بنية مناسبة قد يتعذر اختبار توافق الوثيقة مع بيئة معينة، وقد يرفضها النظام.

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

تثبت صفحة RFC Editor وصفحة Datatracker هوية الوثيقة، ولا تعرض صفحة البحث عن التصويبات حالياً نتيجة مطابقة. ولا يثبت أي منها سلوك منتج أو متلقٍ بعينه.

خمس طبقات للأدلة

ينبغي حفظ بصمة الحمولة، وفئة جسم X.400 ومعرّفه، ونتيجة اختبار قدرة المتلقي، وقرار سياسة المفسر، ثم النتيجة المرئية. الوصول، والتعرّف، والسماح بالتنفيذ، والرسم أحداث منفصلة.

يحصر إطار Heng Lu حول المواصفة الأولية الدنيا الطبقة المشتركة في قواعد قابلة للتحقق. وتطلب أولوية الكود العامل قياس ما ترسله الأنظمة وتقبله فعلاً. أما التمييز بين طبقات الواقع فيمنع رفع اسم النوع أو OID أو البصمة إلى مرتبة دليل على تجربة المستخدم.

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

المصادر