الخلاصة

  • قارنت Maria Matejka، المسؤولة عن تطوير BIRD، بين NETCONF/XML وRESTCONF/JSON وCORECONF/CBOR في جلسة RIPE 93 يوم 26 أكتوبر.
  • يبين مثال في مقترحها الأصلي أن "+3" نص في JSON، لكنه قد يُقرأ رقماً بعد تحويله إلى XML.

عبرت علامة الجمع الحدود وبقي شكلها كما هو. في بداية الرحلة حملت بطاقة «نص». عند نهايتها وجدتها الآلة التالية في صف الأرقام. في إدارة الشبكات لا تقتصر مهمة مكتب الحدود هذا على نقل الأمتعة؛ فقد يحدد معنى أمر يصل إلى جهاز حي.

قدمت Maria Matejka، قائدة تطوير BIRD في CZ.NIC، محاضرتها في RIPE 93 يوم 26 أكتوبر. تتنقل شرائحها الأصلية بين NETCONF مع XML وRESTCONF مع JSON وCORECONF مع CBOR. يصف YANG نموذج البيانات المشترك، لكن كل صيغة تحمل معلومات النوع بطريقة مختلفة. كل باب جديد إلى الجهاز يضيف احتمالاً أن يتولى الوسيط تفسير بطاقة القيمة.

في مقترح فردي نشرته Matejka في مارس مثال صغير ودقيق. يسمح عنصر YANG بالنوعين int32 وstring. تصل القيمة في JSON هكذا: "item": "+3"، فتختار نوع النص وفق RFC 7951. تحمل XML الحروف +3، لكن إشارة النوع التي وفرتها علامات الاقتباس لا تعبر معها. قد يفسر الطرف التالي العنصر بوصفه عدداً. لم تتبدل الحروف؛ تبدل الموظف الذي يقرر خانتها.

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

المسألة أوسع من علامة الجمع. يمثل RFC 7951 بعض الأعداد في JSON كأرقام، بينما يمثل int64 وuint64 وdecimal64 كنصوص؛ وتضيف CBOR أشكالاً مختصرة. وسيط ينظر إلى الحروف وحدها يمكن أن يحوّل التوافق بين الواجهات إلى قرار صامت بشأن نوع البيانات. هذا قرار يحتاج إلى سجل وصاحب.

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

المصادر الأصلية