الخلاصة

  • يضيف draft-ietf-jmap-object-history-00 نسخ الكائنات السابقة والمدمّرة إلى Foo/get، لكنه يسمح للخادم بدمج التعديلات المتقاربة وحذف النسخ بأي ترتيب والتخلص من السجل بصمت عند ضغط التخزين.
  • تفيد اللقطة المستعادة في الاسترجاع، لكنها لا تحدد الفاعل أو طلب التعديل أو قرار التفويض أو الأثر اللاحق، وحتى hasMoreHistory: false لا يشهد بأن السجل كامل.

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

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

تلك هي الحدود الأساسية في JMAP Object History، الذي قُدم باسم مجموعة العمل في 15 سبتمبر. المقترح يجعل الحالة القديمة قابلة للاستعلام؛ ولا يحوّل مخزن الاستعادة إلى دفتر تدقيق.

البروتوكول يعيد حالات محفوظة، لا أحداثاً

ينظم JMAP الأساسي مجموعة طرق لكل نوع كائن: Foo/get وFoo/changes وFoo/set وFoo/query وFoo/queryChanges. مزامنة الحالة الحالية جزء قائم من البنية. يستطيع Foo/changes إخبار العميل بمعرّفات الكائنات التي تغيرت بين حالتين، لكنه لا يقدم القيم السابقة.

توسّع القدرة urn:ietf:params:jmap:object-history طريقة Foo/get. عند استخدام includeReplaced: true يمكن أن تظهر النسخ المستبدلة بجانب الكائن الحي. وعند استخدام includeDestroyed: true يمكن طلب كائنات لم تعد موجودة. وإذا استُخدما معاً، يستطيع الخادم إعادة كل النسخ التي ما زال يحتفظ بها لكائن مدمّر.

تحمل كل نسخة معرّف الكائن ذاته. يرتب objectHistory.version النسخ داخل الاستجابة، ويسجل objectHistory.replaced وقت استبدال ذلك التمثيل بتحديث أو تدمير؛ أما null فيعني أن النسخة حية.

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

تسمح لقطتان متجاورتان بحساب الفرق في القيم، لكنهما لا تثبتان أن فعلاً ذرياً واحداً هو الذي أحدث ذلك الفرق.

قد لا تكون الحلقة المفقودة قد حُفظت أصلاً

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

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

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

هذه المرونة صريحة بشأن كلفة التخزين. وهي تعني أيضاً أن عبارة «كل ما حدث» ليست طلباً صالحاً ما لم يوفر نظام أحداث منفصل العقد المفقود.

hasMoreHistory إشارة للاسترجاع وليست شهادة اكتمال

يحد historyLimit العدد الإجمالي للمدخلات ويوجه الخادم إلى إعادة الأحدث. إذا بلغ الحد لأي معرّف مطلوب، يشير hasMoreHistory: true إلى توفر عناصر أقدم محفوظة في تلك اللحظة. وإذا شمل الطلب عدة كائنات فلا يبين أيها يملك المزيد، وعلى العميل سؤال كل واحد على حدة.

القيمة true مؤقتة. يحذر المسود من إمكان حذف العناصر الأقدم قبل الطلب التالي. فالعلامة تصف ما يمكن استرجاعه في لحظة، ولا تحجز البيانات.

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

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

المدة null لا تعني الاحتفاظ إلى الأبد

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

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

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

الاستعادة والمساءلة تحتاجان إيصالين مختلفين

الواجهة مناسبة للاستعادة. يستطيع العميل سؤال Email/changes عن المعرّفات المدمّرة، ثم تمريرها إلى Email/get وطلب الكائنات المحذوفة وعرض آخر قيمة قبل التدمير. يستعيد المستخدم محتواه من دون ادعاء أن الكائن المحذوف لا يزال حياً.

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

يمكن لسجل الكائن أن يوفر تمثيل ما قبل التغيير أو بعده، لكنه لا يملأ بقية الأعمدة. استنتاج الفاعل من مالك الكائن غير آمن. واستنتاج السلطة من تغير الحالة يتجاهل السياسة المطبقة. واستنتاج أثر خارجي من قيمة مخزنة يخلط بين قبول طبقة التحكم والتنفيذ والمشاهدة.

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

حق الوصول التاريخي ليس مجرد حق اليوم

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

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

يفصل JMAP Sharing بالفعل بين الأطراف وحالة الإذن المقصودة والوصول الفعلي. ويضيف Object History بعد الزمن: حق فحص نسخة قديمة يعتمد على حق قديم، لا على خريطة shareWith الحالية وحدها. إعادة النسخة دليل على أن الخادم قرر كشفها وفق تقييمه، لكنها ليست سجلاً كاملاً لقرار الإذن ما لم يُحفظ القرار بشكل مستقل.

أحياناً يكون السجل الصحيح ناقصاً عمداً

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

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

من الخطر الوعد بـ«تاريخ غير قابل للتغيير» فوق واجهة صُممت للسماح بالحذف. ومن الخطر أيضاً تعطيل الاستعادة لأنها ليست دفتراً جنائياً. التصميم الصحيح يفصل المخازن ويعلن حدودها.

تبني مجموعة العمل ليس نشراً تشغيلياً

وثيقة سبتمبر مطابقة تقريباً للمسود الفردي الصادر في مارس. لم يضف متن البروتوكول دليلاً جديداً؛ والتغير المهم أن المقترح أصبح يحمل اسم مجموعة عمل JMAP.

يصنف Datatracker الوثيقة WG Document في مرحلة I-D Exists. لا يوجد مدير منطقة مسؤول أو shepherd أو telechat. يترك الملخص خانة الحالة المقصودة فارغة، بينما يقول رأس المسود Standards Track. ما زالت Internet-Draft وليست RFC، ولا تثبت المصادر المجمدة تنفيذاً عاملاً أو سياسة احتفاظ في خدمة مسماة.

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

المصادر