الخلاصة

  • جعل RFC 3404 الحل طلباً ذا نوع محدد؛ فكانت I2L وI2R وI2C وI2N تطلب الموقع ونسخة المورد والوصف والاسم الدائم، كما حفظت صيغ المفرد والجمع عدد النتائج المتوقع.
  • كانت S وA وU تحدد تمثيل الخطوة التالية بعد DDDS، أما P فكانت تخرج إلى معالجة خاصة بالتطبيق. واكتشاف المحلّل لم يكن توثيقاً له ولا للمحتوى الذي يعيده.

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

نُشر RFC 3404 على مسار المعايير في أكتوبر 2002، وحدد تطبيقات DDDS لحل URI وURN. توزعت البنية على خمس وثائق: عرض RFC 3401 العائلة، ووضع RFC 3402 الخوارزمية، وخزن RFC 3403 القواعد في سجلات NAPTR داخل DNS، وحدد RFC 3404 تطبيقات الحل، ونظم RFC 3405 نطاقي uri.arpa. وurn.arpa..

تبدأ العملية بسلسلة تخص التطبيق. في حل URI العام يُحوّل URI المطلق إلى صيغة معيارية ومشفرة، ويصبح مخططه أول مفتاح معروف، ثم يضاف إلى uri.arpa. في استعلام DNS. أما URN فيستخدم معرّف فضاء الأسماء مع urn.arpa.. بعد ذلك تعيد قواعد NAPTR كتابة المدخل أو تفوضه حتى تصل إلى نتيجة نهائية أو إلى نظام آخر.

كان تطبيقا URI وURN متطابقين تقنياً، لكن الفصل التشغيلي بينهما مقصود. امتلك حل URN مساراً مختصراً، ولم يكن من الحكمة ربط نشره بقبول محلّل عام لكل مخططات URI. وهكذا استطاع فضاء أسماء أن يقدم خدمة مفيدة من دون انتظار قرار تبنّ عالمي.

حمل حقل Services نوع الإجابة. أعادت I2L عنوان URI واحداً للموقع، وأتاحت I2Ls واحداً أو أكثر. أعادت I2R وI2Rs نسخة أو نسخاً من المورد. قدمت I2C وصفاً، وأعادت I2N اسماً من نوع URN. وحذرت الوثيقة من أن مقارنة اسمين URN قد تحتاج قواعد فضاء الأسماء، لا مجرد مقارنة حرفية.

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

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

كان ممكناً وضع اسم بروتوكول اختياري قبل خدمات الحل. لكن الاسم وحده لم يكف. طلب RFC 3404 تعريفاً مستقلاً لطريقة ترميز الطلب ودلالة الاستجابة. فكلمة HTTP لا تقول كيف يطلب العميل وصفاً بدلاً من مورد، ولا ماذا يعني نوع المحتوى، ولا كيف تُمثل عدة نتائج.

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

وصف حقل Flags بُعداً آخر. كانت S وA وU رايات نهائية في DDDS. توجه S اسم النطاق الناتج إلى استعلام SRV، وتقوده A إلى استعلام عناوين، وتنتج U عنوان URI. وتعني «نهائية» توقف حلقة DDDS، لا انتهاء الاتصال أو التوثيق أو فحص المحتوى.

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

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

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

سمح RFC 3404 بتحسين محدود داخل سجلات لها ORDER نفسه. يستطيع العميل البحث عن خدمة أنسب لقدراته، شرط أن يحافظ على مدخل خوارزمية DDDS الأساسية ومخرجها. ولا يجوز أن يعبر مسار تفويض آخر أو يفحص قيمة ORDER أعلى بعد العثور على تطابق.

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

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

انقسم الأمن على الحدود نفسها. العثور على المحلّل لا يحدد طريقة الاتصال الآمن به؛ على كل بروتوكول حل أن يصفها. حمل تشغيل uri.arpa. وurn.arpa. مخاطر الإتاحة والانتحال والتفويض. وحتى مسار DNS موثّق لا يثبت هوية النظير على مستوى التطبيق ولا أصالة المورد ولا حداثة الوصف.

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

يسجل RFC Editor ثلاثة تصويبات تحريرية. يصحح التصويبان المؤكدان 282 و787 إحالتين لمعالجة Additional Information من RFC 3404 إلى RFC 3403. ويصحح التصويب 2923، المحتفظ به لتحديث الوثيقة، أرقام المراجع في القسم 4. لا يغير أي منها الرايات أو أنواع الخدمات أو عدد النتائج.

ينبغي لإيصال التشغيل أن يحفظ المدخل المعياري، والمخطط أو فضاء الأسماء، والمفتاح الأول، واستعلام DNS، ومجموعة NAPTR الكاملة، وقرار الراية، والبروتوكول، والخدمة المطلوبة وعددها، والاختيار داخل ORDER واحد، والقاعدة المختارة، وانتقال S أو A أو U أو P، والاستعلام أو URI التالي، وترميز الطلب، والنظير الموثق، ونوع المحتوى، وصنف الكائن، والنتيجة التي استُهلكت.

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

لم يعد RFC 3404 بأن كل معرّف سيعطي كل جواب. ألزم النظام بتسمية ما يطلبه والحد الذي يعبره. وهكذا تحولت عبارة «تم الحل» من إشارة خضراء غامضة إلى ادعاء يمكن مراجعته.

المصادر