Skip to main content
Resources

سياسة نقل Whois الكثيفة لنطاقات COM. وNET. وJOBS.

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

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

الأخبار

في 7 نوفمبر/تشرين الثاني 2019، مرر مجلس إدارة ICANN قرارًا بتأجيل إنفاذ الامتثال التعاقدي. وعليه سوف تؤجل إدارة الامتثال التعاقدي في ICANN إنفاذ سياسة نقل WHOIS الكثيفة إلى أن يحدث كل ما يلي:

  • أن ينتهي فريق مراجعة تنفيذ سياسة بيانات تسجيل نطاقات المستوى الأعلى العامة (IRT) مراجعته بالإضافة إلى وضعه تقديرًا لتوقيت تنفيذ توصيات فريق العملية المعجّلة لوضع السياسات (EPDP) وفقًا لما اعتمده مجلس إدارة ICANN في 15 مايو/أيار 2019.
  • أن تقدم منظمة ICANN وفريق مراجعة التوصيات لمجلس منظمة دعم الأسماء العامة المعلومات اللازمة حول تأثيرات توصيات فريق العملية المعجّلة لوضع السياسات على السياسات والإجراءات الحالية (بما في ذلك سياسة نقل WHOIS الكثيفة).
  • أن يتخذ مجلس منظمة دعم الأسماء العامة قرارًا بخصوص اتخاذ إجراء حيال التحديثات على السياسات والإجراءات ذات الصلة (والتي يمكن أن تشتمل على أعمال إضافية تخص السياسة أو إرشادات أو إجراءات أخرى يتم تقريرها) بما يؤثر على سياسة نقل WHOIS الكثيفة.

يجب تفسير الكلمات الرئيسية "يجب" و"يجب ألا" و"يلزم" و"سوف" و"لن" و"ينبغي" و"لا ينبغي" و"مستحسن" و"يجوز" الواردة في هذه الوثيقة كما هو موضح في RFC 2119 ، والذي يتوفر على http://www.ietf.org/rfc/rfc2119.txt .

المجال:

يجب تطبيق هذه السياسة على مشغلي السجل لنطاقات .COM و .NET و .JOBS من gTLD ، وكذلك جميع المسجلين الراغبين في تسجيل أسماء النطاقات .COM أو .NET أو .JOBS في gTLD .

التعاريف:

    • (التسجيل) الخفيفة: اسم النطاق الذي يحتفظ به مشغل السجل ويقدم معلومات تقنية فقط (مثل خوادم الأسماء والحالات وتاريخ الإنشاء) والمسجل الراعي المرتبط باسم النطاق. يتم الاحتفاظ بمعلومات الاتصال الخاصة باسم النطاق من قبل المسجل الراعي.
    • (التسجيل) الكثيفة: اسم النطاق الذي يقدم المسجل الراعي نسخة من معلومات الاتصال المرتبطة به إلى مشغل السجل. يحتفظ اسم النطاق بالمعلومات التقنية (مثل خوادم الأسماء والحالات وتاريخ الإنشاء) والمسجل الراعي المرتبط باسم النطاق. يتم الاحتفاظ بمعلومات الاتصال الخاصة باسم النطاق من قبل المسجل الراعي.
    • اسم النطاق الموجود: اسم النطاق الذي تم إنشاؤه، أو في حالة انتظار، قبل 1 مايو 2018.
    • مقاييس التقدم الانتقالي: المقاييس التي تم إنشاؤها بواسطة مشغل السجل وإبلاغها بانتظام إلى أمناء السجلات و ICANN للسماح بقياس التقدم المحرز في الانتقال من نطاقات خفيفة إلى كثيفة، بما في ذلك على الأقل العدد الإجمالي للنطاقات التي يديرها المسجل وعدد ونسبة النطاقات التي تحتوي على عناصر اتصال.

السياسة وتاريخ السريان:

3.1 يجب تقديم جميع تسجيلات أسماء النطاقات الجديدة على أنها كثيفة بدءا من 1 مايو 2018 على الأكثر.

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

تنطبق المتطلبات التالية على مشغلي السجل فقط:

4.1 يجب على مشغل السجل نشر آلية EPP وآلية بديلة للنقل الجماعي بحلول 1 أغسطس 2017 للمسجلين لترحيل بيانات التسجيل لأسماء النطاقات الحالية (أي الانتقال من خفيفة إلى كثيفة).

4.2 بحلول 1 مايو 2017، يجب على مشغل السجل أن يقدم للمسجلين المعنيين و ICANN الوثائق التي تعكس تغييرات النظام اللازمة لدعم متطلبات القسم 4.1.

