Summary

  • تطلب مسودة IANABIS المؤرخة في 26 أكتوبر من IANA إنشاء خانة Change Controller في كل سجل جديد لا يشترط أن يكون مستند التسجيل RFC صادرا في مسار IETF. وتشمل سياسة RFC Required، التي قد تقبل RFC من مسار آخر، إلى جانب الأسبقية في الطلب ومراجعة الخبير واشتراط المواصفة. أما السجلات القائمة التي تفتقر إلى الخانة فستضاف إليها مستقبلا خانات فارغة. الوثيقة ما زالت مسودة إنترنت.
  • أوصى RFC 8126 النافذ أصلا بتحديد جهة التحكم في التغيير. وفي سجل IANA الحالي لامتدادات وظائف JSONPath يظهر Glyn Normington خبيرا، بينما تسمي الإدخالات الخمسة IETF متحكما في التغيير.

بعد تخصيص القيمة تأتي سلطة تعديلها

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

يشرح RFC 8126 المعمول به أصل المسألة. فالتحكم الافتراضي في السجلات والإدخالات التي تنشأ عن RFC في مسار IETF يعود إلى IETF عبر IESG. ويوصي بتسمية المتحكم عندما يسمح السجل بإدخالات من خارج هذا المسار. كما يوصي بحقل مخصص في السجلات الجديدة التي تتبع أسبقية الطلب أو مراجعة الخبير. إذن لا تخترع مسودة IANABIS -04 فكرة جديدة؛ إنها تنقل التوصية القائمة إلى تعليمات إنشاء أوضح وأوسع.

في الإصدار -04 من مسودة IANABIS، تطلب الفقرة 11.2 من IANA إنشاء الحقل في جميع السجلات الجديدة التي لا تقتضي RFC من مسار IETF، وتعدد الأسبقية ومراجعة الخبير واشتراط المواصفة وسياسة RFC Required التي يمكن أن تستند إلى RFC من خارج مسار IETF. وتوضح الفقرة 2.5 أن الاسم المعتاد لإدخال ناتج من ذلك المسار هو IETF، لأن IESG تتصرف نيابة عنها. وتظل هناك استثناءات عندما يحدد RFC الأصلي IESG صراحة. كتابة الاسم الدقيق تحدد صاحب الصلاحية المؤسسية وتفصل بينه وبين الجهاز الذي يمارسها.

الخانة الخالية لا تنتخب صاحبها

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

هناك نموذج قائم لخانة مملوءة في سجل IANA لامتدادات وظائف JSONPath. تسمي الصفحة Glyn Normington خبيرا لإجراء Expert Review، بينما تسجل IETF جهة للتحكم في إدخالات length وcount وmatch وsearch وvalue. تجتمع وظيفتان مختلفتان في صفحة واحدة من دون خلط بينهما. هذا مثال سابق على المسودة، وليس دليلا على تنفيذ تعليماتها الجديدة.

ويبقى تعديل اسم المتحكم نفسه امتحانا للنظام. تفترض الفقرة 3.1.2 استخدام إجراء التسجيل للتعديل أيضا ما لم ينص السجل على غير ذلك. وبالنسبة لإدخالات تمت من دون RFC، يمكن لـ IANA تأكيد تحديث بيانات الاتصال أو التحكم والموافقة عليه، مع طلب رأي الخبراء أو مديري المجالات عند الحاجة. لا تكفي لوحة الاسم إذا لم تكن طريقة تغيير اللوحة واضحة.

ما زال RFC 8126 مرجع العمل الحالي، ومسودة IANABIS وثيقة عمل لدى IETF. النص النهائي وحالته لدى IESG وسجلات التنفيذ الفعلي في IANA هي الأدلة اللاحقة التي تستحق المتابعة.