Skip to main content
Resources

سياسات حل النزاع لأسماء النطاقات

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

تنطبق السياسات التالية على أنواع متعددة من النزاعات بين شركات التسجيل والأطراف الثالثة عبر التسجيل واستخدام أسماء النطاقات . ويمكن تقديم النزاعات وفقًا لهذه السياسات ضد أحد مزودي خدمة حلول النزاعات المعتمدين للسياسة المقدّمة .

سياسة حل النزاع لأسماء النطاقات الموحدة (الواردة أدناه) قابلة للتطبيق على كافة نطاقات gTLD . وقد تنطبق سياسات حلول نزاعات إضافية على حالات معينة فقط في نطاقات TLD فردية . وهي أيضًا سترد فيما يلي .

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

سياسة حل النزاع لأسماء النطاقات الموحدة

لقد تبنى المسجلون المعتمدون من قبل ICANN في كافة نطاقات gTLD (.aero, .asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel ) سياسة حل النزاع لأسماء النطاقات الموحدة (UDRP). قد يتم البدء في إجراءات النزاع الناشئة من إساءة استخدام عمليات التسجيل المزعومة لأسماء النطاقات (على سبيل المثال، الاحتلال الإلكتروني) من خلال مالك حقوق العلامة التجارية . إن سياسة UDRP هي سياسة بين المسجل والعميل التابع له وهي مشمولة في اتفاقيات التسجيل لكافة المسجلين المعتمدين من قبل ICANN .

سياسة حل النزاع لأهلية الميثاق

سياسة حل النزاع لأهلية الميثاق (CEDRP) تتبعها نطاقات TLD المدعومة .aero, .coop, .museum, and.travel للاعتراضات على تسجيل اسم نطاق ما على الأسس التي لا تلتزم فيها شركة التسجيل بمتطلبات الأهلية (المنصوص عليها في ميثاق النطاقات المدعومة) الخاصة بتسجيل اسم نطاق في نطاق TLD المحدد . ويستطيع أي شخص أو كيان تقديم اعتراض على اسم نطاق مُسجل وفقًا لسياسة CEDRP .

سياسة إعادة النظر في الأهلية

سياسة إعادة النظر في الأهلية (ERP) مدمجة في اتفاقيات مع شركات التسجيل فيما يتعلق بتسجيلات اسم نطاق في .aero . وهي تحدد البنود والشروط . التي ترتبط بأي اعتراض على قرار صادر من الراعي فيما يتعلق بأهلية التسجيل في .aero. وقد وُضعت السياسة من قبل راعي نطاق .aero . فهي ليست إحدى سياسات ICANN وهي مقدمة هنا كمرجع فقط . ويمكن الحصول على المزيد من المعلومات من موقع ويب الراعي .

سياسة حل النزاع لمتطلبات الأهلية

سياسة حل النزاع لمتطلبات الأهلية (ERDRP) يتبعها نطاق TLD .name المقيد غير المدعوم . ويجب أن تتكون تسجيلات نطاق .name من الاسم الشخصي للفرد أو الاسم الشخصي لشخصية وهمية (بشرط أن يمتلك المُسجل علامة تجارية أو حقوق خدمة علامة في الاسم الشخصي لهذه الشخصية) . كما يمكن استخدام الرموز الرقمية بالاشتراك مع أي نوع من أنواع اسم الشخص السابقة . ويمكن إرسال الاعتراضات على تسجيلات نطاق .name على الأسس التي لا تفي بمتطلبات الأهلية وفقًا لسياسة ERDRP . وكذلك فإن التسجيلات الدفاعية وتسجيلات عناوين البريد الإلكتروني لنطاق المستوى الثاني معرّضة للاعتراض وفقًا لسياسة ERDRP . ويستطيع أي شخص أو كيان تقديم اعتراض على تسجيل ما وفقًا لسياسة ERDRP .

سياسة متطلبات أهلية ميثاق نطاق .ASIA

تنطبق سياسة متطلبات أهلية ميثاق آسيا (.ASIA CERP) على أسماء النطاقات المسجلة في نطاقات TLD .ASIA المدعومة . تقتصر تسجيلات نطاق .ASIA على أعضاء مجتمع إنترنت دول آسيا بالكامل ودول آسيا المطلة على المحيط الهادئ . ويمكن إرسال الاعتراضات على تسجيلات نطاق .ASIA على الأسس التي لا تفي بمتطلبات الأهلية وفقًا لسياسة CERP . ويمكن الحصول على المزيد من المعلومات من موقع ويب نطاق .ASIA .