4.3 بحلول 1 مايو 2017، يجب على مشغل السجل نشر آلية EPP وآلية بديلة للنقل الجماعي في بيئات اختبار التشغيل (OT&E ) ذات الصلة للمسجلين لاختبار ترحيل بيانات التسجيل لأسماء النطاقات الحالية (أي الانتقال من خفيفة إلى كثيفة).

4.4 بحلول 1 أغسطس 2017، يجب على مشغل السجل دعم جميع أوامر الاتصال المحددة في RFC5733 كما هو موضح في هذا الشرط. حقول الاتصال EPP <contact:id> ، <contact:postalInfo type >، و <contact:authInfo > ستكون مطلوبة من قبل مشغل السجل. يجب أن يقبل مشغل السجل ولكن يجب ألا يطلب جميع عناصر بيانات التسجيل الأخرى حتى 1 فبراير 2019 التي تمكنه من الامتثال لنظام WHOIS (متاح عبر المنفذ 43) ومتطلبات خدمات دليل الويب المبينة في القسم 1 من المواصفات 4 من "اتفاقية السجل الأساسي المعتمدة في 9 يناير 2014"("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها، وخدمات دليل بيانات تسجيل السجل.

4.5 بحلول 1 مايو 2018، يجب على مشغل السجل طلب بيانات التسجيل الكثيف لعنصر نطاق EPP <create > كما هو موضح في هذا الشرط. يجب أن يطلب مشغل السجل جميع عناصر بيانات التسجيل التي تمكنه من الامتثال لنظام WHOIS (متاح عبر المنفذ 43) ومتطلبات خدمات دليل الويب المبينة في القسم 1 من المواصفات 4 من "اتفاقية السجل الأساسي المعتمدة في 9 يناير 2014"("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها، وخدمات دليل بيانات تسجيل السجل والتسمية المتوافقة وسياسة العرض.

4.6 بين 1 أغسطس 2017 و 1 فبراير 2019، يجب على مشغل السجل توفير مقاييس التقدم الانتقالية لكل مسجل على الأقل، شهريا بحلول الساعة 23:59 بالتوقيت العالمي المنسق في اليوم الأول من الشهر التالي.

4.7 بين 1 أغسطس 2017 و 1 فبراير 2019، يجب على مشغل السجل توفير جميع مقاييس التقدم الانتقالية لـ ICANN لكل مسجل على الأقل، شهريا بحلول الساعة 23:59 بالتوقيت العالمي المنسق في اليوم الأول من الشهر التالي.

4.8 يجب على مشغلي السجل تنفيذ متطلبات سياسة خدمات دليل بيانات تسجيل السجل والتسمية المتوافقة وسياسة العرض ("CL&D Policy ") بالتزامن مع القسم 1 من المواصفة 4 من "اتفاقية السجل الأساسي الحاصلة على موافقة في 9 يناير 2014" ("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها بحلول 1 أغسطس 2017.

4.9 يجب أن يمتثل مشغل السجل لنظام WHOIS (متاح عبر المنفذ 43) ومتطلبات خدمات دليل الويب المبينة في القسم 1 من المواصفات 4 من "اتفاقية السجل الأساسي المعتمدة في 9 يناير 2014"("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها، وخدمات دليل بيانات تسجيل السجل والتسمية المتوافقة وسياسة العرض بحلول 1 مايو 2018 للتسجيلات الجديدة وبحلول 1 فبراير 2019 لأسماء النطاقات الموجودة.

4.10 بين 1 أغسطس 2017 و 1 فبراير 2019، بالنسبة لأسماء النطاقات الموجودة، بالنسبة لحقول مخرجات RDDS حيث لا توجد بيانات في نظام التسجيل المشترك (SRS )، قد يعالج مشغل السجل حقول RDDS التالية باعتبارها اختيارية كما هو موضح في التوضيح 1 من "المشورة: توضيحات على اتفاقية السجل، واتفاقية اعتماد أمناء السجلات لسنة 2013 (أو RAA ) فيما يخص مواصفات خدمات دليل التسجيل (WHOIS ) المعمول بها":

  • معرف أمين السجل المسؤول/الفني
  • اسم أمين السجل/المسؤول/الفني
  • شارع أمين السجل/المسؤول/الفني
  • مدينة أمين السجل/المسؤول/الفني
  • بلد أمين السجل/المسؤول/الفني
  • هاتف أمين السجل/المسؤول/الفني
  • البريد الإلكتروني لأمين السجل/المسؤول/الفني

4.11 اتصال "الفواتير"، أمر اختياري ما لم ينص على خلاف ذلك من قبل اتفاقية السجل. سياسة السجل قد تحدد ما إذا كانت مطلوبة أو اختيارية أو غير مدعومة. إذا كانت مدعومة يجب أن يتم عرض معلومات اتصال الفواتير كما هو موصوف في "الاستشارية: التوضيحات الخاصة باتفاقية السجل واتفاقية اعتماد أمين السجل 2013 (RAA ) التي تتعلق بمواصفات خدمة دليل بيانات التسجيل القابلة للتطبيق لبروتوكول (Whois )" (القسم 22).

تنطبق المتطلبات التالية على أمناء السجل فقط:

5.1 بين 1 أغسطس 2017 و1 فبراير 2019 يجب أن يتقل أمناء السجلات إلى مشغل السجل ذو الصلة جميع الحقول المطلوبة لأسماء النطاق الحالي المتوفر في قاعدة بيانات أمين السجيل التي تمكن مشغل السجل من الامتثال لنظام WHOIS (متاح عبر المنفذ 43) ومتطلبات خدمات دليل الويب المبينة في القسم 1 من المواصفات 4 من "اتفاقية السجل الأساسي المعتمدة في 9 يناير 2014"("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها، وخدمات دليل بيانات تسجيل السجل.

5.2 يجب أن يقدم أمناء السجل جميع بيانات التسجيل المكثف إلى مشغل السجل التي تمكنه من الامتثال لنظام WHOIS (متاح عبر المنفذ 43) ومتطلبات خدمات دليل الويب المبينة في القسم 1 من المواصفات 4 من "اتفاقية السجل الأساسي المعتمدة في 9 يناير 2014"("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها، وخدمات دليل بيانات تسجيل السجل والتسمية المتوافقة وسياسة العرض بدءًا من 1 أغسطس 2017.

5.3 يجب أن يقدم أمناء السجل جميع بيانات التسجيل المكثف إلى مشغل السجل التي تمكنه من الامتثال لنظام WHOIS (متاح عبر المنفذ 43) ومتطلبات خدمات دليل الويب المبينة في القسم 1 من المواصفات 4 من "اتفاقية السجل الأساسي المعتمدة في 9 يناير 2014"("اتفاقية السجل الأساسي") أو التعديلات اللاحقة لها، وخدمات دليل بيانات تسجيل السجل والتسمية المتوافقة وسياسة العرض بدءًا من 1 مايو 2018.

ملاحظات التنفيذ

في حالة وجود تعارض بین قوانین الخصوصیة المحلیة والمتطلبات الواردة في ھذه السیاسة، فإن إجراءات معالجة ICANN لتعارضات WHOIS مع قانون الخصوصیة متاح لمشغلي السجل والمسجلین.

نبذة موجزة

اعتمد مجلس إدارة ICANN توصيات السياسة بالإجماع لمجموعة عمل WHOIS لسجلات GNSO الكثيفة بشأن استخدام WHOIS الكثيف من قبل جميع سجلات نطاقات gTLD في 7 فبراير 2014 بعد اعتماد التوصيات من قبل مجلس GNSO وتنص التوصية1 على أنه "يجب أن يصبح توفير خدمات WHOIS المكثفة، مع الترميز والعرض المتّسقين وفق النموذج المبين في البند 3 Specification (الموصفات) من [إتفاقية إعتماد أمين السجل] لعام 2013، شرطاً لكافة سجلات gTLD المتواجدة حالياً والمستقبلية." (انظر قرار مجلس إدارة ICANN في 2014.02.07.08 - 2014.02.07.09 على http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c ).

عملت ICANN مع فريق من أعضاء المجتمع (أي فريق مراجعة التنفيذ) لتنفيذ توصيات السياسة. كجزء من التنفيذ وقبل اعتمادها، طلبت ICANN من المجتمع تقديم مدخلات حول توصيات السياسة المقترحة واللغة المتضمنة في هذه السياسة. (انظر https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en ).

كما ضم التقرير النهائي (1,23 ميجا بايت، PDF ) الخاص بفريق عمل (WG ) عملية وضع سياسة WHOIS المكثفة PDP في مادته 7.2 توجيه "اعتبارات التنفيذ" المرتبط بالجدول الزمني والمتطلبات اللازمة لتنفيذ الانتقال من Whois الخفيفة إلى Whois المكثفة. من الملاحظ بشكل خاص أنه "أكد فريق العمل WG أن تنفيذ قسم واحد من التوصيات (على سبيل المثال، انتقال نموذج سجلات gTLD الخفيفة الموجودة إلى المكثفة) يجب ألا يُحدث تأخيرًا لا داعي له لتنفيذ الجزء الآخر من التوصيات (على سبيل المثال، وضع العلامات بشكل متسق وعرض مثل هذه البيانات)".

نتيجة لذلك، عملت منظمة ICANN مع فريق مراجعة التنفيذ على مسارات تنفيذ موازية لنقل تسجيلات Whois الخفيفة إلى كثيفة والترميز والعرض المتسقين لبيانات Whois . لمزيد من التفاصيل انظر https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en.

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."