الخلاصة

  • أنشأ RFC 3968 سجل IANA الذي أغفله RFC 3261 لمعاملات حقول ترويسة SIP وقيمها، وربط الاسم بالحقل والمراجع المعرّفة.
  • أثبت التسجيل وجود تخصيص عام موثق وحدّ من التصادم العرضي، لكنه لم يثبت أن جهازاً معيناً فهم المعامل أو قبله أو نفّذه بصورة آمنة.

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

هذه هي الفجوة التي عالجها RFC 3968. سمح RFC 3261 بتعريف معاملات وقيم جديدة في حقول ترويسة SIP، لكنه لم ينشئ سجلاً لها لدى IANA. كان من الممكن أن تستخدم تطبيقات مستقلة الكلمة نفسها لميزتين متباينتين مع بقاء الرسالة صحيحة نحوياً.

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

غياب شجرة المورّد جعل المصدر علنياً

لم يخصص السجل مساراً مستقلاً لامتدادات المورّدين. كان التسجيل العام يتطلب RFC، لأن امتدادات SIP قد تزيد التعقيد أو تضر بالأمن. وبمصطلحات RFC 2434، كانت السياسة IETF Consensus، مع عدم اشتراط أن تكون الوثيقة على مسار المعايير.

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

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

الحقل جزء من الاسم

سمح RFC 3968 بالاسم نفسه في حقول ترويسة مختلفة، ومنع تكراره داخل الحقل الواحد. لذلك لا تكفي سلسلة مثل q أو tag أو algorithm لتعيين الكائن. لا بد من حفظ الحقل معها.

كما أن علامة Predefined Values: Yes لم تكن قائمة القيم. اختار النص التسجيل بالإحالة: تشير الخانة إلى RFC الأصلي وإلى وثائق لاحقة تضيف قيماً. وكان على المنفذ أن يتبع كل مرجع ليجمع القواعد والمعاني والشروط الأمنية.

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

دليل القدرة صدر عن المعاملة

حدد RFC 3261 أدوات أخرى لوقت التشغيل: Supported وRequire وProxy-Require وUnsupported والاستجابة 420. يستطيع طرف إعلان ميزة، أو اشتراط فهمها، أو ذكر ما لم يفهمه. هذه رسائل صادرة عن مشارك محدد في معاملة محددة.

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

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

لم يحبس الحرف دورة الحياة

حاول RFC 3427 إدارة حقول P- الأولية أو الخاصة أو الاحتكارية ومراجعتها، بسبب مخاطر الأمن والتعقيد. لكن RFC 5727 سجل أن بعض هذه الحقول انتشر خارج نطاقه المحدود، وأن قاعدة التثبيت جعلت إعادة التسمية غير عملية، فألغى المسار الخاص.

عمم RFC 6648 الدرس: لا يجوز استنتاج أن المعامل معياري أو آمن من وجود بادئة مثل X- أو غيابها. ينبغي أن تحمل البيانات الوصفية والمراجع الحالة بدلاً من هجاء الاسم.

وضم الجدول الأول مراجع مختلفة في طبيعتها: RFC 3310 للمصادقة، وRFC 3265 للأحداث، وRFC 3455 لامتدادات الشبكات الخاصة، وRFC 3329 لاتفاقات الأمن. وحّد السجل طريقة العثور عليها، لا أثرها أو مخاطرها.

لا يزال سجل IANA لمعاملات SIP فهرساً حياً لعدة سجلات فرعية. وتثبت صفحة RFC Editor وسجل التصحيحات وIETF Datatracker الحالة الوثائقية، لا قياسات التنفيذ أو الأمن.

جعل RFC 3968 السؤال «من عرّف هذا الاسم هنا؟» قابلاً للتحقق. أما «هل فهمه هذا الطرف وماذا فعل؟» فبقي سؤالاً تجيب عنه المعاملة.

المصادر