الخلاصة

  • استخدم RFC 3940 رقمًا في نطاق المرسل لربط أجزاء NormObject وطلبات إصلاحه أثناء النقل، لا لمنح المحتوى هوية عالمية أو دائمة.
  • كان الحقل محدودًا إلى 16 بت ويمكن أن يلتف ويُعاد استخدامه؛ لذلك وجب على التطبيق تعريف الاسم الباقي في NORM_INFO أو داخل المحتوى نفسه.

تقليل الردود لم يلغ الحاجة إلى مرجع دقيق

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

لكن الإصلاح يحتاج إلى معرفة الكائن الذي تخصه القطعة أو الطلب. نشر RFC 3940 في نوفمبر 2004 بصفة تجريبية، وعرّف object_transport_id لهذه المهمة. يخصص المرسل قيمًا متزايدة ويستعمل القيمة نفسها لإرسال الكائن وإصلاحه. ومع معرّف المرسل الذي يحمله البروتوكول يستطيع المستقبل تمييز NormObject الجاري داخل الجلسة.

كان ذلك جوابًا عن سؤال النقل: إلى أي عمل جارٍ تنتمي هذه القطعة؟ ولم يكن جوابًا عن اسم السجل أو الإصدار بعد انتهاء النقل.

نوع الحاوية لم يحدد معنى الشيء

عرض NORM ثلاثة أنواع: بيانات ثابتة في الذاكرة، وملف، وتيار مستمر غير محدود. غير أن الفرق بين NORM_OBJECT_DATA وNORM_OBJECT_FILE كان تلميحًا للتخزين لدى المستقبل: ذاكرة أو وسيط غير متطاير. وباستثناء هذا الاختيار، كان كلاهما وحدة محتوى محدودة تُنقل بالطريقة نفسها. وكان للتطبيق أن يحمل مادة ثابتة داخل تيار أيضًا.

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

العداد المحدود يعود إلى البداية

بلغ طول حقل الكائن 16 بت، وأدار كل مرسل تسلسله بصورة مستقلة. الرقم المنفرد لا يكفي؛ فهو يحتاج إلى المرسل ونسخته التشغيلية والجلسة والحالة الزمنية لدى المستقبل. أقر RFC 3940 بأن القيمة قد تتكرر في جلسة طويلة جدًا أو غير محددة، ودعا المستقبل إلى إعادة المزامنة عندما يبتعد التسلسل عن الحالة المتوقعة.

ثم رسمت الوثيقة الحد بوضوح: لا تقدم ترويسات رسائل NORM تعريفًا عالميًا أو على مستوى التطبيق لمحتوى البيانات. تصلح معرّفات النقل فقط ما دام المرسل يرسل الكائن أو يصلحه. التزايد الرتيب يوفر ترتيبًا محليًا، لا تفردًا أبديًا.

في نوفمبر 2009 حل RFC 5740 محل RFC 3940، ونقل NORM إلى مسار المعايير. لكنه أبقى هذا الفصل، بل قال صراحة إن الحقل سيلتف ويتكرر في الجلسات الطويلة. نضج النقل، ولم يتحول رقمه المؤقت إلى مفتاح أرشيف.

بطاقة سياق صغيرة ترافق الشحنة

أتاح NORM_INFO للتطبيق إرفاق سياق اختياري بالكائن. كان نوع MIME مثالًا ممكنًا. يستطيع المستقبل فحص هذا السياق قبل تخصيص موارده للاستلام الموثوق، ويمكنه طلب إصلاح INFO إذا فاته.

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

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

قد تكتمل البايتات داخل السجل الخطأ

لنتصور ذاكرة مؤقتة تستخدم معرّف المرسل في البروتوكول والرقم ذي 16 بت مفتاحًا دائمًا. تفقد حالة الجلسة، ثم تعود بعد التفاف العداد. يصل كائن جديد وتُصلح كل قطعه بصورة صحيحة. ومع ذلك قد تلصق الذاكرة به عنوان الكائن القديم أو مدة صلاحيته أو أذون الوصول إليه.

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

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