الخلاصة

  • توصي RFC 5284 بأن تتجاهل التطبيقات التكرارات الإضافية لـ USER_ERROR_SPEC وأن تمررها بلا تعديل؛ النسخ المتعددة ليست مصادر مستقلة ولا ترفع الشدة بذاتها.
  • لا يكتسب الخطأ معناه إلا من رقم المؤسسة والمنظمة الفرعية والقيمة الخاصة معاً، ثم يحتاج أي إجراء أو إصلاح إلى إيصالات منفصلة.

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

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

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

كائنان متجاوران بدلاً من بديل خفي

رسائل PathErr وResvErr في RSVP تحمل ERROR_SPEC القياسي، ورسالة Notify في RSVP-TE تفعل الشيء نفسه. يضيف RFC 5284 كائن USER_ERROR_SPEC إلى هذا الغلاف الإلزامي ولا يلغيه.

يمكن للكائن الخاص أن يرافق أي رمز خطأ معرف. وإذا لم يصلح رمز آخر، يستخدم Error Code 33 المسمى User Error Spec، ويشير الرقم الفرعي 0 إلى وجود التفاصيل في الكائن المصاحب. الرمز 33 من دون USER_ERROR_SPEC يجعل الرسالة مشوهة.

كذلك لا يسمح بالكائن إلا في PathErr أو ResvErr أو Notify. ظهوره في رسالة أخرى حالة مشوهة. أما ResvConf، فعلى الرغم من حمله ERROR_SPEC، لا يستخدم رموز الخطأ وقيمها بالمعنى الذي يحتاجه هذا الامتداد.

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

المفتاح الكامل أوسع من User Error Value

يبدأ الكائن بحقل Enterprise Number، وهو رقم مؤسسة خاص من 32 بت تعينه IANA. يأتي بعده Sub Org من 8 بت، ويمكن للمؤسسة أن تستخدمه لتقسيم فضاء القيم بين فرق تعمل بالتوازي. وعندما لا تحتاج إلى هذا التقسيم، يفضل أن يكون صفراً. ثم تأتي قيمة الخطأ الخاصة من 16 بت.

لا تحمل القيمة 25 معنى قائماً بذاته. قد تعرفها مؤسسة لحالة موارد، وتستخدمها مؤسسة أخرى لفشل اختبار. وحتى داخل المؤسسة الواحدة قد تختلف بين منظمتين فرعيتين. الهوية التشغيلية هي الثلاثي الكامل، لا الرقم الأخير.

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

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

Class 194 يضمن المرور لا الفهم

يحمل USER_ERROR_SPEC رقم Class 194 وC-Type 1. يقع الرقم ضمن مجال RSVP من 192 إلى 247، حيث يمرر التطبيق الكائن غير المعروف من دون تعديل. يستطيع عقدة قديمة الحفاظ على الامتداد حتى لو لم تعرف شيئاً عن محتواه.

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

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

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

القالب المشترك لا يجعل التفاصيل عامة

يمكن للكائن أن يتضمن كائنات فرعية يعرفها المستخدم. لها غلاف Type-Length-Value: النوع والطول كل منهما 8 بت، والطول الكلي يشملهما، ولا يقل عن أربعة بايتات ويكون مضاعفاً لأربعة. يستطيع محلل عام تحديد الحدود حتى إن لم يفهم النوع.

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

هذه الطبقات توزع المسؤولية بوضوح. المعيار يحدد الوعاء. IANA تميز مساحة المؤسسة. صاحب المساحة يصف الأنواع. المستقبل يقرر الثقة والفعل. النتيجة تقاس من مصدر آخر. لا ينبغي لأي طبقة أن تدعي إيصال الطبقة التالية.

النص تفسير مساعد لا قناة أوامر

يوفر Error Description نصاً بترميز UTF-8/Net-Unicode، مع حشو صفري حتى مضاعف أربعة بايتات. لا يشمل الطول المعلن الحشو، ويمكن أن يكون صفراً. يوصي RFC 5284 بسطر من محارف US-ASCII القابلة للطباعة حين يكون ذلك عملياً لزيادة قابلية العرض.

قد لا تستطيع كل التطبيقات إظهار النص بسبب دعم المحارف. لذلك يجب أن يبقى الوصف معلومات مساعدة، بينما توجد المعلومات الحرجة في القيمة الرقمية. وعلى التطبيق الذي لا يدعم UTF-8 استخدام أسلوب الهروب في RFC 5137.

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

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

من التسجيل إلى النتيجة سلسلة وليست خانة واحدة

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

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

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

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