الخلاصة

  • يعرّف RFC 9877 المعرّف geofeed1 وعلاقة الرابط geofeed ونوع الوسائط application/geofeed+csv كي يشير كائن شبكة RDAP إلى ملف عبر HTTPS.
  • يثبت الرابط وجود مسار اكتشاف في استجابة محددة، ولا يثبت وحده حداثة كل سطر أو الوجود المادي للشبكة أو مكان أي شخص.
  • يبدأ الاستخدام المنضبط بحفظ نطاق الكائن واستبعاد السجلات الخارجة عنه والتحقق من سلطة الناشر وعمر البيانات، ثم اتخاذ قرار الاستخدام في طبقة مستقلة.

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

نشر IETF الوثيقة RFC 9877 على مسار المعايير في أكتوبر 2025. وهي تسمح بوضع علاقة geofeed داخل عضو links المعتاد في كائن شبكة IP، مع عنوان HTTPS والنوع الموصى به application/geofeed+csv. أما geofeed1 فيعلن أن الخادم يتبع سلوك الامتداد.

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

ماذا يعني إعلان geofeed1؟

إذا أعلن الخادم geofeed1 ضمن rdapConformance، وجب أن يورده في استجابات البحث والاستعلام التي تحتوي كائنات شبكة IP وفي استجابة المساعدة. وإذا كان يملك عنوان geofeed لكائن بعينه وكان قادراً على إعادته، وجب أن يضيف الرابط. وقد تمنعه قيود تنظيمية أو ظروف مماثلة من ذلك.

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

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

يؤمّن HTTPS قناة النقل ويصادق نقطة الويب وفق WebPKI، لكنه لا يبرهن بمفرده أن مشغّل الموقع مخوّل بالتحدث عن كل بادئة في الملف. سلامة النقل وسلطة مورد الأرقام حلقتان مختلفتان.

الصعود إلى الأب يوسع حدود الإثبات

يفرض RFC 9082 أن يعيد استعلام IP أكثر كائن شبكة تخصيصاً يغطي العنوان أو النطاق. ويقر RFC 9877 بأن رابط geofeed قد يوجد في أب أقل تخصيصاً، لذلك يمكن للعميل النظر في الصعود التكراري.

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

يوصي RFC 8805 بالتحقق من أن الناشر صاحب سلطة على الموارد ذات الصلة. ويساعد تمهيد RFC 9224 في توجيه العميل إلى خدمة RDAP القادرة على الإدلاء ببيانات موثوقة عن وضع المورد. هذا يقوي منشأ المؤشر، لا صحة كل مدينة ولا موقع خروج الحركة ولا وجود المستخدم.

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

التوقيع يعزز السلطة ولا يجيز القرار

يصف RFC 9632، الذي أبطل RFC 9092، مصادقة اختيارية بواسطة RPKI. يمكن لتوقيع صحيح أن يربط الملف بشهادة تغطي مساحة العناوين. لكنه لا يثبت المعنى الجغرافي لكل صف، ولا يجعل الملف حديثاً، ولا يبيح استخدامه للمنع أو إنفاذ سياسة.

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

كما تكشف وتيرة الجلب عن حد مهم. يمنع RFC 9877 عمليات البحث الآنية المتكررة التي تضع حملاً غير مبرر. ويوصي RFC 9632 باتباع إشارات حداثة HTTP، وبألا يتكرر الجلب أكثر من أسبوعياً عند غيابها. استدعاء واجهة الآن لا يجعل المصدر الأسبوعي آنياً.

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