الخلاصة

  • تسجل RFC 9517 فضاء URN الرسمي ddi؛ ويتكون الاسم من وكالة معتمدة ومورد تخصصه الوكالة وإصدار صريح.
  • يحوّل الحل اسم الوكالة إلى نطاق تحت ddi.urn.arpa، ويتبع تفويض DNS وDDDS وسجلات NAPTR، ثم يختار خدمة ويرسل URN الأصلي.
  • صحة البنية وبقاء الاسم لا يثبتان التخصيص أو تشغيل الخدمة أو سلطة المستودع أو سلامة الكائن أو حفظه. لكل طبقة إيصال مستقل.

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

نُشرت RFC 9517 في يناير 2024 بوصفها RFC معلوماتية في المسار المستقل. وهي تسجل ddi لموارد معايير Data Documentation Initiative. ليست مواصفة Standards Track ولا تمثل إجماع IETF. قيمتها التشغيلية في فصل أصحاب السلطة خلف الاسم الواحد.

الصيغة السليمة لا تعني أن الاسم خُصص

الشكل هو urn:ddi:<الوكالة>:<المورد>:<الإصدار>. تعتمد DDI Alliance معرّف الوكالة المبني على ترتيب أسماء النطاقات المعكوس. ثم تخصص الوكالة مواردها وإصداراتها ووكالاتها الفرعية.

ينشأ التفرد من التزامين: تمنع المؤسسة تكرار نطاقات الوكالات، وتمنع الوكالة التكرار داخل نطاقها. لا يرى المحلل سوى الحروف والفواصل. توضح RFC 8141 أن بدء السلسلة بـurn: ومطابقتها للقواعد لا يجعلها URN مخصصاً؛ يجب تسجيل NID واتباع عملية التخصيص المدارة.

قواعد حالة الأحرف غير موحدة. لا تفرق المقارنة بين حالة urn وddi والوكالة، لكنها تفرق في المورد والإصدار. تحويل السلسلة كلها إلى أحرف صغيرة قد يدمج موردين. اعتبار حالة الوكالة جزءاً من الهوية قد يكرر السلطة نفسها. لذلك يلزم حفظ القيمة الأصلية وأجزائها والتحويل المطبق.

علامات الفصل لا تحفظ الأرشيف

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

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

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

الحل سلسلة من عمليات التسليم

يستخرج العميل الوكالة، ويوحد حالة أحرفها، ويعكس أجزاءها المفصولة بالنقاط، ثم يضيف .ddi.urn.arpa. يعمل DNS كقاعدة DDDS. وقد يمر الطلب من urn.arpa إلى DDI Alliance ثم إلى خادم الوكالة.

تعرض NAPTR الخدمات. يمكن للعلامة النهائية u إنتاج URI، بينما تقود s إلى استعلام SRV. يختار العميل الخدمة ثم يقدم URN الأصلي. الناتج المتوقع معلومات اتصال بخدمة أو أكثر، لا المورد ولا دليلاً على أن الخدمة سليمة ومخولة.

ينبغي تسجيل المحلل والوقت وTTL وعمر الذاكرة وحالة التحقق وكل حقول NAPTR ونتيجة SRV وسبب الاختيار وهوية TLS والرد النهائي. عبارة «تم الحل» لا توضح من تكلم وبأي سلطة.

قد تعيد I2R نسخة من المورد، وتعيد I2C وصفاً، وتعيد I2L موقعاً واحداً، وتعيد I2Ls عدة مواقع. ليست هذه النتائج متبادلة. يمكن أن يبقى الوصف بعد ضياع الكائن، أو يشير عنوان حي إلى إصدار مختلف، أو تختلف المواقع. اختزالها إلى موجود يمحو نوع الدليل.

DoH يحمي وصلة ولا يوثق المورد

تصف الوثيقة الموارد بأنها معلومات عامة ذات ملف أمني منخفض، لكنها تربط أمن الحل بأمن DNS العام. قد يحمي DoH الوصلة بين العميل والمحلل المختار من التنصت والتلاعب.

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

يحافظ الاسم الدائم على السؤال فيما تتغير البنية. لكنه لا يرث سلطة الإجابة أو الحفظ أو الحقيقة.

المصادر