الخلاصة

  • تسجل PARTSTAT=ACCEPTED حالة مشاركة مرتبطة بمستخدم تقويم؛ ولا ترصد وصول الشخص أو بقاءه أو انتباهه أثناء الحدث.
  • يتطلب إثبات الحضور فصل المستجيب والوكالة ونسخة الموعد والتكرار والتسليم والمشاهدة الفعلية في حقول مستقلة.

قد يصل المدير بعد انتهاء اجتماع إلى قائمة جميلة: عشرون مدعواً، وثمانية عشر «قبلوا». ثم تتحول الكلمة في تقرير الأداء إلى «حضروا». لم يضف التقرير مستشعراً جديداً ولم يسأل المضيف، بل بدّل معنى حقل موجود. هنا تبدأ المشكلة.

تعرّف RFC 5545 المعامل PARTSTAT بأنه حالة مشاركة مستخدم التقويم. ومن قيم الأحداث NEEDS-ACTION وACCEPTED وDECLINED وTENTATIVE وDELEGATED. هذه مفردات تنظم الدعوات والنوايا قبل الموعد. ليست وصفاً لعبور باب، أو الانضمام إلى مكالمة، أو مدة البقاء، أو الانتباه.

ما الذي يضيفه سجل Cyrus Daboo

يمتد عمل Cyrus Daboo عبر الطبقات التي تنقل هذه الحالة. شارك في تأليف CalDAV، أي RFC 4791، وألف iTIP في RFC 5546، وشارك Bernard Desruisseaux في امتدادات جدولة CalDAV في RFC 6638. وتسرد صفحته في IETF ستاً وعشرين RFC في لقطة البحث، فيما توثق جائزة CalConnect لعام 2013 إسهامه التاريخي في قابلية تشغيل التقويمات معاً.

أما RFC 5545 فمؤلفها Bernard Desruisseaux، لا Daboo. ذكر الشخص لا يبرر محو الطبيعة التعاونية للمعايير. أهمية Daboo هنا أن RFC 5546 وRFC 6638 تكشفان رحلة الرد بين المستخدم والمنظم والخادم من دون دمج سلطاتهم.

الرد لا يملك الحدث كله

في نموذج iTIP يسيطر المنظم على نسخة الجدولة الرئيسية. يبدأ المدعو عادةً عند NEEDS-ACTION. ثم يغير PARTSTAT في خاصية ATTENDEE الخاصة به ويرسل رسالة REPLY إلى المنظم، الذي يدمجها في نسخته. حالة الحدث العامة STATUS وحالة كل مدعو PARTSTAT قراران مختلفان.

بذلك تثبت ACCEPTED في نسخة المنظم أمراً محدوداً: تحمل هذه النسخة رداً بالقبول لذلك العنوان. ولا تثبت وحدها من شغّل التطبيق، أو أن الرد ما زال مناسباً بعد التعديل، أو أن أحداً حضر لاحقاً.

ثلاثة أشخاص محتملين وراء اسم واحد

تتعامل RFC 5546 صراحةً مع التفويض. يستطيع المدعو أن يمنح مستخدماً آخر حق الحضور نيابةً عنه. ويبين SENT-BY أن مستخدم تقويم استجاب بالنيابة عن المدعو أو المنظم المحدد. قد يكون الفاعل مساعداً إدارياً أو صندوق بريد مشتركاً أو إجراءً آلياً مأذوناً.

لذلك قد تختلف هوية صاحب عنوان الدعوة عن هوية من أرسل الرد وعن هوية من حضر. حذف التفويض والاحتفاظ بكلمة «قبل» يفقد المحقق القدرة على إعادة بناء الإسناد الصحيح.

القبول مرتبط بنسخة وبموعد متكرر

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

ويضيف التكرار حدوداً أخرى. قد يقبل المستخدم السلسلة عموماً ثم يرفض جلسة واحدة أو ينقلها، ويحدد RECURRENCE-ID تلك الحالة. نسخ القبول العام إلى كل جلسة يصنع سجلاً للحضور لم يصرح به التقويم.

الخادم ينجز الجدولة ولا يشاهد الإنسان

تصف RFC 6638 «الجدولة الضمنية»: قد يؤدي حفظ مورد الجدولة أو تعديله أو حذفه إلى إرسال الخادم الرسائل اللازمة. ويمكن معالجة الرسائل الواردة آلياً. عندما يصل REPLY إلى جهة المنظم، يستطيع الخادم تحديث PARTSTAT؛ أما SCHEDULE-STATUS فيصف نتيجة تسليم الجدولة أو معالجتها. وقد يكون وكيل الجدولة SERVER أو CLIENT أو NONE.

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

إذا لزم إثبات الحضور فلتوجد خانة له

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

يحفظ سجل الأدلة الجيد حقولاً مستقلة: عنوان الدعوة، قيمة الرد، المستجيب أو ممثله، SEQUENCE، نطاق التكرار، حالة التسليم، إشارة الحدث، طريقة الرصد، النافذة الزمنية، والاستثناء أو الاعتراض. توضع PARTSTAT=ACCEPTED في خانة الرد. وإذا لم تُجمع ملاحظة للحضور، تبقى خانة الحدث فارغة.

الفراغ هنا معلومة صحيحة: التقويم يعرف الرد، ولا يعرف المشهد.