الخلاصة

  • عرّفت RFC 6920، المنشورة في أبريل 2013، أسماء Named Information أو ni القائمة على خوارزمية تجزئة وقيمتها. تتحدد هوية الشيء بالخوارزمية وطول القيمة والقيمة نفسها، لا باسم الخادم الاختياري في العنوان.
  • يمكن تحويل اسم ni إلى رابط HTTP(S) تحت المسار /.well-known/ni/ لسؤال خادم عن البايتات. يسجل جدول IANA أسماء الخوارزميات وأطوالها، ولا يحفظ الملفات أو يسرد الخوادم التي تملك نسخها.
  • يحتاج التطبيق إلى اسم موثوق المصدر، ونسخة قابلة للجلب، وحساب يجريه العميل على المدخل الصحيح. سجل مؤرخ لاستلام الاسم والجلب والمقارنة هو الدليل على استعمال خدمة بعينها لهذه الآلية.

يستطيع العنوان البقاء والملف يتغير

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

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

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

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

عند التسليم يعود عنوان الخادم

البصمة لا تخبر العميل في أي مخزن يجد الملف. لذلك حددت RFC 6920 تحويل اسم ni إلى URL من نوع HTTP أو HTTPS يبدأ مساره بـ/.well-known/ni/. إن احتوى الاسم على خادم، استُخدم في الرابط الناتج؛ وإن خلا منه، أمكن للتطبيق اختيار خادم من سياقه. وقد يحيل ذلك الخادم الطلب إلى عنوان آخر. بعدها فقط توجد بايتات يستطيع العميل حساب بصمتها.

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

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

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

جدول الخوارزميات ليس مستودعاً للملفات

حتى يقرأ برنامجان اسماً واحداً بالطريقة نفسها، لا بد من توافقهما على أسماء الخوارزميات وأطوال القيم. ينشر سجل IANA للمعلومات المسماة هذه الأسماء والأطوال والمراجع، ومعامل ct الخاص بنوع المحتوى. تلزم RFC 6920 بدعم SHA-256 الكامل، وتتيح أشكالاً مختصرة ذات أسماء تبين طولها. تقصير القيمة يزيد فرص التصادم، لذلك لا يجوز إخفاء الطول عند المقارنة.

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

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

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