الخلاصة

  • كان الحرفي الأصلي في IMAP سلسلة مؤطرة بعدد داخل أمر واحد. بعد {n} ينتظر العميل رد الاستمرار + قبل إرسال الأوكتتات وبقية النحو.
  • أضاف RFC 2088 صيغة {n+} فألغى رحلة الانتظار، لكنه ترك الخادم الرافض أمام تصريف بيانات مسموح بها سلفاً أو إغلاق الاتصال.
  • قيد LITERAL- الإرسال بلا إذن منفصل إلى 4096 أوكتت مع بقاء الصيغة نفسها. ونشر APPENDLIMIT سياسة رفع مستقلة، ثم أدخل IMAP4rev2 الشكل المقيد في النحو الأساسي.

انتهى السطر ولم ينته الأمر

يمكن للحرفي أن يحتوي CR وLF، ولذلك لا تحده نهاية سطر. العدد هو الحد: يقرأ المستقبل الأوكتتات المعلنة، ثم يعود مباشرة إلى تحليل بقية الأمر نفسه. قد تأتي مسافة أو وسيط آخر أو حرفي ثانٍ.

ألزم RFC 2060 العميل الذي يرسل إلى الخادم بأن ينتظر طلب استمرار. فإذا اكتشف الخادم خطأ في مقدمة A001 LOGIN {11} استطاع إرسال BAD بدلاً من الدعوة، ومنع اختلاط السلسلة المرفوضة بالأمر التالي. حافظ RFC 3501 على هذه القاعدة.

لم يكن + قبولاً نهائياً لـ LOGIN أو APPEND. كان استعداداً للجزء التالي فقط. حتى {0} احتاج إلى الرد؛ فالمعنى هو السلطة لا زمن نقل الحمولة.

وهذا غير نافذة TCP. طبقة النقل تدير سعة تيار لا يعرف صندوق البريد أو الحصة. أما استمرار IMAP فهو قرار تطبيقي داخل تركيب نحوي واحد.

تفويض 1997

عرف RFC 2088 قدرة LITERAL+. إذا أعلنها الخادم جاز للعميل كتابة {n+} وإرسال العدد فوراً. وإذا غابت عاد إلى {n} المتزامنة.

لم تختفِ الحدود. يفحص الخادم العلامة في نهاية السطر، يستهلك العدد المضبوط، ثم يكمل الأمر. ما اختفى هو السؤال والجواب بين الجزأين. في اتصال مرتفع التأخير، يوفر ذلك رحلة لكل حرفي.

كان إعلان القدرة تفويضاً اختيارياً. لم يفرض العميل التحسين على خادم قديم؛ الخادم هو الذي قال مقدماً إنه يقبل المبادرة. لكن هذا التفويض غيّر لحظة الرفض الرخيص.

الرفض بعد بدء الوصول

وثق RFC 7888 في 2016 المشكلة التشغيلية. مع LITERAL+ قد يبدأ حرفي ضخم قبل أن يقرر الخادم أنه أكبر من سياسته. يمكنه قراءة n أوكتت والتخلص منها ثم رفض الأمر، فيهدر الشبكة والذاكرة والعمل. أو يرسل BYE ويغلق، فيفرض اتصالاً جديداً وربما محاولة آلية أخرى.

يمكن إرسال BAD أو NO مبكراً، لكن الحكم لا يسحب البايتات التي سمح الإعلان بإرسالها. ويظهر الثمن خصوصاً في APPEND، إذ يحمل رسالة كاملة ومرفقات. وفّر العميل زمنه، بينما ورث الخادم كلفة التنظيف.

لماذا كان الحد 4096 شيئاً واحداً فقط

حدد RFC 7888 قدرتين. يسمح LITERAL+ بالحرفيات غير المتزامنة من أي حجم ضمن الامتداد. أما LITERAL- فيسمح بها حتى 4096 أوكتت؛ وما زاد يعود إلى الانتظار.

تبقى الكتابة {n+} ولا يظهر ناقص في الحرفي. اسم القدرة المعلن هو الذي يحدد مدى التفويض، ولذلك لا يعلن الخادم LITERAL+ وLITERAL- معاً.

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

سياسة صندوق منفصلة

قدم RFC 7889 APPENDLIMIT في الشهر نفسه. يستطيع الخادم إعلان حد عام، أو دعوة العميل إلى سؤال STATUS أو LIST-STATUS عن حد كل صندوق.

يتجنب العميل رسالة تتجاوز قيمة معروفة، لكن البقاء دونها لا يضمن النجاح: أذونات الوصول والحصة وأسباب أخرى مستقلة. وعندما يجهل الحد، ينصح RFC بتجنب الحرفي غير المتزامن في APPEND.

إذن يجيب 4096 عن نطاق إذن نحوي مشترك، ويجيب APPENDLIMIT عن سياسة تشغيلية محلية. فصلهما يحفظ قاعدة عامة صغيرة ويترك قرارات المستقبل للصندوق الذي يملكها.

الانتظار داخل IMAP4rev2

أدخل RFC 9051 دلالة LITERAL- في IMAP4rev2 عام 2021. لا يتجاوز الحرفي غير المتزامن عادة 4096؛ وما فوق ذلك ينتظر. لم يلغ الإصدار الحديث التوقف، بل أبقاه قبل الالتزام الكبير بالموارد.

يسجل سجل قدرات IMAP لدى IANA الأسماء الثلاثة. وهو يثبت المعاني القياسية لا انتشارها الحالي.

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

المصادر والحدود

لا تقيس المصادر دعماً حالياً أو أداءً أو معدل إساءة. الاستمرار ليس قبولاً نهائياً، و4096 ليس حصة، وAPPENDLIMIT لا يضمن قبول الرسالة الأصغر.