سياسة حل نزاع متطلبات الأهلية لنطاق .cat ( Política de Resolució de Conflictes sobre Requisits d'Admissibilitat del .cat )

تنطبق سياسة حل نزاع متطلبات الأهلية لنطاق .cat (.cat ERDRP) على أسماء النطاقات المسجلة لنطاق TLD .cat المدعوم . وتقتصر تسجيلات نطاق .cat على أعضاء المجتمع الكتالوني اللغوي والثقافي . ويمكن إرسال الاعتراضات على تسجيلات نطاق .cat على الأسس التي لا تفي بمتطلبات الأهلية وفقًا لسياسة ERDRP . ويمكن الحصول على المزيد من المعلومات من موقع ويب نطاق .cat .

سياسة الاعتراض على التسجيلات الدفاعية للملكية الفكرية

تنطبق سياسة الاعتراض على التسجيلات الدفاعية للملكية الفكرية (IPDRCP) على التسجيلات الدفاعية للملكية الفكرية في نطاق .pro TLD ، المقصور استخدامه على الأعضاء المتدربين المعتمدين في مهن معينة (وهي حاليًا المهن الطبية، والقانونية، والمحاسبية). ويمكن عمل تسجيل دفاعي للملكية الفكرية فقط من خلال مالك علامة تجارية مؤهلة أو تسجيل علامة خدمة . وتوفر سياسة IPDRCP وسيلة للاعتراض على التسجيلات الدفاعية للملكية الفكرية فيما يتعلق باحتمالية اضطلاع شركة التسجيل تلك بمؤهلات التسجيل . ويستطيع أي شخص أو كيان بدء إجراء من إجراءات سياسة IPDRCP من خلال إرسال الاعتراض وفقًا للقواعد .

سياسة الاعتراض على المؤهلات

سياسة الاعتراض على المؤهلات (QCP) يتبعها نطاق TLD .pro المقيد غير المدعوم، الذي يقتصر استخدامه على الأعضاء المرخصين في مهن معينة . ويمكن تقديم الاعتراضات على التسجيل على أساس أن شركة التسجيل لم تضطلع بمؤهلات التسجيل وفقًا لسياسة QCP . ويستطيع أي صاحب مصلحة تقديم اعتراض على تسجيل ما وفقًا لسياسة الاعتراض على المؤهلات .

سياسة حل نزاع القيود

تنطبق سياسة حل نزاع القيود (RDRP) على نطاق TLD .biz المقيد غير المدعوم . يجب استخدام القيود في نطاق .biz TLD أو قصد استخدامها في المقام الأول للأعمال أو الأغراض التجارية حسنة النية . ويمكن تقديم الاعتراضات على تسجيل ما أو على استخدام نطاق اسم محدد على أساس أنه لا يتم أو لن يتم استخدامه في المقام الأول للأعمال أو الأغراض التجارية حسنة النية وفقًا لسياسة RDRP . ويمكن تقديم الاعتراضات وفقًا لسياسة RDRP من خلال أي طرف يقوم برفع شكوى ضد مزود خدمة حلول النزاعات المعتمد .

سياسة معارضة بدء تشغيل علامة تجارية

لقد كانت سياسة معارضة بدء تشغيل علامة تجارية (STOP) متاحة فقط لأصحاب الملكية الفكرية المدرجين في خدمة طلب IP أثناء مرحلة بدء التشغيل لسجل نطاق biz (في الفترة من 25 يونيو وحتى 21 سبتمبر 2001 ). ولم تعد سياسة STOP متاحة كسياسة لحل النزاع لأسماء نطاقات .biz . ويمكن عمل النزاعات وفقًا لسياسة UDRP ، أو RDRP ، أو المحاكم المتاحة . لمزيد من المعلومات، الرجاء الرجوع إلى موقع مشغل السجل .

سياسة الاعتراض على النشوء

لقد تم تطبيق سياسة الاعتراض على النشوء (SCP) فقط أثناء فترة نشوء نطاق .info TLD. وقد تمت إدارة الاعتراضات وفقًا لسياسة الاعتراض على النشوء من قبل مشغل السجل (Afilias) . ومع انتهاء فترة النشوء التي مدتها مائة وعشرون (120) يومًا، يمكن للأطراف المتنازعين بشأن صلاحية تسجيل النشوء استخدام سياسة UDRP أو من خلال المحاكم المتاحة . لمزيد من المعلومات، الرجاء الرجوع إلى موقع مشغل السجل .

سياسة حل نزاع الانتقال

تنطبق سياسة حل نزاع الانتقال (TDRP) على المعاملات التي يقوم فيها مالك اسم النطاق بنقل أو محاولة نقل اسم نطاق إلى مُسجل جديد . وتتعلق سياسة TDRP بنزاعات المسجلين وفقًا لسياسة الانتقال الداخلي بين المسجلين ، التي تتبعها نطاقات TLD المتمثلة في .biz, .com, .info, .name, .net, .org, and .pro . ويمكن تقديم الإجراءات وفقًا لسياسة TDRP ضد مشغل السجل المناسب أو ضد مزود حل نزاع مستقل . ويستطيع أي مسجل معتمد من قبل ICANN اتخاذ إجراء من إجراءات سياسة TDRP ضد مسجل آخر من خلال إرسال شكوى طبقًا للقواعد الإضافية لمشغل السجل المحدد أو مزود حلول النزاعات .

إجراءات

عملية الموافقة على مزودي خدمة حل النزاع

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

المنظمات التي تسعى إلى موافقة مؤقتة كمزودي خدمة وفقًا لسياسات حل النزاع الخاصة بشركة ICANN يجب عليها اتخاذ الخطوات التالية :

  1. أن يكونوا على دراية بالسياسة ذات الصلة والقواعد المتعلقة بها .
  2. أن يرسلوا طلب تقديم بواسطة البريد الإلكتروني إلى العنوان ( icann@icann.org ) وبواسطة البريد العادي :

    Dispute Resolution Service Provider Applications
    Internet Corporation for Assigned Names and Numbers
    4676 Admiralty Way, Suite 330
    Marina del Rey, CA 90292-6601 USA

ويجب أن يحتوي الطلب على ما يلي :

  1. نظرة عامة على قدرات مقدم الطلب وخلفيته في توفير خدمة حلول نزاع بديلة (ADR) ، بما في ذلك وصف لسجل إنجازات مقدم الطلب الخاص بمعالجة النواحي الكتابية لإجراءات خدمة ADR المستعجلة .
  2. قائمة بأسماء ومؤهلات الأعضاء الاستشاريين الذين يقترحهم مقدم الطلب ليتم إدراجهم في قائمته المنشورة ووصف لمتطلبات التصفية التي استخدمها مقدم الطلب في اختيار الأعضاء الاستشاريين الذين سيتم إدراجهم في القائمة .
  3. وصف لأدوات القياس التدريبية والتعليمية التي يقترحها مقدم الطلب للاستعمال للأعضاء الاستشاريين المدرجين بخصوص نزاعات أسماء النطاقات، والسياسة ذات الصلة، والقواعد المرتبطة بها .
  4. تعهد من قبل مقدم الطلب بعدم منع أو إعاقة أي عضو من الأعضاء الاستشاريين المدرجين من العمل كعضو استشاري لنزاعات أسماء النطاقات التي يديرها مزودون معتمدون آخرون .
  5. نسخة من القواعد الإضافية التي يقترحها مقدم الطلب (بما في ذلك بيان الرسوم) .
  6. وثائق إجراءات التشغيل الداخلي المقترحة من قبل مقدم الطلب . في حالة طلبها، ستحتفظ ICANN بهذه الوثائق سرًا .
  7. جدول مقترح بتنفيذ مقدم الطلب لبرنامجه الخاص بإدارة الإجراءات وفقًا للسياسة، بما في ذلك بيان بقدرة مقدم الطلب الإدارية فيما يتعلق بعد الإجراءات المتخذة بصورة شهرية .
  8. بيان أي قيود مطلوبة على عدد الإجراءات التي يقوم مقدم الطلب بمعالجتها، سواءً أثناء فترة بدء التشغيل أو بصورة دائمة .
  9. وصف للكيفية التي يقترحها مقدم الطلب لإدارة الإجراءات، بما في ذلك تفاعلاته مع الأطراف، والمسجلين، و ICANN ، والمزودين المعتمدين الآخرين .
  10. وصف للكيفية التي يعتزم مقدم الطلب استخدامها لنشر قرارات الهيئات في الإجراءات التي يديرها وتعهد بتزويد ICANN بنسخ من كافة أجزاء قرارات الهيئات التي لم تُنشر .

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

  1. يجب أن يتمتع مقدم الطلب بسجل إنجازات في معالجة النواحي الكتابية لإجراءات خدمة ADR بكفاءة . وتعتبر ICANN المراجعة الصحيحة لمرافعات التوافق الإداري والتوزيع الموثوق والموثّق جيدًا للوثائق إلى الأطراف والهيئات من القدرات الضرورية بالنسبة للمزودين . وفي حالة فقدان سجل الإنجازات القوي في معالجة الوظيفة الكتابية، يجب إرسال خطة مفصلة بتوفير تلك القدرات عادةً .
  2. يجب أن يقترح مقدم الطلب قائمة بالمحايدين المؤهلين بدرجة عالية الذين يوافقون على العمل كأعضاء استشاريين . ويجب أن تتضمن قائمة مقدم الطلب عشرين شخصًا على الأقل . ويتوقع تمامًا من مقدمي الطلبات أن يقوموا بتدريب المحايدين المدرجين فيما يتعلق بالسياسة والقواعد، وتكنولوجيا أسماء النطاقات، والمبادئ القانونية الأساسية القابلة للتطبيق على نزاعات أسماء النطاقات . ولذلك، لا ينصح بالقوائم الطويلة جدًا للمحايدين . يجب على مقدم الطلب إما تقديم قائمة بالأعضاء الاستشاريين من دول متعددة، أو اقتراح خطة لتوسيع قائمته لتصبح متعددة الجنسيات، في حالة تقديمه لقائمة تشمل دولة واحدة أصلاً .
  3. يجب أن تُظهر القواعد الإضافية والإجراءات الداخلية الخاصة بمقدم الطلب أنه يفهم القواعد التشغيلية للسياسة والقواعد المرتبطة بها .
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."