الملخص

  • نُشر في 14 سبتمبر التنقيح 00-01 من ميثاق Agent Communication Protocols المقترح في IETF. وما زال في مرحلة المراجعة الداخلية لدى Steering Group/IAB، ومدرجاً على جدول اجتماع IESG الهاتفي في 17 سبتمبر؛ لذلك لم تصبح Agentproto مجموعة عمل ذات ميثاق بعد.
  • يضيف النص تنسيقاً مع أعمال التقييس والمصادر المفتوحة ذات الصلة خارج IETF لفهم الممارسات المنشورة وتفادي التباعد غير الضروري.
  • تنص الجملة السابقة مباشرة على إحالة التغييرات في بروتوكولات مجموعات IETF الأخرى إلى تلك المجموعات كي تقرر كيفية معالجتها. فمسار الدليل الخارجي غير مسار القرار الداخلي.
  • يقترح Daniel Kade إيصال تنسيق بمسارين يوثق المادة الخارجية وما آلت إليه من دون تحويل التشاور إلى تفويض. هذا الاقتراح ليس شرطاً في الميثاق المقترح.

جملتان ترسمان حد السلطة

يضع النص 00-01 أمام المجموعة المحتملة ثلاثة نواتج متوازية: بروتوكولاً أساسياً لإدارة الحوار بين المستخدمين والوكلاء والأدوات، وبنية مرجعية، ووثيقة معلومات عن حالات الاستخدام والمتطلبات.

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

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

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

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

المراجعة مرحلة قائمة لا تفويض مكتمل

تسجل صفحة Datatracker الحالة بوصفها Start Chartering/Rechartering (Internal Steering Group/IAB Review)، وتذكر إدراج المقترح في اجتماع IESG الهاتفي يوم 17 سبتمبر. إدراج بند على جدول الأعمال دليل على الحركة الإجرائية، لا على النتيجة.

تظهر المقارنة مع 00-00 أربعة تغييرات. حُذفت كلمة intelligent من التعريف الافتتاحي للوكيل، وأضيف المستخدمون إلى فقرة حماية تبادل البيانات، وصُحح خطأ نحوي، وأُضيفت جملة التنسيق الخارجي.

يوفر السجل التاريخي وسجل الاقتراع سياقاً زمنياً. ففي 10 سبتمبر سأل تعليق عما إذا كان ينبغي التعاون مع جهات من خارج IETF. وسأل تعليق آخر عن حماية التبادل مع المستخدمين وعن معالم زمنية تتابع تقدم النواتج. وفي 13 سبتمبر أضيف موعد مارس 2028 لتقديم مسودة بروتوكول إدارة الحوار إلى IESG بوصفها Proposed Standard، ثم ظهر 00-01 في اليوم التالي.

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

ولا يعيد التنقيح تفسير جلسة BoF في IETF 126. فالأسئلة هناك فصلت بين النطاق والنواتج وتأسيس المجموعة، ولكل منها عدد مختلف من المشاركين. النص الجديد خطوة لاحقة في مسار الميثاق، وليس وسيلة لدمج تلك الأرقام في تفويض واحد.

ما توضحه قواعد الاتصال المؤسسي

يسند RFC 4052 إدارة علاقات الاتصال الرسمية في IETF إلى IAB، ويدعو إلى إبقائها غير رسمية قدر الإمكان، وإلى منع تكرار العمل من دون تعطيل مهمة أي منظمة. الغرض هو تنسيق الاعتماد المتبادل لا دمج الاختصاصات.

ويضع RFC 4691 حداً واضحاً لدور مسؤول الاتصال. فهو قناة ثنائية الاتجاه تجمع المعلومات التي تحتاج إليها IETF، لكنه لا يصنع موقفاً مؤسسياً بنفسه. وما ينقله باسم IETF يجب أن يستند إلى الإجماع المعني، لا إلى رأيه الشخصي.

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

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

إيصال بمسار دخول ومسار قرار

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

أما مسار القرار فيسجل ناتج Agentproto المتأثر، والمسؤول داخل IETF، ورابط النقاش، والحالة، والتعليل. ويمكن استخدام حالات محدودة مثل لوحظ، نوقش، اعتُمد، عُدّل ثم اعتُمد، رُفض، أُجّل، أو طُلب إجراء من المالك الخارجي.

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

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

المصادر

  1. ميثاق Agentproto المقترح 00-01 مع المعالم
  2. ميثاق Agentproto المقترح 00-00 مع المعالم
  3. سجل تاريخ ميثاق Agentproto
  4. اقتراع ميثاق Agentproto
  5. صفحة الميثاق المقترح
  6. RFC 4052 — إدارة IAB لعلاقات اتصال IETF
  7. RFC 4053 — إجراءات التعامل مع بيانات الاتصال
  8. RFC 4691 — إرشادات العمل كمسؤول اتصال لـIETF
  9. RFC 2418 — إرشادات وإجراءات مجموعات عمل IETF
  10. RFC 5434 — اعتبارات إنجاح جلسة BoF
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption