الخلاصة

  • نُشر draft-paxton-aicp-00 في 2 سبتمبر 2026، وهو مسودة إنترنت فردية نشطة بلا اعتماد أو مكانة رسمية لدى IETF، ولا مسار RFC أو مدير منطقة مسؤول أو موعد اجتماع هاتفي.
  • قد يسجل تقدم AICP الخطوات المكتملة والنشطة والإجمالية، مع نسبة اختيارية. مجموعات الخطوات هي المرجع، أما النسبة فإرشادية.
  • تنص المسودة على أن النسبة ليست احتمالاً للنجاح ولا حداً يمكن عنده افتراض أن الإلغاء آمن.
  • مرحلة العملية وحالة أثرها مستقلتان. فقد تترك العملية الفاشلة أو الملغاة أثراً جزئياً، والإلغاء طلب مستقل ومتكرر بأمان ويُنفذ بأفضل جهد.
  • يحتاج قرار التوقف ذي العواقب إلى إيصال خاص يحفظ الخطوات والمرحلة والأثر والتسلسل وحالة طلب الإلغاء والمشاهدات المعلقة وضرورة المطابقة.

رقم واحد وثلاثة أسئلة مختلفة

تعرّف صفحة Datatracker الحالية وثيقة Agent Infrastructure Control Protocol (AICP) بأنها النسخة 00 من مسودة إنترنت فردية كتبها Tihan-Nico Paxton وحُدثت في 2 سبتمبر 2026. وعبارة Standards Track في الترويسة غاية يقصدها الكاتب، لا اعتماداً مؤسسياً قائماً. لا تسجل الصفحة مسار RFC أو مدير منطقة مسؤولاً أو اجتماعاً هاتفياً. وتوضح إرشادات IETF أن أي شخص يستطيع تقديم مسودة إنترنت، وأن نشرها لا يمنحها مكانة رسمية.

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

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

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

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

المرحلة لا تختصر ما حدث في العالم

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

الاستقلال مقصود. يمكن أن تفشل العملية بعدما غيّرت مورداً خارجياً، أو تُلغى بعدما وقع جزء من التغيير، أو تنجح مع آثار جانبية. وعلى مقدم الخدمة أن يحدّث حالة الأثر بتحفظ؛ فغياب المشاهدة ليس مشاهدةً للغياب.

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

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

الإلغاء طلب وليس عودة إلى الوراء

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

يتعين على مقدم الخدمة الإبلاغ عن المرحلة النهائية وحالة الأثر، ولا يجوز له الادعاء بأن cancelled تعني أن شيئاً لم يحدث. وهذا يبطل قواعد مثل «الإلغاء آمن ما دامت النسبة أقل من 40%». ربما أرسلت الخطوة النشطة أمراً خارجياً، أو كانت خطوة مكتملة هي التغيير الوحيد، أو ربما لم تصل المشاهدة بعد.

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

كما لا تسمح النسبة بإعادة المحاولة. فالآثار المحتملة أو الجزئية أو المجهولة لا يجوز أن تؤدي إلى تكرار أعمى. يستطيع نموذج المشكلة في AICP بيان أمان المحاولة الجديدة ووجوب المطابقة قبلها. أما انتهاء المهلة أو انخفاض النسبة فلا يقدمان هذه الإجابة.

إيصال مستقل عند التوقف

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

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

وينبغي أن يبقي التغيير المتوقع منفصلاً عن التغيير المشاهد. فإذا كان يفترض أن تلغي خطوة اعتماداً ولم يأت تأكيد مستقل، تكون العبارة الدقيقة: «الإلغاء متوقع؛ الأثر مجهول». أما «أُلغي عند 35%» فلا تصف ما تعرفه المؤسسة. وunknown نتيجة صحيحة، لا خانة فارغة ينبغي ملؤها بالنسبة.

يقدم حق السجلات الدقيقة عند Heng Lu انضباطاً تحريرياً مفيداً: السجل يصف الواقع ولا يخلقه. وبالقياس، لا ينبغي للإيصال أن يخلق احتمال نجاح أو أماناً من مجرد كسر عددي. هذا تطبيق تحليلي مني، وليس قولاً إن مقال Heng Lu يفرض قاعدة على AICP أو IETF.

مقترح مفيد بلا إثبات نشر

تتضمن النسخة 00 مثالاً لدورة تحكم عبر HTTP وثوابت للبروتوكول، لكنني لم أجد فيها قسم Implementation Status. ولا تثبت المصادر التي راجعتها تنفيذاً مستقلاً أو نشراً إنتاجياً أو نتيجة تشغيل بيني أو تبنياً من IETF. وتذكرنا صفحة RFC Editor بأن مسودة الإنترنت قد تتغير أو تنتهي أو لا تصبح RFC قط.

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

المصادر

  1. IETF Datatracker: Agent Infrastructure Control Protocol
  2. أرشيف IETF: draft-paxton-aicp-00
  3. IETF: تعريف مسودات الإنترنت
  4. RFC Editor: كيف تُنشأ وثائق RFC
  5. Heng Lu: The Bill of Rights of Uniqueness Coordination