الخلاصة

  • تتحكم LANGUAGE في RFC 5255 في النصوص الثابتة المقروءة بشرياً وفي العرض المترجم لبادئات NAMESPACE، لكنها لا تغيّر فضاء الأسماء القانوني ولا هوية صندوق البريد.
  • يغيّر COMPARATOR دلالة SEARCH وSORT وTHREAD. لذلك يجب أن يسجل إثبات النتيجة فك الترميز وتحويل مجموعة المحارف وقاعدة المقارنة والرجوع المحتمل إلى i;octet.

ليست «اللغة» سلطة واحدة

تبدو التدويل في كثير من الواجهات كأنها تفضيل بسيط يختار منه المستخدم لغة الشاشة. يفصل RFC 5255 بين قرارين مختلفين جذرياً. تختار LANGUAGE اللغة التي يستخدمها الخادم في الشروح الثابتة، ويمكنها أن توفر عرضاً مترجماً لبادئات فضاء الأسماء. أما I18NLEVEL وCOMPARATOR فيحددان الكيفية التي تقارن بها السلاسل النصية أثناء تنفيذ الاستعلام.

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

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

ترجمة البادئة ليست إنشاء هوية جديدة

يرسم RFC 5255 نطاق LANGUAGE بعناية. فهي تشمل عبارات الخادم الثابتة والعرض المترجم لبادئات NAMESPACE. أما إنشاء أسماء بديلة محلية لصناديق البريد المشتركة فيقع صراحة خارج الآلية. يمنع هذا الحد العرض من التحول بصمت إلى عنوان جديد.

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

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

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

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

طبقة الحماية تنشئ جيلاً جديداً للغة

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

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

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

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

قاعدة المقارنة سياسة استعلام قابلة للتنفيذ

يميز RFC 5255 بين المقارن الافتراضي والمقارن الفعال. يعمل الأول عندما لا توجد مفاوضة أخرى، بينما يستخدم الثاني فعلياً في الجلسة. يتطلب I18NLEVEL=1 قاعدة i;unicode-casemap، ويضيف I18NLEVEL=2 إمكان اكتشاف قواعد أخرى واختيارها بأمر COMPARATOR.

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

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

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

يبدأ أصل النتيجة قبل المقارنة

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

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

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

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

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

المحتوى نفسه قد ينتج جواباً مختلفاً

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

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

ما زال سجل IANA لقدرات IMAP يدرج LANGUAGE وI18NLEVEL=1 وI18NLEVEL=2 مع الإحالة إلى RFC 5255. يثبت السجل أسماء القدرات ومراجعها. لكنه لا يثبت انتشارها في الإنتاج، ولا جودة تنفيذ معين، ولا تطابق نسخة مكتبة المقارنة بين خادمين.

دعم UTF-8 اللاحق لم يلغ حدود السلطة

لا يدعي RFC 5255 أنه جعل كل معرفات IMAP دولية. ويلاحظ قسم الأمان أن هذه الامتدادات تستخدم UTF-8 ولكن ليس للمعرفات. أضاف RFC 6855 لاحقاً دعماً أوسع لـ UTF-8 في أسماء المستخدمين وعناوين البريد والرؤوس ومعالجة أسماء الصناديق، ثم حل RFC 9051 محل IMAP4rev1 كبروتوكول أساسي.

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

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

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

المصادر