Skip to main content
Resources

سياسة استرداد التسجيل المنتهي

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

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

  1. المشترك عند انتهاء الصلاحية

    1.1. المشترك عند انتهاء الصلاحية ("RAE") هو الذي يُعرف باسم مالك الاسم المسجل الذي يحق له تجديد اسم النطاق على الفور قبل انتهاء صلاحيته.

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

  2. تجديد التسجيلات

    2.1. الإشعارات التذكيرية بانتهاء الصلاحية

    2.1.1. قبل انتهاء صلاحية تسجيل أي نطاق gTLD، يجب أن يقوم أمناء السجل بإخطار مالك الاسم المسجل مرتين على الأقل قبل موعد الانتهاء. ويجب إرسال أحد هذه الإخطارات قبل شهر تقريبًا من انتهاء الصلاحية، كما يجب إرسال الآخر قبل أسبوع من تقريبًا من انتهاء الصلاحية. وفي حالة تحويل التسجيل إلى مالك اسم مسجل آخر تبعًا لشرطٍ ما في اتفاقية التسجيل وفيما يتعلق بانتهاء صلاحية التسجيل (حسب ما جاء في الفقرة 1.2)، فلابد من تحويل إشعارات التجديد هذه إلى مالك الاسم المسجل بدلا من ذلك. ولا يوجد في هذه السياسة ما يمنع أمناء السجل من إرسال إخطارات إضافية، على اعتبار إرسال الإخطارين المطلوبين على الأقل في الأوقات المُحددة.

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

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

    2.2. التجديد بعد انتهاء الصلاحية

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

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

    2.2.3. بالنسبة للتسجيلات التي تم حذفها بعد انتهاء الصلاحية بثمانية أيام أو أكثر: يظل التسجيل قابلاً للتجديد لمدة ثمانية متتالية أيام على الأقل (بعد انتهاء الصلاحية)، وبعدها يجب أن يقوم الأمين بمقاطعة مسار نظام أسماء النطاقات، الذي حدده مالك الاسم المسجل، وحتى ذلك الحين، يسمح السجل المعمول به بهذه المقاطعة.

    2.2.4. أثناء مقاطعة مسار نظام أسماء النطاقات DNS، الذي حدده مالك الاسم المسجل، إذا وجَّه أمين السجل حركة شبكة الويب بشأن اسم النطاق إلى صفحة ويب في حين لا يزال التسجيل ساريًا من قبل المشترك، فيجب أن تشير صفحة الويب هذه بشكلٍ واضح إلى انتهاء تسجيل اسم النطاق وتوفر تعليمات بشأن التجديد.

    2.2.5. يجب أن يسمح أمين السجل لمالك الاسم المسجل بتجديد التسجيل منتهي الصلاحية، بدايةً من تاريخ انتهاء الصلاحية وخلال فترة مقاطعة نظام أسماء النطاقات DNS التي ورد وصفها في الفقرات 2.2.2 و2.2.3.

    2.2.6. بمجرد أن يقوم مالك الاسم المسجل بتجديد التسجيل، يجب أن يقوم أمين السجل بإعادة نظام أسماء النطاقات الذي حدده مالك الاسم المسجل، على الفور أو في أقرب وقت ممكن من الناحية التجارية.

  3. فترة السماح بالاسترداد

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

    3.2. يجب أن يقوم السجل بتعطيل حلول نظام أسماء النطاقات ويمنع محاولات نقل التسجيل. وقد أقرت ICANN آلية الانتقال الكبير لأسماء النطاقات وصرحت بأن الانتقال الجزئي لا يخضع لإجراء منع محاولات النقل. كما يجب أن يشير السجل بوضوح إلى أن نتائج Whois الخاصة بالتسجيل تعمل في فترة السماح بالاسترداد.

    3.3. يجب أن يسمح أمناء السجل للمشترك عند انتهاء الصلاحية باستعادة السجل الذي تمت إزالته، خلال فترة السماح بالاسترداد (إذا كانت فترة السماح بالاسترداد مقدمة من السجل المعني).

  4. إخطار المشتركين بالرسوم والإجراءات

    4.1. يجب أن يسدد المشتركين رسوم التجديد، ورسوم تجديد ما بعد الانتهاء (إذا كانت مختلفة)، ورسوم الاسترجاع/الاستعادة بشكل معقول وفي متناول مالكي الأسماء المسجلة الحاليين ومالكي الأسماء المسجلة المحتملين في وقت تسجيل أي اسم نطاق gTLD.

    4.1.1. يجب أن تكون هذه الرسوم ظاهرة، على الأقل، على موقع ويب أمين السجل، ويجب إدراج رابط لهذه الرسوم في اتفاقية التسجيل التي يبرمها أمين السجل. ويجب على أمناء السجل، الذين لا يقدمون خدماتهم عبر موقع ويب، أن يقوموا على الأقل بإدراج هذه الرسوم في اتفاقية التسجيل.

    4.1.2. بالإضافة إلى ذلك، يجب أن يضمن أمناء السجلات عرض هذه الرسوم على المواقع الإلكترونية للموزعين المتعاملين معهم.

    4.2. يجب أن يقدم أمناء السجل وصفًا لطرق توصيل إخطارات ما قبل وبعد انتهاء فترة الصلاحية، على مواقع الويب الخاصة بهم (إن وجدت)، الوارد ذكرها في القسم 2 أعلاه.

    4.2.1. ويجب أن يتضمن هذا الوصف، بشكلٍ عام، قنوات/وسائط الاتصال التي سيتم استخدامها، ويتضمن تعريفًا لنقطة الاتصال التي سيتم إرسال الإخطارات إليها (مثل البريد الإلكتروني لمالك الاسم المسجل، ورقم هاتف جهة الاتصال الإدارية، وعنوان بريد العميل، وما إلى ذلك).

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

    4.2.3. بالإضافة إلى ذلك، يجب أن يضمن أمناء السجلات عرض طرق المراسلة هذه على المواقع الإلكترونية للموزعين المتعاملين معهم.

    4.3. في حالة قيام ICANN بنشر مواد تعليمية للمشتركين تستهدف الإشراف على أسماء النطاقات وتجديد واستعادة تسجيلات نطاقات gTLD عبر الإنترنت؛ فيتعين على أمناء السجل، بعد فترةٍ وجيزة من استلام إخطار ICANN، توفير هذه المواد (أو مواد مماثلة يقوم أمناء السجل بتعديلها حسب ممارساتهم المحددة) لملاك الأسماء المسجلة من خلال:

    4.3.1.إدراج رابط لهذه المواد في رسالة يتم إرسالها لمالك الاسم المسجل بعد اكتمال عملية التسجيل مباشرةً، ومن جميع آليات الإخطار المُتبعة للتذكير بدقة بيانات Whois، مثل الإخطارات السنوية التي تشترطها سياسة WHOIS للتذكير بالبيانات <http://www.icann.org/resources/registrars/consensus-policies/wdrp>، و

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

