نجح عنوان الغد في التحقق، لكن مسار الطوارئ لم يُثبت بعد

الخلاصة

• يضيف المقترح تدفق ChangeSets إلى LoST كي يحدد العميل السجلات المدنية المحتمل تأثرها، ويجهز البدائل، ويتحقق منها مسبقاً عند زمن asOf مستقبلي.
• يصف الرد المستقبلي ما يعرفه الخادم لحظة الإجابة، ويحمل NO-CACHE، وقد يتغير قبل موعد النفاذ، ولا يغني عن استعلام LoST آني عند استخدام الخدمة فعلياً.
• إشعار التغيير، واستمرارية المؤشر، والتحقق المسبق، والتحضير المحلي، والتنفيذ، وتعيين وقت المكالمة، ونقل الموقع، والوصول إلى PSAP، والنتيجة التشغيلية إيصالات منفصلة.

قد يتغير الوصف القانوني للمكان من دون أن يتحرك المكان

عند منتصف الليل تصبح منطقة جزءاً من بلدية جديدة. المبنى ثابت، والوصلة ثابتة، والجهاز ثابت؛ لكن قيمة مدنية مثل A3 قد تكون صحيحة قبل الموعد وخاطئة بعده. على خادم معلومات الموقع أن يسحب السجل القديم ويفعّل الجديد في اللحظة الصحيحة.

يعالج المسودّة الحالية هذا النوع من التغيير المعروف مسبقاً. يتيح RFC 5222 أصلاً التحقق من الموقع المدني وربط الموقع ونوع الخدمة بعنوان URI. ويحدد RFC 5139 حقول العنوان. أما المقترح فيضيف PlannedChangePoll وGetChangeSet وVersions.

يحمل ChangeSet معرّفاً ووقت نفاذ وقائمة مواقع جزئية. يقارن العميل عناصرها بسجلاته، فيحدد الصفوف المحتمل تغيرها ويجهز البدائل. ويتيح asOf سؤال الخادم عن التحقق المتوقع في لحظة مستقبلية، فيما يقترح revalidateAfter موعداً لمراجعة التحقق الجاري.

هذه آلية استعداد مفيدة. لكنها لا تنفذ التغيير بمجرد وصفه.

الرد على سؤال عن الغد موسوم صراحة بأنه غير قابل للتخزين

لا يعد الخادم بأن النتيجة المستقبلية ثابتة. يجيب بما يفهمه الآن من التغييرات التي يفترض أن تسري بحلول asOf. قد تظهر خطة جديدة أو تغيير غير مخطط، ولذلك قد تختلف إجابتان عن اللحظة المستقبلية نفسها. يجب أن يحمل كل mapping مستقبلي expires="NO-CACHE".

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

حتى NO-EXPIRATION لا يعني صلاحية أبدية. إنه يقول فقط إن الخادم لا يعرف الآن تغييراً مخططاً يؤثر في النتيجة ولا يقترح موعداً محدداً لإعادة التحقق. تظل التغييرات المفاجئة ممكنة، وتظل المراجعة الدورية مطلوبة.

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

مؤشر ChangeSet ذاكرة محلية وليس اتفاقاً عالمياً

يحتفظ العميل بآخر changeSetId ثم يطلب ما بعده. قد لا يكشف نص المعرّف ترتيبه؛ الخادم هو الذي يعرف التسلسل. وإذا ضاع المؤشر، فلا يستعيد العميل إلا ما لا يزال الخادم يحتفظ به.

تسأل مراجعة الأمن عن حدود هذه الهوية: هل المعرّف محصور بخادم واحد؟ ماذا تفعل مصادفة قيمتين عند خادمين؟ هل يحتفظ العميل بطابور لكل سلطة؟ وكيف يتصرف إذا اختلفت سلطتان على الحالة التي ينبغي أن تسري في التاريخ نفسه؟ وتشير أيضاً إلى أن وصف OpenAPI لا يبدو أنه يعرّف وسيط المعرّف المطلوب للاستطلاعات اللاحقة.

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

وتطرح مراجعة العمليات فصلاً مماثلاً في مخططات XML. يبقى Relax NG في RFC 5222 هو المرجع السلطوي، بينما يقدم المقترح XML Schema أسهل استعمالاً لكنه غير سلطوي. اجتياز الأداة المريحة لا يصبح تلقائياً دليلاً على مطابقة المرجع من دون إثبات التكافؤ.

التحويل الموثوق يترك سلسلة أدلة

يحفظ إيصال الإشعار هوية الخادم والمعرّف ووقت النفاذ والموقع الجزئي والسجلات المطابقة. ويحفظ إيصال التدفق نطاق الخادم والمؤشر السابق والتسلسل ونافذة الاحتفاظ والفجوات. ويحفظ التحقق المستقبلي وقت السؤال وasOf والمدخل الدقيق والجواب وعلامة NO-CACHE.

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

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

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

النص ما زال قيد تقييم IESG

عند إغلاق البحث، وضعت أجندة IESG المراجعة 18 في اجتماع 24 سبتمبر. أظهر Datatracker حالة IESG Evaluation وثلاث مواقف DISCUSS وحاجة إلى مواقف إضافية، مع مسائل IANA غير محسومة حول تسجيل XML. وصنفت مراجعتي الأمن والعمليات النص بأنه يحتوي مسائل. هذه ليست RFC معتمدة ولا تقرير نشر ولا نتيجة توافق تشغيلي.

لا تتنبأ المقالة بالتصويت. بل تحفظ السؤال الذي يبقى بعد أي تعديل: ماذا يثبت كل إيصال، ومن يملك الانتقال التالي، وما الذي يمكن الرجوع إليه عندما لا يطابق الواقع الجدول؟

المصادر

السجلات الأولية: المسودّة الحالية وأجندة IESG ومراجعة الأمن ومراجعة العمليات وRFC 5222 وRFC 5139 وRFC 6443 وRFC 6881.