الملخص

  • تضيف المراجعة 08 من مسودة امتدادات iCalendar دور المشاركة OWNER، لكنها تنص على أنه دلالة وصفية فقط ولا يجوز أن يمنح وحده صلاحية تعديل كائن التقويم.
  • تكشف JMAP Calendars سطح التحكم الفعلي: يجب أن يطابق المشارك إحدى هويات المستخدم في الحساب، ثم تسمح حقوق التقويم الحالية وقيود الحدث بالعملية.
  • قراءة الدور، وربط الهوية، وقرار التفويض، وحفظ التغيير، وإرسال رسائل الجدولة، والمعالجة البعيدة، ورؤية المشارك للنتيجة إيصالات مستقلة.

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

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

تفصل هذه القاعدة بين ادعاء تحمله البيانات وسلطة يمارسها النظام. ويسهل الخلط بينهما في التقويم لأن الدور يصل بجوار الوقت والمكان والتكرار والمشاركين داخل واجهة واحدة قابلة للتنفيذ.

الادعاء ينتقل، أما السلطة فلا تنتقل تلقائيًا

يقدم RFC 5545 تمثيلًا قابلًا للنقل. وقد يمر الكائن نفسه عبر ملف أو رسالة أو مخزن CalDAV أو خدمة JMAP، بينما تختلف الحسابات والهويات ونماذج الحقوق. لذلك لا يمكن أن يحمل حقل الدور تفويضًا عالميًا.

تصرح المسودة بأنها لا تحدد دلالة OWNER في CalDAV. يستطيع المستقبل حفظ الدور وعرضه، لكنه لا يستطيع اختراع قاعدة كتابة لم يضعها البروتوكول. وحتى إدراجه مستقبلًا في سجلات iCalendar لدى IANA لن يصادق على المشارك أو يمنحه صلاحية؛ فالسجل ينسق الاسم والمرجع فقط.

يتفق ذلك مع مبدأ Minimum Initial Specification: يحدد التنسيق المشترك الحد الأدنى اللازم للتشغيل البيني ولا يستحوذ على القرارات المحلية اللاحقة. يمكن أن يكون OWNER مفردة مشتركة، بينما يبقى منح السلطة لدى البروتوكول والجهة المشغلة.

تجعل JMAP سلسلة القرار مرئية

تعد مسودة JMAP Calendars المستخدم مالكًا للحدث فقط إذا كان لأحد المشاركين دور owner وكان ذلك المشارك مطابقًا لإحدى ParticipantIdentity الخاصة بالمستخدم داخل الحساب.

ولا ينشئ هذا التطابق قدرة شاملة. يسمح mayWriteOwn بالإنشاء أو التعديل أو الحذف في التقويم الذي يحمل هذا الحق فقط، وعندما يملك المستخدم الحدث أو لا يكون له مالك. أما mayWriteAll وmayRSVP وmayShare وmayDelete فتمثل سلطات مختلفة.

عند CalendarEvent/set يجب على الخادم فرض الحقوق في myRights ورفض التغيير غير المسموح بخطأ forbidden. هذا الحكم هو إيصال السلطة؛ أما الدور فمجرد مدخل إلى القرار.

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

المرحلة ما تثبته ما يبقى غير مثبت
التحليل وجود OWNER في بنية صحيحة من أعلنه وهل ما زال ساريًا
مطابقة الهوية ارتباط المشارك بهوية في الحساب الحقوق على التقويم والحدث
التفويض قاعدة حالية تسمح بالعملية نجاح التغيير
التعديل الخادم قبل الحالة الجديدة إرسال رسائل الجدولة
التسليم نظام آخر استلم الرسالة تطبيقها أو عرضها
إعادة القراءة مشارك يرى التغيير تقارب كل النسخ بصورة دائمة

نجاح الحفظ لا يعني أن الاجتماع تغير للجميع

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

يوضح RFC 6638 وRFC 4791 أن التخزين والجدولة سطحان مترابطان لا حقيقة ذرية واحدة. فمجموعة التقويم وسلطة المستخدم وصندوق الإرسال ونسخة المشارك تحتاج إلى أدلة منفصلة.

يسجل المسار القابل للتدقيق بصمة الكائن، وموقع الدور، ومطابقة الهوية، وإصدار الحقوق، وحالة الأصل والخصوصية، وحكم السياسة، ومعرف التغيير وبصمتي ما قبله وما بعده، واختيار المستلمين، ونتيجة النقل، وإعادة القراءة. لا حاجة إلى تخزين محتوى الموعد الخاص؛ تكفي المعرفات والبصمات والنتائج المحدودة.

تقدم المواصفة ليس دليل تشغيل

تعرض صفحة Datatracker المراجعة 08 كمسودة لمجموعة CALENDAR EXTENSIONS مقصودة لمعيار Proposed Standard وقد طُلب نشرها. يوثق السجل التاريخي وتقرير المشرف المسار. ليست RFC بعد، ولا تثبت سلوك منتجات منشورة.

تضيف الوثيقة أيضًا SHOW-WITHOUT-TIME لكنها تؤكد أن إشارة العرض لا تغير المدة الزمنية المستخدمة لاكتشاف التعارض. الانضباط نفسه ينطبق على OWNER: المظهر لا يعيد كتابة الحالة العميقة، والوسم لا يعيد كتابة التفويض.

تدعو Running-Code Primacy إلى فحص الهوية التي حُلّت والحقوق التي حُمّلت والحكم الحقيقي للخادم. تكشف The Policy Mirror السلطة المختبئة في المطابقة والتخزين المؤقت والقيم الافتراضية. وتفصل Reality Layers بين البنية والدور والسلطة والنتيجة.

لذلك ليس سؤال القيادة «هل كتب التقويم مالكًا؟»، بل «أي نظام منح أي عملية على أي حالة، وما الدليل اللاحق على وصول التغيير إلى من يعتمدون عليه؟»

المصادر