Skip to main content
Resources

برنامج امتثال جهة التسجيل

هذه الصفحة متوفرة باللغات:

النظرة العامة التالية على برنامج امتثال جهة التسجيل [PDF, 553 KB] بمثابة دليل توجيهي فقط. يجب على الأطراف المتعاقدة الاستمرار في المراجعة والامتثال لجميع المتطلبات الواردة في اتفاقاتها مع هيئة ICANN وسياساتها المعمول بها.

وقد تم تطوير برنامج امتثال جهة تسجيل نطاق gTLD من خلال تقسيم الأحكام التعاقدية لاتفاقية اعتماد جهة التسجيل (RAA) إلى جوانب امتثال عامة. ويتم تنفيذ تلك الجوانب عبر دمج جهود المراقبة الداخلية ومعالجة الشكاوى ومراقبة المصادر الخارجية، مثل الأخبار المتعلقة بالمجال. وقد يؤدي وجود خدمة جديدة أو تغيير في السياسة إلى مراقبة إضافية للامتثال في هذا الجانب.

وتتطابق صيغة اتفاقية RAA فيما لا يتعلق بمزايا جهة التسجيل. وفيما يلي بعض من جوانب الامتثال المتعلقة باتفاقية RAA والأحكام ذات الصلة.

لمزيد من المعلومات الإضافية المتعلقة بجهات التسجيل واتفاقيات RAA، برجاء الرجوع إلى صفحة المعلومات الخاصة بجهات التسجيل والمسجلين.

قائمة ببعض جوانب الامتثال المتعلقة بجهة التسجيل.

  1. خدمات دليل تسجيل البيانات (Whois)

    هذه هي بعض الجوانب العريضة حيث يكون على جهات التسجيل المعتمدة العديد من الالتزامات، بما في ذلك:

    • توفير خدمة Whois العامة المجانية على المنفذ 43 وعبر شبكة الإنترنت؛
    • تقديم جميع عناصر البيانات المطلوبة إلى السجلات؛
    • تحديث البيانات في الوقت المناسب؛
    • اتخاذ خطوات معقولة للتحري عن حالات انعدام الدقة وتصحيحها عند الإخطار بها؛
    • توفير تذكير المسجلين ببيانات Whois سنويا.

    وتشمل الأحكام ذات الصلة الأقسام التالية؛ 3.2 و 3.3 و 3.7.8 من اتفاقية RAA لعام 2009 واتفاقية RAA لعام 2013، ووثيقة برنامج دقة Whois لاتفاقية RAA لعام 2013.

    للمزيد من المعلومات برجاء زيارة صفحة: حول شكاوي Whois.

  2. نقل اسم النطاق

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

    التزامات جهة التسجيل المتعلقة بعمليات النقل محددة في سياسة النقل بين جهات التسجيل (IRTP).

  3. تجديد أسماء النطاقات

    توفر سياسة استرداد التسجيل منتهي الصلاحية (ERRP) وسياسة حذف النطاق منتهي الصلاحية(EDDP) متطلبات جهات التسجيل المعتمدة لدى ICANN بشأن انتهاء صلاحية اسم النطاق، وبما في ذلك إبلاغ المسجلين بانتهاء الصلاحية. للمزيد من المعلومات برجاء زيارة صفحة: حول تجديد/استعادة النطاق.

  4. الحفظ الاحتياطي للبيانات

    يطلب من جهات التسجيل تقديم نسخة إلكترونية من قاعدة البيانات الخاصة بهم إلى وكيل الضمان وفقًا للتنسيق والجدول الزمني المعتمد. كما أن عليهم الدخول في اتفاق مناسب مع ICANN ووكيل الضمان. تعمل ICANN مع وكلاء ضمان البيانات للتأكد أن بيانات ودائع جهات التسجيل تسير وفقًا للجدول الزمني المطلوب وبالتنسيق المطلوب، وأن كافة البيانات تتوافق مع متطلبات اتفاقية RAA.

  5. سياسة UDRP

    تعد السياسة الموحدة لفض النزاع حول أسماء النطاقات (UDRP) طريقة لتسوية نزاعات محددة حول أسماء النطاقات تشمل النزاعات المتعلقة بالعلامات التجارية. وعلى الرغم من ضرورة طرح سياسات UDRP عبر موفرين مستقلين لخدمة تسوية النزاعات، إلا أن اتفاقية RAA تتطلب من جهات التسجيل الامتثال لسياسة UDRP. وتشمل مناطق الامتثال لسياسة UDRP التحقق من معلومات المسجل والحفاظ على الوضع الراهن للنطاق وقفل أسماء النطاقات، وتنفيذ قرارات سياسة UDRP في الوقت المناسب. لمزيد من المعلومات، برجاء زيارة صفحة: حول نزاعات اسم النطاق/UDRP.

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

مراقبة الامتثال

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

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

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."