الخلاصة

  • فصل RFC 822 في أغسطس 1982 بين امتدادات البريد المنشورة رسمياً والحقول التي يعرّفها المستخدمون. لن تبدأ أسماء الفئة الأولى بـX-، فتحصل الثانية على مجال أسماء محمي.
  • ظهرت كلفة الحماية لاحقاً. طلب RFC 2068 في يناير 1997 من تطبيقات HTTP اعتبار x-gzip وx-compress مكافئين لـgzip وcompress حفاظاً على التوافق. وعرّف RFC 5064 في ديسمبر 2007 Archived-At لكنه وصف وسجّل سلفه X-Archived-At أيضاً.
  • ألغى RFC 6648 في يونيو 2012 عادة استخدام البادئة في أسماء المعاملات النصية الجديدة لبروتوكولات التطبيقات. لا يصح للبرنامج الحكم على رسمية الحقل أو أمانه من شكله؛ السجل وإجراءات التسجيل يحملان تلك المعلومات.

رف مخصص للاختبارات المحلية

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

هذا ما صنعه RFC 822 الصادر في أغسطس 1982 للبريد الإلكتروني. فرّق بين حقول الامتداد التي تنشرها الوثائق الرسمية وحقول يحددها المستخدمون. الأولى لن تبدأ بـX-؛ الثانية تحصل على منطقة محمية. يستطيع فريق عمل إضافة معلومة إلى رسائله من دون أن يطلب أولاً اعتماد اسمها في العالم كله.

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

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

دفع HTTP ثمن الاسمين مبكراً

في RFC 2068 المنشور في يناير 1997 تظهر الفاتورة في جملة تقنية محددة. حفاظاً على التوافق مع التطبيقات السابقة، ينبغي اعتبار x-gzip مكافئاً لـgzip وx-compress مكافئاً لـcompress. لم يعد لدى المعيار حرية اختيار صيغة جديدة وحيدة ثم تجاهل القديمة. كانت البرمجيات تتبادل الصيغتين بالفعل.

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

تغيرت صياغة البريد أيضاً. استبدل RFC 2822 في أبريل 2001 RFC 822 ووصف الحقول الاختيارية من دون الإبقاء على الفصل النحوي القديم بين الامتداد الرسمي وحقل المستخدم. تغير القاعدة في الكتاب لا يعيد كتابة الرسائل المخزنة، ولا يمحو الأسماء التي تتعرف إليها البرامج القائمة.

جاء مثال أكثر تحديداً في RFC 5064 الصادر في ديسمبر 2007. وضع المعيار الحقل Archived-At ليشير إلى عنوان نسخة محفوظة من الرسالة. ثم خصص فقرة لسلفه X-Archived-At حفاظاً على التوافق: يمكن للبرنامج قراءة الاسم القديم، لكن من الأفضل ألا يولّده في الرسائل الجديدة. سُجل القديم بوصفه متقادماً بجانب الاسم الجديد. عندما فاز الحقل بوضع رسمي، لم يغادر سلفه دفتر العناوين.

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

سقطت شارة «تجريبي» عن الاسم

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

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

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

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

ثمة فخ آخر في ترحيل الأسماء آلياً. قد تغير المراجعة الرسمية سلوك الحقل أو خصائصه الأمنية. عندئذ يؤدي حذف X- والتعامل مع الصورتين بوصفهما شيئاً واحداً إلى خطأ جديد. التكافؤ الذي سجله RFC 2068 خاص بزوجي الترميز المذكورين فيه؛ ليس أمراً عاماً بمحو البادئة من كل اسم.

نجاح التجربة يمنح اسمها حق البقاء

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

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

لم يفرغ RFC 6648 الدرج القديم. طلب فقط ألا يولد الاختبار القادم وفي اسمه دين تغيير مستقبلي. يمكن تسجيل حالة التجربة في سجل قابل للتحديث، وترك اسمها ثابتاً عندما يتغير حكم المؤسسة عليها.