الخلاصة

  • اقترح RFC 1049 حقل Content-Type لأجسام الرسائل المنظمة مثل PostScript وTeX وTROFF. يظل الجسم ضمن حدود ASCII التي قبلها البريد آنذاك، ويستخدم برنامج القراءة الحقل لاختيار أداة العرض.
  • أتاحت الصيغة ذكر الإصدار والموارد اللازمة للتفسير. ومع غياب وسيلة آلية لمعرفة قدرات المتلقي، احتفظ المرسل بقائمته الخاصة للأشخاص المجهزين. ووسّع RFC 2045 هذا الحقل لاحقاً في MIME.

قد تنجو الرسالة من الرحلة بحروفها كلها ثم تخسر القارئ عند الوصول. تخيل صندوق بريد في 1988 يستقبل مستند PostScript: يعرض برنامج البريد أوامر الطباعة كما هي، بينما ينتظر الإنسان معادلات وصفحة جميلة. لقد تسلّم كواليس المسرح عوض العرض. في RFC 1049، المنشور في مارس من ذلك العام، عالج Martin Sirbu هذه المفارقة باقتراح أن يعلن البريد نوع المعالجة التي يحتاج إليها جسمه.

كانت رسائل RFC 822 تحتوي حقول ترويسة محددة وجسماً من محارف ASCII. وضع المستخدمون في ذلك الجسم مواد من TROFF وTeX وScribe وSGML وDVI وPostScript. تعبر هذه المواد الطريق على هيئة محارف مقبولة، لكنها تحتاج إلى برنامج آخر كي تظهر بصورة الوثيقة المقصودة. يمنح حقل Content-Type برنامج القراءة اسماً يتعرف به إلى التقنية ويسلم الجسم إلى المعالج المناسب. يحمل مسار البريد المحارف كالمعتاد؛ أما قرار العرض فيتخذ عند فتح الرسالة.

لم تكن البطاقة مجرد عبارة «ملف خاص». تبدأ بقيمة للنوع، مثل POSTSCRIPT أو TROFF، مع باب لأنواع خاصة تبدأ بـX-. ويمكن أن تليها قيمة للإصدار وإشارة إلى مورد مطلوب وتعليق. ذكر Sirbu إصدارات LaserPrep لمستندات PostScript، وأدوات eqn وtbl وme الخاصة بـTROFF. معرفة اسم الطبق مفيدة، لكن الطاهي يحتاج أيضاً إلى أدوات المطبخ. بهذا جعلت إشارة المورد اعتماداً تقنياً خفياً أمراً يمكن كتابته في الرسالة.

ظهر الحساب الأصعب عند المتلقي. فالجهاز الذي يفتقر إلى المفسر يستقبل محارف ASCII، وقد يعرض الأوامر الخام وحسب. كيف يعرف المرسل من يستطيع قراءة PostScript؟ درس RFC ثلاثة طرق: قاعدة محلية لقدرات الأنظمة البعيدة، تفاوض وتحويل أثناء نقل SMTP، ودليل ينشر قدرات أجهزة الاستقبال. تحتاج القاعدة إلى تحديث دائم؛ ويتطلب التفاوض تغيير برامج بريد موجودة ولا يغطي كل المسارات بين الشبكات؛ ويجعل الدليل إرسال البريد وخدمة الأسماء جزءاً من العمل الجديد.

للبدء بالتجربة، اختار Sirbu حلاً بشرياً على نحو طريف: يحتفظ المرسل بقائمة خاصة توضح ما يستطيع كل مخاطَب قراءته. صار للوثيقة اسم موحد في الترويسة، وظل دفتر العلاقات الشخصية مسؤولاً عن قائمة المدعوين. وترك RFC لبرنامج القراءة حرية تحديد ما يفعله عند رؤية حقل صحيح. التعرف إلى النوع، وامتلاك المفسر، وإظهار صفحة مفهومة ثلاث مهام منفصلة.

العلاقة اللاحقة موثقة صراحة في RFC 2045: عمّم MIME حقل Content-Type الوارد في RFC 1049. أضاف نوع الوسيط ونوعه الفرعي ومعاملاته، وإلى جانبه حقولاً مثل MIME-Version وContent-Transfer-Encoding. وصف نص 1996 الصيغة الأقدم بأنها أبسط ومتوافقة إلى حد كبير. وتبقى لحظة 1988 مهمة بذاتها: تعلمت الرسالة أن تسمي ما بداخلها، بينما ظل العلم بما يستطيع المتلقي قراءته عند الشخص الذي يرسلها.

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