Skip to main content
Resources

Registry Request Service (RRS)

Questions registries and sponsors are asked to complete when submitting a request for a new registry service through the RRS

Proposed Service

Name of the Proposed Service

Technical Description of the Proposed Service

Consultation

Please describe with specificity your consultations with the community, experts and or others. What were the quantity, nature and content of the consultations?

  1. If the registry is a sponsored TLD, what were the nature and content of these consultations with the sponsored TLD community?

  2. Were consultations with gTLD registrars or the registrar constituency appropriate? Which registrars were consulted? What were the nature and content of the consultation?

  3. Were consultations with other constituency groups appropriate? Which groups were consulted? What were the nature and content of these consultations?

  4. Were consultations with end users appropriate? Which groups were consulted? What were the nature and content of these consultations?

  5. Who would endorse the introduction of this service? What were the nature and content of these consultations?

  6. Who would object the introduction of this service? What were(or would be) the nature and content of these consultations?

Timeline

Please describe the timeline for implementation of the proposed new registry service.

Business Description

Describe how the Proposed Service will be offered:

Describe quality assurance plan or testing of Proposed Service:

Please list any relevant RFCs or White Papers on the proposed service and explain how those papers are relevant.

Contractual Provisions

List the relevant contractual provisions impacted by the Proposed Service:

What effect, if any, will the Proposed Service have on the reporting of data to ICANN?

What effect, if any, will the Proposed Service have on Whois?

Contract Amendments

Please describe or provide the necessary contractual amendments for the proposed service:

Benefits of Service

Describe the benefits of the Proposed Service:

Competition

Do you believe your proposed new Registry Service would have any positive or negative effects on competition? If so, please explain:

How would you define the markets in which your proposed Registry Service would compete?

What companies/entities provide services or products that are similar in substance or effect to your proposed Registry Service?

In view of your status as a registry operator, would the introduction of your proposed Registry Service potentially impair the ability of other companies/entities that provide similar products or services to compete?

Do you propose to work with a vendor or contractor to provide the proposed Registry Service? If so, what is the name of the vendor/contractor, and describe the nature of the services the vendor/contractor would provide.

Have you communicated with any of the entities whose products or services might be affected by the introduction of your proposed Registry Service? If so, please describe the communications.

Do you have any documents that address the possible effects on competition of your proposed Registry Service? If so, please submit them with your application. (ICANN will keep the documents confidential).

Security and Stability

Does the proposed service alter the storage and input of Registry Data?

Please explain how the proposed service will affect the throughput, response time, consistency or coherence of responses to Internet servers or end systems:

Have technical concerns been raised about the proposed service, and if so, how do you intend to address those concerns?

Other Issues

Are there any Intellectual Property considerations raised by the Proposed Service?

Does the proposed service contain intellectual property exclusive to your gTLD registry?

List Disclaimers provided to potential customers regarding the Proposed Service:

Any other relevant information to include with this request:

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