الخلاصة

  • وضع iMIP قواعد حمل كائن التقويم داخل MIME، وربط قيمة method الخارجية بعملية METHOD داخل الكائن.
  • أتاح الجزء النصي فهماً بشرياً في برامج البريد غير المتخصصة، لكنه لم يكن بديلاً عن كائن التقويم ولا اقتراحاً ثانياً لموعد آخر.

البريد لم يعد مجرد سطر يقول «احضر»

قد تعرض الرسالة اسم المرسل وموضوعاً مثل «اجتماع الثلاثاء»، لكن هذه الكلمات لا تكفي لتحديد ما الذي يمكن لبرنامج تقويم آخر معالجته. فصلت عائلة معايير التقويم بين نموذج البيانات iCalendar، وتبادل عمليات الجدولة عبر iTIP، وبين وسيلة نقل تلك الرسائل. وجاء RFC 2447، المنشور عام 1998 باسم iMIP، ليحدد وصلة البريد: غلّف كائن التقويم في MIME وانقله عبر البريد الإلكتروني. لم يكن الهدف أن يتحول عنوان الرسالة إلى بروتوكول تقويم.

الجزء الذي يحتوي الكائن يجب أن يستخدم النوع text/calendar. كما يشترط RFC 2447 وجود معامل MIME اسمه method تكون قيمته مطابقة لخاصية METHOD في الكائن. بذلك تستطيع طبقة MIME التعرف على نوع العملية، بينما تبقى بيانات الجدولة داخل الكائن. إذا احتوت رسالة واحدة على كائنات مختلفة ذات طرق مختلفة، فتوضع في أجزاء text/calendar منفصلة داخل multipart/mixed. فصل الأجزاء يمنع جمع عمليتين في كتلة واحدة لا يمكن معرفة حدودها.

شرح الإنسان ليس كائناً آخر

في أواخر التسعينيات لم يكن كل برنامج بريد قادراً على قراءة بيانات التقويم. لذلك يسمح MIME بتضمين تمثيل نصي سهل القراءة مع الكائن المنظم، غالباً داخل multipart/alternative. يمكن لمستلم أن يقرأ ملخصاً عادياً؛ ويمكن لعميل تقويم أن يعالج الجزء البنيوي. المقصود أن يشرح العرضان الترتيب نفسه لقراء مختلفين.

لكن هذا لا يجعل multipart/alternative وسيلة لتقديم وقتين متنافسين. إذا احتوى الجزء الأول على VEVENT يبدأ الساعة الثانية والثاني على VEVENT يبدأ الساعة الثالثة، لم يعد الأمر اختلافاً في طريقة العرض؛ صار هناك حدثان محتملان أو تناقض. التفاوض على وقت آخر يقع في عمليات iTIP، لا في ترتيب أجزاء MIME. هذه الحدود الصغيرة تمنع نصاً توضيحياً من أن يُعامل كأنه سجل موازٍ.

تطرقت المواصفة أيضاً إلى نقل الأحرف والمرفقات. عند استخدام أحرف تتجاوز US-ASCII يجب الإعلان عن مجموعة المحارف؛ وتُستخدم ترميزات النقل المناسبة عندما لا يستطيع مسار البريد حمل البايتات كما هي. استبدل RFC 6047، الصادر عام 2010، RFC 2447 وحدّث ربط iMIP في ضوء صيغ الرسائل وS/MIME اللاحقة. هذه الأحكام تحفظ قابلية فك المحتوى، لا تثبت وصول الرسالة أو تطبيقها في تقويم المستلم.

وقد يشير كائن iCalendar إلى محتوى آخر بواسطة Content-ID أو Message-ID. أوصى RFC 2447 بإرفاق الأجزاء المشار إليها ضمن الرسالة نفسها متى أمكن، لأن الطرف المتلقي قد لا يملك الوصول أو الإذن لفتح مورد خارجي. المعرّف ليس المرفق نفسه، ولا يمنح حق الوصول إليه.

ولا تكفي حقول البريد لتحديد دور من أنشأ الموعد. فقد يعيد شخص توجيه رسالة، فيصبح Sender شخصاً آخر غير Organizer؛ كما أن برنامج البريد ليس ملزماً بنقل الدور إلى Reply-To. لذلك ينبغي استخراج ORGANIZER وATTENDEE من جزء text/calendar. وصف RFC 2447 استخدام أجزاء MIME الأمنية للمصادقة والسرية، ثم جعل RFC 6047 مصادقة S/MIME مطلوبة. ومع ذلك، لا تثبت التوقيعات إلا علاقة بين محتوى محمي وموقّع وفق آلية الثقة؛ ولا تثبت التسليم، أو معالجة التطبيق، أو موافقة المستخدم أو حضوره.

نُشر RFC 2447 في نوفمبر 1998 ضمن مسار المعايير، ثم أبطله RFC 6047 في 2010. توضح هذه السلسلة تطور وصلة نقل، لا معدل استخدام برامج التقويم. أما الدرس الدائم فهو معماري: معنى الموعد في كائن التقويم، وتغليفه في MIME، ونقله بالبريد؛ ونجاح طبقة واحدة لا يغني عن دليل الطبقات الأخرى.

المصادر