الخلاصة

  • تحدد خيارات الاختيار في RFC 5258 الأسماء التي تدخل مجموعة النتيجة، أما خيارات الإرجاع فتضيف معلومات إلى أسماء اختيرت بالفعل؛ وضياع الطلب يعني ضياع سبب ظهور كل سطر.
  • مع RECURSIVEMATCH قد يظهر أصل لأن فرعاً يحقق SUBSCRIBED، حتى إذا لم يكن الأصل مشتركاً أو حمل \NonExistent؛ وتوثق CHILDINFO هذه العلاقة السببية المؤقتة.

الصف الظاهر ليس بالضرورة صندوقاً صالحاً للتصرف

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

يحوّل LIST-EXTENDED الاكتشاف إلى سؤال كامل المعلمات. يحدد reference name والأنماط مجال المطابقة، وتقرر selection options أي الأسماء يدخل المجموعة، بينما تطلب return options معلومات عن الأسماء التي دخلتها. وتقيّد الهوية المصادق عليها وقدرات الجلسة ووقت المعالجة صحة النتيجة أكثر.

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

لا يكفي في التدقيق حفظ الصفوف النهائية. يجب حفظ الخادم والجلسة وجيل capabilities والهوية المصادق عليها وreference name والأنماط الخام وتفسيرها القانوني وخيارات الاختيار والإرجاع ووسم الأمر وكل الاستجابات غير الموسومة ووقت المعالجة. هذه هي إيصال الإجابة؛ من دونه تبدو الشجرة أوسع سلطة مما منحها البروتوكول.

الاختيار يغير العضوية، والإرجاع يشرح العضو

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

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

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

ينطوي اختيار SUBSCRIBED على خيار الإرجاع المناظر، لذلك تحمل الصفوف \Subscribed. لكن هذا لا يلغي ضرورة تسجيل السبب. ففي الترحيل أو المصالحة يختلف أن يكون الاشتراك سبب دخول الاسم عن أن يكون مجرد صفة لاحظها الخادم بعد دخول الاسم بسبب آخر.

ولا يصح اختزال LIST (SUBSCRIBED) إلى LSUB. تتطلب LIST الموسعة صفات صحيحة وكاملة بمعانيها العادية، بينما تحتفظ LSUB بسلوك تاريخي خاص. توحيد النتيجتين تحت مسمى «مجلدات مشتركة» يمحو الحد الذي جاء RFC 5258 لتثبيته.

قد يفشل الأصل في الاختبار ويظهر مع ذلك

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

يسمح RECURSIVEMATCH بإرجاع Foo مع CHILDINFO (SUBSCRIBED). يظل واجباً أن يطابق الأصل نمط LIST القانوني في الطلب. أما الفرع الذي تسبب في الإرجاع فلا يلزمه أن يطابق ذلك النمط. المعنى الدقيق للسطر هو أن فرعاً واحداً على الأقل حقق الشرط، وأن الأصل أُدرج لتوضيح مساره.

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

وتكشف قواعد صلاحية الأمر غرض الخيار. لا يجوز إرسال RECURSIVEMATCH منفرداً ولا مع REMOTE وحده، وعلى الخادم أن يرد BAD. فلا بد من معيار آخر يفسر الخيار كيف تحقق عند فرع. وهو ليس أمراً عاماً لجلب الشجرة كاملة بصورة عودية.

قد يكون الأصل موضعاً لغوياً لا صندوقاً موجوداً

لا تفرض أسماء IMAP الهرمية وجود صندوق لكل مقطع سابق. يمكن أن يوجد Customers/ABC من دون صندوق اسمه Customers. ومع ذلك تحتاج الواجهة إلى الاسم الأب لكي تضع الفرع في موضعه المفهوم.

في هذه الحالة يسمح RFC 5258 بإرجاع الأب مع \NonExistent وCHILDINFO (SUBSCRIBED). لا تناقض بينهما. الأولى تقول إن الاسم لا يشير إلى صندوق موجود وتستلزم \NoSelect؛ والثانية تقول إن فرعاً حقق الاختيار فكان سبب إرجاع الاسم.

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

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

CHILDINFO توثق السبب ولا تسمي الفرع

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

بين استجابة LIST والطلب التالي قد تحذف جلسة أخرى الفرع أو تعيد تسميته. وقد تتغير ACL. ينبغي للعميل أن يتعامل بصورة صحيحة مع بحث تالٍ لا يجد أي فرع مؤهل. المعلومة ملاحظة صحيحة عند زمن محدد، وليست مفتاحاً خارجياً دائماً.

وتفيد العلة أيضاً عند إرسال عدة أوامر LIST في pipeline. فالاستجابات غير الموسومة تحتاج إلى ربطها بالسؤال المناسب. تشكل معايير CHILDINFO ومعلمات كل طلب وترتيب الوصول سجل الاعتماد. أما الوسم النهائي وحده فلا يعيد المعنى التشغيلي لكل صف سابق.

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

ولا تساوي CHILDINFO الصفة \HasChildren. الأولى تشرح لماذا أدخل الاختيار أصلاً في النتيجة. والثانية تصف حالة الأبناء القابلين للوصول بغرض التنقل. مصدر السطر السببي وتلميح البنية ملاحظتان منفصلتان.

علامة التوسيع مرتبطة بهوية ولحظة

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

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

تعني \HasNoChildren عدم وجود صناديق أبناء قابلة للوصول للهوية الحالية. لا تعني عدم وجودها لكل الهويات. وهي ليست \NoInferiors التي تقول إن الأبناء غير موجودين ولا يمكن إنشاؤهم مستقبلاً. دمج الصفتين في علامة «ورقة دائمة» يحول الرؤية الحالية إلى استحالة بنيوية.

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

اتساع المعلومات لا يمنح الإسقاط سيادة

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

يمكن لـ LIST-STATUS إضافة الحالة، ولـ SPECIAL-USE إضافة الدور، ولـ NOTIFY وCONTEXT إضافة آليات التحديث. وتفصل ACL في RFC 4314 الحقوق عن مجرد ظهور الاسم. تجعل هذه الامتدادات الشجرة أغنى وأحدث، لكنها لا تحولها إلى جرد مستقل عن الطلب والهوية والجيل.

تثبت سجلات IANA مفردات capabilities وصفات أسماء الصناديق ومراجعها المعيارية. وجود token في السجل لا يثبت أن خادماً بعينه يعلنه أو ينفذه بصورة صحيحة أو يعرض المجال نفسه. وينقل RFC 9051 IMAP إلى صيغة أحدث، من دون أن يلغي السؤال العملي: أي أمر نُفذ، ولأي هوية، ولماذا ظهر كل سطر؟

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

المصادر