ملاحظات

مقدمة وخلفية: بناءً على طلب لجنة At-Large الاستشارية التابعة لمؤسسة ICANN، قامت مؤسسة ICANN في الخامس من ديسمبر عام 2008 بنشر تقرير مشاكل <http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf> [PDF, 422 KB] بعنوان عملية تطوير سياسة استرجاع اسم النطاق بعد انتهاء الصلاحية. وقد أطلقت المنظمة الداعمة للأسماء العامة ("GNSO") عملية وضع سياسة عام 2009، والتي أسفرت عن تقديم العديد من توصيات وضع السياسات والمعالجة <http://gnso.icann.org/en/resolutions/#201107> إلى مجلس إدارة ICANN. وقد صدق مجلس إدارة ICANN على التوصيات بتاريخ 28 أكتوبر 2011 <http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#1.5>، موجها العاملين إلى تطبيق هذه السياسة.

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

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

ويلتزم جميع أمناء السجل والسجلات بهذه السياسة اعتبارًا من 31 أغسطس 2013.

الإخطارات التذكيرية بانتهاء الصلاحية: تُقر توصيات المنظمة الداعمة للأسماء العامة بضرورة وجود بعض المرونة في توقيت إخطارات التجديد قبل انتهاء الصلاحية. وبناءً عليه، إذا تم إرسال الإخطارات، المطلوب إرسالها قبل شهر واحد وأسبوع واحد قبل انتهاء الصلاحية الموضحة في الفقرة 2.1.1، خلال 26 إلى 35 يومًا وخلال 4 إلى 10 أيام على التوالي قبل انتهاء الصلاحية، فإن هذا يُعد امتثالاً للسياسة.

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

