الخلاصة
- تعاملت RFC 3743 مع صيغ محددة من الأحرف الصينية واليابانية والكورية على أنها حزمة إدارية مرتبطة بصاحب واحد.
- تُفعّل الصيغ المفضلة عادةً في المنطقة، بينما تبقى صيغ أحرف أخرى محجوزة من دون أن تصبح بالضرورة تسميات نشطة في DNS. ولا تثبت الوثيقة أن سجلاً بعينه اعتمد جدولاً أو أن اسماً ما يُحلّ.
الاسم المسجّل أوسع من التسمية الظاهرة
يبدو تسجيل اسم النطاق عادةً صفقة على سلسلة واحدة: تكون متاحة، فيطلبها شخص، ثم قد تُنشر في المنطقة. تجعل أسماء النطاقات الدولية هذا التصور ناقصاً. ففي الصينية واليابانية والكورية، قد تبدو نقاط ترميز مختلفة متشابهة، أو تحمل دلالات قريبة، أو تُعدّ صيغاً بديلة بحسب اللغة والمنطقة. يستطيع DNS مقارنة التسميات المرمّزة، لكنه لا يقرر وحده متى ينبغي إسناد شكلين من Unicode إلى صاحب واحد.
هذا هو الفاصل الإداري الذي تناولته RFC 3743، وهي وثيقة معلوماتية نُشرت في أبريل 2004 عن فريق الهندسة المشترك JET. شاركت في الفريق جهات من مجتمعات معلومات الشبكة في الصين وتايوان وكوريا واليابان وغيرها. رحّبت ملاحظة IESG بربط JET السياسة بآلية تنفيذ، لكنها أوضحت أيضاً أن IETF لا تفرض سياسة على أي منطقة. يمكن تنسيق الجدول نفسه مع اختيارات محلية مختلفة.
هذه ليست مسألة تحويل تسمية Unicode إلى تمثيل ASCII المتوافق مع DNS. فقد حدّدت وثائق IDNA السابقة معالجة السلاسل وترميزها. أما RFC 3743 فتتناول طريقة إدارة المنطقة للأشكال التي قد تسبب التباساً بعد قبول التسمية: يمكن ألا تُترك صيغ مترابطة لمُسجّلين مختلفين. ويستطيع ملف تقني التحقق من صلاحية السلسلة، لكنه لا يحسم وحده كل أحكام التكافؤ بين المجتمعات اللغوية.
جدول الصيغ اللغوية يحوّل السياسة إلى إجراء
تحتفظ المنطقة بجدول Language Variant Table (LVT) لكل لغة تسمح بها. ويحدد الجدول نقاط الترميز الصحيحة والصيغ المفضلة وصيغ الأحرف البديلة. تصف هذه الفئات معاملة إدارية مختلفة، لا ترتيباً عالمياً للكتابات ولا ضماناً بأن كل تركيب يولّده الجدول كلمة مألوفة.
أثناء التسجيل، تُمرر التسمية المقترحة أولاً عبر Nameprep وفق منظومة IDNA السائدة آنذاك. ثم تتحقق جهة التسجيل من صلاحية الرموز في جدول كل لغة أُرفقت بالطلب. وبعد ذلك تولّد تركيبات الصيغ المفضلة وصيغ الأحرف، وتحذف التكرارات، وتفحص التصادم مع التسميات المسجلة والمحجوزة. ويمكن للمنطقة تصفية المرشحين وفق قواعدها. لا يحدد Unicode هذه النتائج؛ بل يحددها الجدول والإجراء المحلي.
الفارق الحاسم هو بين التفعيل والحجز. يُفعّل عادةً الاسم الأصلي والصيغ المفضلة المؤهلة، فتدخل ملف المنطقة بوصفها Zone Variants. أما صيغ الأحرف فتبقى عادةً محجوزة: لا يستطيع متقدم آخر تسجيلها، لكنها لا تُنشر بالضرورة كتسميات نشطة في DNS. وتسمي RFC 3743 المجموعة التي تضم التسمية الأصلية واللغات المرتبطة والصيغ المفعلة والمحجوزة «حزمة IDL».
تغيّر الحزمة وحدة الإدارة. ففي النموذج التقليدي يُسجّل كل اسم أو يُحذف أو يُنقل منفرداً. أما هنا فالحزمة ذرية: نقل IDL أو حذفه يؤثر في صيغ الحزمة كلها. يمنع ذلك أن يحصل صاحبان مختلفان على أشكال قررت المنطقة ربطها، لكنه يعني أيضاً أن الطلب قد يشمل تسميات لا تظهر مطلقاً في DNS النشط.
توضح أمثلة RFC أهمية اختيار اللغة. فقد يجتاز الاسم جداول لغات عدة وينتج صيغاً مفضلة مختلفة؛ وقد يفشل أيضاً لأن نقطة ترميز غير مقبولة في إحدى اللغات المختارة. هذه أمثلة لشرح الخوارزمية، وليست دليلاً على أن سجلاً معروفاً اعتمد الجدول أو أن نطاقاً تجارياً سُجّل فعلاً بهذا النموذج.
ما الذي لا يثبته الحجز
تترك RFC 3743 قرارات مهمة لكل منطقة: الجداول واللغات وسياسة النزاع والحد المقبول لعدد الصيغ وتقسيم العمل بين المسجّل وجهة التسجيل. تستخدم الأمثلة مبدأ «الأسبق أحق» أحياناً، لكن الوثيقة تسمح باستبداله بسياسة محلية للحقوق والنزاعات. ولا تثبت الوثيقة الملكية القانونية للاسم، أو تفعيل الحزمة، أو إدراج تسمية ASCII في المنطقة، أو نجاح استعلام DNS.
تساعد وثائق IDNA2008 اللاحقة على رسم الحدود: فهي تحدد الصلاحية الفنية وإجراءات التسجيل والاستعلام، مع الإقرار بأن جهات التسجيل قد تفرض قيوداً محلية إضافية. لا يحوّل هذا الاستمرار خوارزميات عصر IDNA2003 في RFC 3743 إلى قواعد بروتوكول حالية، ولا يجعل جدول JET معياراً لغوياً عالمياً. التحقق من الصلاحية، وسياسة التسجيل، والتسجيل الفعلي، والنشر في المنطقة، وحل الاسم نتائج مختلفة يجب التثبت منها كل على حدة.
كان إسهام JET التاريخي معماراً إدارياً. لم يحاول الفريق إدخال كل أحكام التكافؤ بين حروف CJK في بروتوكول DNS، بل أعطى مديري المناطق وسيلة لتحديد الخيارات المحلية وربط الأشكال ذات الصلة بصاحب واحد. يقلل ذلك نوعاً من انقسام الملكية، لكنه يزيد الاعتماد على جداول اللغة وقواعد دورة الحياة. قد يرى المستخدم تسمية واحدة، بينما يشمل الحجز مجموعة أوسع بكثير.
المصادر
- RFC 3743 — إرشادات JET لتسجيل أسماء CJK وإدارتها؛ سجل Datatracker؛ تاريخ الوثيقة؛ معلومات RFC Editor؛ بحث التصويبات.
- RFC 3490 — IDNA؛ RFC 3454 — Stringprep؛ RFC 3491 — Nameprep؛ RFC 3492 — Punycode؛ RFC 4690 — الخطوات التالية لأسماء IDN.
- RFC 5890 — تعريفات IDNA؛ RFC 5891 — بروتوكول IDNA2008؛ RFC 5892 — جداول IDNA2008؛ RFC 5895 — تحويلات IDNA2008؛ RFC 6912 — مبادئ إدراج نقاط Unicode في التسميات؛ RFC 8753 — مراجعة IDNA لإصدارات Unicode الجديدة؛ جداول IANA IDNA.
- منظور تحريري وليس متطلباً من IETF: Lu Heng، Running-Code Primacy.
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
