الخلاصة

  • أجاز RFC 2180 أكثر من استجابة متوافقة عندما تغيّر جلسة IMAP صندوق بريد تستخدمه جلسة أخرى؛ لذلك لا يعني نجاح الأمر أن جميع الجلسات شاهدت الاسم أو البيانات نفسيهما فوراً.
  • كانت الصفقة العملية هي متانة العميل: على البرمجيات أن تصالح إشعارات EXPUNGE المتأخرة والنتائج الجزئية والرسائل الشبحية وأرقام التسلسل المتحركة، بدلاً من اعتبار سلوك خادم واحد هو البروتوكول كله.

اختفاء الاسم لم يكن بالضرورة اختفاء المحتوى

لنتخيل أن عميلين اختارا صندوق البريد FOO. يرسل العميل الأول الأمر DELETE FOO ويتلقى OK. ثم يسأل عميل ثالث عن FOO فيجيبه الخادم بأن الصندوق غير موجود. مع ذلك قد يواصل العميل الثاني، الذي اختار الصندوق قبل الحذف، إرسال FETCH أو STORE إلى محتواه.

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

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

ويظهر الانقسام نفسه عند إعادة التسمية. قد يغير الخادم سمة الاسم وحدها. يستطيع العميل الذي اختار الصندوق سابقاً مواصلة أوامر مثل FETCH، لأنها تعمل على الحالة المختارة لا على الاسم القديم. لكن APPEND FOO قد يفشل، وربما يعيد تلميح NEWNAME. هنا انفصل سطح المحتوى عن سطح فضاء الأسماء: الجلسة تحتفظ بمرجع صالح في حين لم يعد الاسم الذي بدأت به صالحاً لعميل جديد.

خريطة أرقام التسلسل قد تتقادم قبل السماح بشرح السبب

يصنع الحذف المتزامن بواسطة EXPUNGE مشكلة أدق. تمثل أرقام تسلسل رسائل IMAP مواقع داخل صندوق البريد المختار حالياً. وعندما تُحذف رسالة نهائياً تتحرك كل المواقع اللاحقة. لكن RFC 2060 يمنع استجابة EXPUNGE من مقاطعة أوامر بعينها، منها FETCH وSTORE وSEARCH. لذلك قد يتصرف عميل بينما تنتظر خريطته القديمة تحديثاً لا يحق للخادم إرساله بعد.

سجل RFC 2180 عدة معالجات مسموحة. يستطيع الخادم الاحتفاظ بنسخ شبحية زمناً يكفي للرد على FETCH القائم. وقد يعيد بيانات الرسائل التي ما زالت موجودة فقط ثم ينهي الأمر بـNO. وقد يعيد بيانات عادية للرسائل الباقية وحقولاً على هيئة NIL لما اختفى ثم ينهي بـOK. أو يتجنب الموقف كله برفض EXPUNGE حين تكون عدة جلسات متصلة بالصندوق.

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

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

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

ثبّت COPY معنى الأمر الواحد، لا حالة الصندوق كلها

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

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

مذكرة تشغيل بيني، لا وصف لكل خادم

تصنّف صفحة RFC Editor التعريفية RFC 2180 وثيقة معلوماتية. وتقول مقدمته صراحة إنه لا يعرّف توافق IMAP4 ولا يحصر جميع السلوكيات الصحيحة؛ ظل RFC 2060 مرجع الامتثال. ما سجله هو ممارسات بعض الخوادم وسلوكيات عدّتها قائمة IMAP البريدية معقولة.

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

خففت أعمال لاحقة بعض تكاليف المصالحة من دون إزالة الفصل بين طبقات الواقع. أتاح RFC 2177 للعميل في وضع IDLE تلقي تحديثات الصندوق بسرعة أكبر، لكنه لم يحول الغموض إلى معرفة. وأضاف RFC 7162 أرقام تعديل وVANISHED وآليات QRESYNC لتسريع المزامنة. ولم تجعل أي منهما OK دليلاً على تقارب عالمي فوري.

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