توضح الفقرة 2.2.2 المدة الزمنية التي يجب أن يقوم أمين السجل خلالها بمقاطعة مسار حلول نظام اسم النطاق إذا تمت إزالة التسجيل خلال ثمانية أيام من انتهاء صلاحيته. على سبيل المثال، إذا انتهت صلاحية التسجيل يوم 1 أكتوبر، وقام أمين السجل بإزالة الاسم يوم 3 أكتوبر، فلابد من مقاطعة مسار الحلول خلال الفترة من 1 إلى 3 أكتوبر. توضح الفقرة 2.2.3 المدة الزمنية التي يجب أن يقوم أمين السجل خلالها بمقاطعة مسار حلول نظام اسم النطاق إذا تمت إزالة التسجيل بعد أكثر من ثمانية أيام من انتهاء صلاحيته. على سبيل المثال، إذا انتهت صلاحية التسجيل يوم 1 أكتوبر، وقام أمين السجل بإزالة الاسم يوم 20 أكتوبر، فلابد من مقاطعة مسار الحلول خلال الفترة من 12 إلى 20 أكتوبر بحد أدنى.

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

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

أفضل الممارسات المقترحة: توصي المنظمة الداعمة للأسماء العامة بأفضل الممارسات التالية لأمناء السجل:

  • في حالة الإرسال الطبيعي لإشعارات ما بعد انتهاء الصلاحية، الموضحة في الفقرة 2.1.2 إلى جهة الاتصال التي تستخدم النطاق محل التساؤل، وكان من المعلوم أن التوصيل قد تمت مقاطعته من خلال إجراءات ما بعد انتهاء الصلاحية (مثل مقاطعة حل نظام DNS، حسبما ورد في الفقرتين 2.2.2 و2.2.3)، فلابد من إرسال إخطارات ما بعد انتهاء الصلاحية إلى جهة اتصال أخرى تتناسب مع مالك الاسم المسجل، إن وجدت.
  • ينبغي على أمناء السجل توجيه النصيحة لملاك الأسماء المسجلة بتقديم جهة اتصال فرعية بريدية لا تشترك مع اسم النطاق ذاته، وفي حالة انتهاء رسائل التذكير يتم إرسالها إلى جهة الاتصال الفرعية.
  • ينبغي أن يشتمل توضيح طريقة الإشعار الواردة في الفقرة 4.2، على العنوان البريدي لأمين السجل، وذلك من خلال رسائل الإشعار المرسلة ومقترح بأن يقوم ملاك الأسماء المسجلة بحفظ هذا العنوان البريدي باسم "مرسل آمن" لتجنب العناوين البريدية التي تم غلقها من خلال برنامج تصفية الرسائل غير المرغوب فيها.

الوقت المحدد للامتثال: يجب أن يمتثل جميع أمناء السجل المعتمدين من ICANN وسجلات gTLD إلى سياسة إخطارات ERRP بحلول يوم 31 أغسطس 2013. ويشترط القسم 2.1 من السياسة، أن يقوم أمناء السجل بإرسال إخطارات ما قبل انتهاء الصلاحية إلى جميع مشتركي gTLD. ويُتوقع أن يبدأ أمناء السجل في إرسال هذه الإخطارات اعتبارًا من 31 أغسطس، وفقًا للجدول الوارد في سياسة ERRP. بمعنى آخر، إذا كان تاريخ انتهاء الصلاحية مستحقًا خلال أقل من 30 يومًا بعد يوم 31 أغسطس 2013، فلا يُشترط أن يُرسل أمين السجل الرسالة التذكيرية قبل انتهاء الصلاحية بشهر. ويطبق نفس الأمر، إذا كان تاريخ انتهاء الصلاحية مستحقًا خلال أقل من 7 أيام بعد يوم 31 أغسطس، فلا يُشترط أن يُرسل أمين السجل الرسالة التذكيرية قبل انتهاء الصلاحية بأسبوع. إلا أن أمناء السجل لا يزالون ملتزمون، وفقًا للقسم 3.7.5 من اتفاقية اعتماد أمين السجل، بإرسال رسالتين تذكيريتين بانتهاء الصلاحية لجميع السجلات، حتى تلك التي تنتهي صلاحيتها خلال أقل من شهر أو أسبوع من تطبيق سياسة ERRP. يُرجى الرجوع إلى الجدول أدناه للتوضيح.

انتهاء صلاحية التسجيلات: أول إخطار بانتهاء الصلاحية مطلوب بناءً على سياسة ERRP (شهر واحد قبل انتهاء الصلاحية) ثاني إخطار بانتهاء الصلاحية مطلوب بناءً على سياسة ERRP (أسبوع واحد قبل انتهاء الصلاحية) يُشترط إرسال إخطارين على الأقل بانتهاء الصلاحية (بما في ذلك إخطارات ERRP)
قبل 7 سبتمبر 2013 x
7 سبتمبر 2013 - 30 سبتمبر 2013 x x
1 أكتوبر وما بعده x x x
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."