الخلاصة

  • يحدد Date الوقت الذي أعلن فيه المنشئ اكتمال الرسالة واستعدادها للإرسال، لا وقت نقلها الفعلي.
  • تحتاج مرحلات Netnews إلى تاريخ محدود للـMessage-ID التي رأتها. إذا قاست القِدم من وقت التأليف، فقد ترفض مقالة دخلت الشبكة للتو بعد انتظار طويل.
  • أضاف Injection-Date ساعة دخول من دون استبدال Date. حسّن دليل القبول، لكنه لم يصادق الكاتب أو دقة الساعة أو الوصول إلى كل خادم.

مقالة الاثنين التي وصلت يوم الجمعة

ينتهي شخص من كتابة مقالته وهو بعيد عن الاتصال. يضع التطبيق Date يوم الاثنين ويحفظ النص. يوم الجمعة فقط يستطيع posting agent تقديمه إلى news server.

بالنسبة إلى الكاتب، الاثنين حقيقة سليمة: عنده اكتملت المقالة. لكن relay يحتفظ بسجل محدود قد يقرأ القيمة نفسها بطريقة أخرى. لعلها مقالة قديمة عادت بعدما حُذف سجل Message-ID الذي كان يكشف تكرارها.

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

جاء Injection-Date كتاريخ ثانٍ لا يملك حق تصحيح الأول.

ما الذي كان Date يحفظه؟

وصفت RFC 1036 عام 1987 الحقل Date، الذي كان يسمى Posted، بأنه تاريخ نشر الرسالة أصلاً إلى الشبكة. وكان يبقى بلا تغيير أثناء الانتشار، فلا يعيد كل وسيط كتابة بداية المقالة عند مروره.

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

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

منع التكرار صنع مشكلة ذاكرة

تتبادل relaying agents وserving agents مستقلة مقالات Netnews. تلزمها RFC 5537 بحفظ سجل لما قبلته ورفض عرض المقالة نفسها مرة أخرى. يوفر Message-ID مفتاح المقارنة.

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

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

حين كانت ساعة التأليف وحدها متاحة، احتُسب الوقت الذي بقيت فيه المقالة خارج الشبكة من عمرها داخل الشبكة.

سلطة أضيق للتاريخ الثاني

تعرف RFC 5536 Injection-Date بأنه تاريخ ووقت حقن المقالة في الشبكة. الغرض محدد: عند فحص المقالات القديمة، يستخدم news server وقتاً أضافه خادم عند injection بدلاً من وقت أضافه user agent أثناء التأليف.

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

الحد الحاسم هو عدم الاستبدال. تمنع RFC 5536 تعديل Date موجود عند إضافة Injection-Date. كما تنبه إلى أن ساعات agents غير متزامنة، ولذلك قد تبدو قيمة الدخول أسبق من قيمة التأليف. الفرق السالب بينهما ليس برهاناً على انعكاس السببية.

حل الاسم الموثق محل NNTP-Posting-Date المستخدم من دون مواصفة، وأصبح الاسم القديم deprecated. وحّدت المواصفة المفردات، لا الساعات.

ثلاثة أزمنة لثلاثة نطاقات

في التحسين الشائع لسجل التكرار، تعتبر RFC 5537 Injection-Date تاريخ المقالة إن وُجد، وتستخدم Date عند غيابه. تفحص المرحلات والخوادم القيم البعيدة في المستقبل، وتقارنها بالنافذة إذا طبقت cutoff.

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

تحدد RFC 3977 arrival timestamp محلياً للخادم، وتطلب أن تتبع أرقام المقالات ترتيب الوصول. ذلك الوقت يخص خادماً واحداً، لا الشبكة كلها.

  • يحفظ Date إعلان المنشئ أن المقالة اكتملت.
  • يحفظ Injection-Date عبور المقالة إلى Netnews.
  • يحفظ arrival time استقبال خادم محدد وترتيبه المحلي.

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

أبواب متعددة لا تعني أعماراً متعددة

لأسباب تتعلق بالتكرار الاحتياطي أو الشبكات المنفصلة، أمكن تقديم المقالة نفسها إلى أكثر من injecting agent. لم يكن المقصود إنشاء مقالات مستقلة؛ فعند التقاء المسارات ينبغي أن يجعل Message-ID الاستقبال مرة واحدة.

لذلك تطلب RFC 5537 أن تكون Message-ID وDate وInjection-Date متطابقة في كل نسخ proto-article. وإذا أعيد تجهيز مقالة محقونة للدخول إلى شبكة أخرى، تبقى الحقول الثلاثة بلا تعديل. تحديث التاريخ الثاني عند كل باب يمنح المقالة نفسها ولادة جديدة مراراً.

لا يعني Injection-Date ببساطة «الآن» عند أي gateway لاحق. في multiple injection يصبح جزءاً من الاستمرارية التي تجعل نقاط الدخول المتعددة تمثل نشراً واحداً.

ظل الغموض القديم داخل التوافق

تتجاهل التطبيقات السابقة الحقل الجديد وتواصل استعمال Date للـcutoff. تعترف RFC 5537 بأن تاريخ تأليف بعيداً في الماضي قد يؤدي إلى انتشار أضعف حتى مع وجود Injection-Date صحيح.

إذا كانت Message-ID وDate موجودتين، ينبغي لـposting agent إضافة التاريخ الثاني حين مضى على التأليف أكثر من يوم، ويجب عليه فعل ذلك عند التقديم إلى عدة injecting agents. يفحص injecting agent القيم المفرطة في المستقبل أو الماضي ويضيف وقته عندما تنطبق شروط البروتوكول. وبقربه من الكاتب يستطيع شرح الرفض بطريقة مفيدة.

لكن هذه الواجبات لا تغير relay قديماً. أبقى التوافق الاتصال ممكناً، وقَبِل فترة قد يتخذ فيها طرفان قرارين مختلفين بشأن المقالة نفسها.

التسجيل لا يجعل الساعة شهادة

Injection-Date ادعاء زمني من agent عند حد الدخول. ليس توقيعاً تشفيرياً، ولا إثباتاً للكاتب أو تزامن الساعة. ولا يحدد موافقة moderator، أو وقت القراءة، أو الوصول إلى جميع الخوادم، أو الحذف وفق retention محلي.

يسجل سجل حقول الرسائل لدى IANA حالياً Injection-Date حقلاً معيارياً في Netnews ويربطه بـRFC 5536. يثبت السجل الاسم المشترك، لا صحة كل قيمة ولا شمول النشر.

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