الخلاصة

  • طلب RFC 2277 من مواصفات IETF الفصل بين عناصر البروتوكول والنص، وتحديد charset، وإتاحة UTF-8، وتوفير طريقة معرّفة لحمل معلومة اللغة.
  • أنشأت هذه الواجبات سجلاً قابلاً للمراجعة في مسار المعايير، لكنها لم تثبت دعم المستقبل أو قبول التفاوض أو قواعد locale أو صحة العرض أو فهم القارئ.

نُشر RFC 2277 في يناير 1998 بوصفه BCP 18. لم يقدم ترميزاً جديداً، بل وصف السياسة التي كان IESG يطبقها على البروتوكولات الداخلة في مسار معايير IETF. ولخص إعلان IESG المعاصر الحد المطلوب: على بروتوكول النص أن يستطيع استخدام UTF-8 وحمل وسوم اللغة، وإلا احتاج إلى تبرير قوي ومسار استثناء.

كانت كلمات الإلزام موجهة إلى المواصفة. ما يبدو كلمة داخل بروتوكول تطبيقي يجب أن يصنف: أهو رمز تقرؤه الآلة أم نص موجه إلى الإنسان؟ وإذا تُركت الدولية لطبقة أخرى، وجب التأكد من أن أصحاب تلك الطبقة يعرفون مسؤوليتهم. كما ينبغي للمواصفة أن تقول هل الأسماء دولية أم مقيدة بـ US-ASCII.

هذه سياسة شفافية، وليست شهادة تشغيل. يعرّف RFC 2277 charset بأنه قواعد تحويل سلسلة octets إلى سلسلة محارف. وعلى كل بيانات المحارف أن تعلن charset، وعلى بروتوكولات النص أن تتيح UTF-8. أما البروتوكولات والمخازن القديمة فقد تحتاج إلى قيمة افتراضية أخرى، مع استخدام أسماء مسجلة للمجموعات الإضافية.

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

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

معلومة اللغة لها وظيفة أخرى. طلب RFC 2277 وسيلة لحملها، لكنه لم يشترط وجودها في كل نص. وأوصى آنذاك بوسوم RFC 1766 مع التمييز بين اللغة وPOSIX locale. فالـ locale قد يضم ترتيب الفرز وصيغ التاريخ والعملة، ويجوز للمستقبل قبول رأي المرسل في هذه القواعد أو تجاهله.

لذلك لا يثبت الوسم ar أن هذا القارئ يفهم النص. كان Accept-Language في RFC 2068 يعبر عن تفضيل، مع تنبيه إلى أن قابلية الفهم تعتمد على الفرد. كما أن مطابقة بادئة الوسم لا تعني فهم كل تنويعاته. وأوضح RFC 1766 أن وسم اللغة وحده لا يقرر عرض charset بصورة صحيحة في كل حالة، وذكر مزج اليابانية والصينية مثالاً على الحد.

أوصى RFC 2277 بجمع القرارات في قسم “Internationalization Considerations” بجوار Security Considerations. هذا القسم إيصال تصميم: يبين موضع النص، والتمثيلات، وطريق اللغة، والتفاوض، والطبقة المسؤولة. لكنه لا يثبت أن التنفيذ اتبع القرار أو أن الترجمات متسقة أو أن التحذير أدى إلى الفعل الصحيح.

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

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

تثبت المصادر سياسة 1998 وصلتها بورشة RFC 2130 وآليات MIME وHTTP واللغة آنذاك وتطور مواصفة UTF-8. ولا تثبت انتشاراً حالياً أو سلوك منتج مسمى أو تبادلاً معيناً أو فهم مستخدم.