الخلاصة

  • جعل RFC 2446 المنظّم صاحب السجل الرئيسي في تبادل iTIP، بينما يستطيع الحاضر إرسال COUNTER يقترح بديلاً كاملاً من دون أن يصبح هذا الاقتراح تعديلاً نافذاً على سجل المنظّم.
  • لا تكفي METHOD أو SEQUENCE أو REPLY أو نجاح التحليل النحوي أو ظهور الحدث محلياً لإثبات التفويض أو التنفيذ أو تقارب جميع الأطراف؛ فكل طبقة من هذه الطبقات تمثل دليلاً مختلفاً.

نُشر RFC 2446، iCalendar Transport-Independent Interoperability Protocol (iTIP)، في نوفمبر 1998 كوثيقة Standards Track. كان جزءاً من مجموعة قسمت مشكلة التقويم بين عدة طبقات: عرّف RFC 2445 كائنات iCalendar ونموذج البيانات، بينما عرّف RFC 2446 معاملات الجدولة المستقلة عن وسيلة النقل. ثم قدم RFC 2447 الربط باستخدام البريد الإلكتروني، قبل أن تُحدّث RFC 6047 جانب iMIP. وفي مرحلة لاحقة حل RFC 5546 محل RFC 2446، مع بقاء الفصل البنيوي بين اقتراح الحاضر وقرار المنظّم واضحاً.

هذا الفصل يبدأ من الأدوار نفسها. في نموذج iTIP يبدأ الـOrganizer التبادل ويسيطر على السجل الرئيسي، بينما يمثل المدعوون Attendees. وهذه أدوار تشغيلية في بروتوكول الجدولة، وليست الشيء نفسه الذي يعبّر عنه وسيط ROLE الوصفي في خاصية ATTENDEE. وبالمثل، لا ينبغي الخلط بين STATUS، الذي يصف حالة الإدخال ككل، وبين PARTSTAT، الذي يسجل حالة مشاركة حاضر بعينه.

بنى RFC 2446 فوق هذه الأدوار مجموعة METHODS تختلف دلالتها. PUBLISH ينشر معلومات من دون توقع دورة رد تفاعلية. REQUEST يطلب من الطرف الآخر معالجة عنصر الجدولة ويدعم الاستجابة. REPLY يبلغ حالة الحاضر. COUNTER يسمح للحاضر باقتراح تغيير، بينما DECLINECOUNTER يتيح للمنظّم رفض هذا الاقتراح. هذه ليست أسماء مختلفة للعملية نفسها؛ كل METHOD يمثل خطوة لها دلالة مختلفة في انتقال حالة الجدولة كما يحددها RFC 2446.

تظهر أهمية ذلك بوضوح في COUNTER. يمكن أن يحمل COUNTER كائن VEVENT أو VTODO بديلاً كاملاً، لكن اكتمال الكائن لا يمنح المرسل سلطة تعديل السجل الرئيسي. فلو اقترح حاضر، في مثال افتراضي، نقل اجتماع من الاثنين إلى الثلاثاء، فإن وصول COUNTER صحيح البنية لا يعني أن اجتماع الثلاثاء أصبح الموعد الرسمي. الاقتراح وصل؛ القرار لم يحدث بعد.

إذا قرر المنظّم قبول التغيير، فهو يعيد جدولة السجل من جانبه ثم يرسل REQUEST جديداً إلى الأطراف المتأثرة. وحافظ RFC 5546 على هذا الفصل، موصياً بإرسال REQUEST بعد قبول COUNTER. لذلك توجد على الأقل مرحلتان مستقلتان: اقتراح الحاضر، ثم قرار المنظّم الذي يُجسَّد في تحديث جديد يخرج من سلطة السجل الرئيسي.

ويمنع SEQUENCE اختصار هذه العملية إلى رقم واحد. في RFC 2446، يتتبع SEQUENCE مراجعات المنظّم، وليس عملية تصويت أو عداداً لموافقة الحاضرين. رسائل REPLY وREFRESH وCOUNTER وDECLINECOUNTER، وكذلك REQUEST المتعلق بالتفويض، لا ترفع SEQUENCE بسبب وظيفتها وحدها، في حين ترتبط ADD وCANCEL بزيادة التسلسل وفق قواعد البروتوكول. كذلك قد يصل REPLY متعلقاً بمراجعة أقدم، لذلك فإن مجرد رؤية رقم تسلسل أو رد لا يثبت أن كل الأطراف تعمل على الحالة نفسها.

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

كما أخذ التصميم في الحسبان بيئة store-and-forward التي لا تضمن ترتيب الوصول. قد تصل رسالة CANCEL قبل REQUEST الأصلية التي تشير إليها. يقترح RFC 2446 في حالة CANCEL غير المرتبط ذي SEQUENCE غير صفري إمكانية تعليقه انتظاراً لوصول الرسالة السابقة، مع السماح بانتهاء صلاحية هذا التعليق. وجود الرسالة إذاً لا يساوي بالضرورة وجود سياقها السابق في مخزن المستلم.

هذه التفاصيل تصبح أكثر أهمية عند التفكير في الثقة. حقول Organizer وAttendee تصف أدواراً، لكنها ليست آلية مصادقة. يمكن انتحالها إذا لم توفر طبقة النقل حماية مناسبة. ولهذا يقع إثبات هوية المرسل وسرية الرسائل ضمن آليات ربط النقل، لا ضمن أسماء خصائص iCalendar نفسها. وجود MIME أمني أو نقل موثَّق هو سؤال منفصل أيضاً عن السؤال الأعلى: هل يملك المرسل صلاحية تنفيذ الانتقال الذي يقترحه؟

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

القراءة الأدق لتاريخ iTIP تفصل سلسلة الأدلة إلى مراحل: البايتات المستلمة، وهوية المرسل الموثقة، وصلاحيته، ثم METHOD وUID وSEQUENCE، ثم PARTSTAT أو COUNTER، ثم قرار المنظّم، ثم REQUEST جديد عند الحاجة، ثم التسليم إلى الأطراف، فالحفظ المحلي، والتنبيه، وأخيراً المشاركة المرصودة. لا يمكن دمج هذه المراحل في إشارة واحدة من دون فقدان المعنى الذي حاول البروتوكول نفسه الحفاظ عليه.

وتفيد كتابات Heng Lu هنا كمنظور تحليلي حول الفصل بين النص المنشور والتنفيذ الفعلي، لكنها ليست مصدراً معيارياً لـiTIP. وجود مواصفة منشورة أو بنية صحيحة لا يثبت أن البرامج طبقتها، ولا أنها تبنت السلوك نفسه، ولا أن المستخدمين أو المنظّمين وافقوا على النتيجة. في هذا التاريخ، تكمن قيمة RFC 2446 بقدر كبير في الحدود التي رسمها بين ما تقوله الرسالة وما يقرره صاحب السلطة وما يمكن مراقبته فعلاً.

المصادر