الخلاصة

  • حدّد RFC 2049 سلوكاً مشتركاً للجهل، من دون اشتراط دعم كل subtype حاضر أو مقبل.
  • كان ترميز النقل أو charset أو النوع غير النصي المجهول يتراجع إلى application/octet-stream، ولا تُعرض البايتات الخام غير النصية كنص.
  • قصدت كلمة “safe” المرور عبر الأنظمة المعروفة المطابقة لـ RFC 821/822 ومنع العرض العرضي، لا إثبات سلامة الملف أو هوية المرسل أو التكامل أو النتيجة.

كان النظام المفتوح يحتاج إلى قاعدة لعدم المعرفة

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

اختار RFC 2049 أرضية سلوكية. ينشئ العميل MIME-Version: 1.0، ويتعرف Content-Transfer-Encoding، ويفك quoted-printable وbase64، ويميز 7bit و8bit وbinary. وإذا لم يحمل النقل الأدنى ثمانية بتات أو binary فعلى المرسل الترميز والوسم الصحيح. الوسم يصف عملية عكسية ولا يثبت تنفيذها.

إذا كان Content-Transfer-Encoding مجهولاً فلا يمنح Content-Type المألوف إذناً للتفسير. تُعامل MIME entity كلها كـ application/octet-stream: يجب أولاً استعادة سلسلة octets ثم تقرير معنى media type.

يسجل EID 5470 أن صياغة الأصل تنسب Content-Type نحوياً إلى encoding نفسه، ويقترح عبارة “MIME entity with”. وحالة Held for Document Update تعني توضيحاً مسجلاً لا نصاً استبدل المعيار بالفعل.

لا تمنح الفئة العليا سوى قدر صغير من المعرفة

في text يجب عرض US-ASCII، وعلى الأقل إبلاغ المستخدم بأي charset آخر. يمكن عرض subtype نصي مجهول بصورته الخام فقط إذا كان charset معروفاً وبعد التحويل من canonical إلى local. أما charset المجهول فيصبح octet-stream.

تتراجع subtypes المجهولة للصورة والصوت والفيديو أيضاً. وفي application يجب إمكان إزالة base64 أو quoted-printable ووضع الناتج في ملف المستخدم. الحفظ ليس إذن تشغيل. وحذر RFC 2046 من أن viewer عاماً يرث مخاطر أخطر صيغة يدعمها.

للأنواع المركبة مسار مختلف: التعرف إلى mixed وalternative وdigest، ومعاملة multipart المجهول كـ mixed، وعرض message/rfc822 تكرارياً، وتحويل message المجهول إلى octet-stream. ويصبح Content-Type المجهول كلياً octet-stream بلا parameters. الحفظ أو اختيار برنامج قرار محلي لا أمر تلقائي.

انتهى معنى “safe” قبل الفعل

قال RFC إن البيانات الموسومة جيداً آمنة للإرسال لأن النظام المطابق يستطيع معاملتها كثنائي غير مميز ولا يسكبها على شاشة مستخدم ينتظر نصاً. وكانت آمنة أيضاً بالنسبة إلى الأنظمة المعروفة المطابقة لـ RFC 821 وRFC 822: لا تكسرها ولا تكسرها تلك الأنظمة.

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

فساد MTA كان واقعاً لا ترخيصاً

اعترف النص بكثرة MTA غير المطابقة والواسعة الانتشار، وكانت تغير الرسائل لتناسب التخزين المحلي أو تكون معطلة ببساطة. قد تتغير NUL وTAB والمسافات النهائية والأسطر الطويلة والمحارف غير الثابتة والنقطة المنفردة وFrom في أول السطر. لبّى base64 أضيق أبجدية وطول سطر قابلين للنقل؛ ولم يضمن quoted-printable كل gateway مذكور.

لكن القائمة لم تكن توصية. حظر RFC 821 تغيير whitespace وطي الأسطر، ووصف RFC هذه الممارسات بأنها BAD وinvalid. مقاومة الواقع لا تحول العطل إلى قاعدة.

تسمي صفحة RFC Editor الحالية الوثيقة Draft Standard، بينما يقول النص التاريخي Standards Track ويؤرخه في نوفمبر 1996. هذا دليل نشر لا إحصاء تطبيق. ويصحح EID 3933 بحالة Verified إحالة encoded-word إلى قواعد RFC 822 وRFC 2047، من دون تحويل نص العرض إلى هوية.

كان الإرث جهلاً منضبطاً: فك المعروف، وعزل المجهول، وعدم تسمية حيازة البايتات فهماً.

المصادر