الخلاصة

  • تعذر في 29 أغسطس فتح رابطين بلا امتداد لمحضري AVTCORE وMMUSIC في IETF 84، مع أن نسخة جرى جلبها عبر rsync احتوت على ملفين مرتبطين بالجلستين.
  • وسّع موظفو IETF قائمة الامتدادات التي يجربها الخادم لتشمل PDF وHTM وصيغاً أخرى موجودة في المواد القديمة؛ وفي فحص محدود يوم 6 سبتمبر أعاد الرابطان استجابة HTTP 200.
  • وجود وثيقة في مخزن، وإمكان الوصول إليها علناً، وصحة هوية الكائن المعاد، ومطابقة بايتاته لنسخة معلنة أربع حالات منفصلة.
  • ينبغي لبيان قابل للقراءة آلياً أن يربط كل مادة بمعرف ثابت ومسار محدد ونوع وسائط وحجم وبصمة ونسخة وحالة تصحيح أو إحلال وتاريخ آخر فحص.
  • لا يحل هذا البيان محل المحضر ولا يصادق على دقته؛ بل يجعل قرار الخادم عند تفسير الاسم التاريخي قابلاً للفحص والمراجعة.

فشل الطريق وبقيت الوجهة

قال Jörg Ott في 29 أغسطس إنه لم يتمكن من الوصول، انطلاقاً من مواد IETF 84، إلى محضري AVTCORE وMMUSIC، بينما نجحت روابط مجموعات أخرى اختارها عشوائياً. واقترح في بلاغه الأول إجراء فحص آلي للروابط. وسجل أيضاً ظهور خطأ Cloudflare 1015 أثناء البحث من اتصال خلوي بعيد ورديء.

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

ربط Ott لاحقاً المشكلة باختلاف امتدادي PDF وHTM. وفي 2 سبتمبر قدم موظفو IETF التفسير التشغيلي: صفحات الاجتماعات القديمة تشير إلى أسماء محاضر بلا امتداد، والخادم كان يجرب قائمة محدودة فقط. لذلك وُسعت قائمة الاحتمالات كي تشمل .pdf و.htm وصيغاً أخرى موجودة فعلاً في البيانات، وقيل إن الحالتين المبلغ عنهما وعدداً من الحالات المشابهة ينبغي أن تعمل بعد ذلك.

وتناول الرد نفسه مسألة تقييد المعدل بحذر. فالحد، بحسب الموظفين، مرتفع ويصعب بلوغه بالتصفح العادي، وطلبوا إرفاق معرّف Cloudflare Ray ID إذا تكرر الأمر. لا ينفي ذلك استجابة 1015 التي رآها Ott، ولا يثبت انقطاعاً عاماً لخدمة المواد. خطأ اختيار الامتداد وقيد الوصول فئتان مختلفتان ولا ينبغي دمجهما في رواية واحدة.

النجاح في الفتح لا يثبت صحة الاختيار

في فحص منخفض الوتيرة يوم 6 سبتمبر، أعاد رابط محضر AVTCORE بلا امتداد ملف PDF حجمه 242,140 بايت، ويحمل قيمة Last-Modified من عام 2012. وكانت بصمة SHA-256 المرصودة 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1. أما رابط محضر MMUSIC فأعاد HTML بتاريخ تعديل من 2012 وببصمة 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214.

هذه قيم لوصف ما شوهد في ذلك التاريخ، وليست إعلاناً أبدياً عن نسخة أصلية وحيدة. كما نجح فتح مسارين ينتهيان بـ avtcore.html وmmusic.html، لكنهما أعادا بايتات وتواريخ مختلفة وصفحات تلخص المجموعتين، لا المحضرين. لذلك قد يقود تخمين امتداد مألوف إلى وثيقة حقيقية لكنها ليست الوثيقة المقصودة.

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

  1. الوجود: هل توجد مادة مرتبطة بالجلسة في مخزن أو مرآة ما؟
  2. الوصول: هل تستطيع مطالبة عامة جلب شيء الآن؟
  3. الهوية: هل الشيء المعاد هو المحضر المعلن، لا صفحة مجموعة أو مرشح اختير خطأ؟
  4. السلامة: هل تطابق البايتات النسخة المعلنة في وقت محدد؟

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

للوثيقة دورة تبدأ قبل النشر ولا تنتهي عنده

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

وتجعل إرشادات مواد الاجتماعات الحالية تقديم المحاضر إلزامياً، وتحدد الصيغ المقبولة وفترة التقديم ونافذة التصحيح. وفي 13 أغسطس، سرد تذكير من الأمانة بشأن IETF 126 جلسات كانت محاضرها لا تزال غائبة قبل الموعد النهائي في اليوم التالي، وحدد 8 سبتمبر لإجراء التصحيحات. لا تكشف تلك الرسالة الحالة النهائية. لكنها تظهر أن «لم يقدم بعد»، و«تم استلامه»، و«نُشر»، و«صُحح»، و«استُبدل»، و«يمكن الوصول إليه الآن» أوصاف مختلفة.

تعريف صارم خلف رابط مرن

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

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

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

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

المصادر

  1. بلاغ Jörg Ott عن تعذر الوصول إلى محضرين
  2. رد Carsten Bormann بشأن نسخة rsync
  3. متابعة حول امتدادي PDF وHTM
  4. تفسير موظفي IETF وإصلاح آلية الاختيار
  5. تذكير بشأن محاضر IETF 126
  6. إرشادات IETF لمواد الاجتماعات
  7. RFC 2418
  8. مواد IETF 84
  9. مسار محضر AVTCORE
  10. مسار محضر MMUSIC
  11. Lu Heng عن أولوية الشيفرة العاملة