ICANN | Proposed Unsponsored TLD Agreement: Appendix C, Part 1 (.name)
  ICANN Logo

Proposed Unsponsored TLD Agreement: Appendix C,
Part 1 (.name)

(8 August 2003)

Functional Specifications

Part 1 - Service Descriptions

A. Domain Name Registrations

Domain names in the .name TLD may be registered through ICANN-accredited registrars that have Registry-Registrar Agreements ("RRAs") in effect with the Registry Operator and are qualified (hereafter in this Part, "Approved Registrars"), according to the following criteria:

  • Domain names must be of the format specified for the "Domain name character set" in Part 13 (Character Sets) of this Appendix C.
  • Domain names must meet the naming conventions for domain names specified in Appendix L, Part 0. Domain names in the .name TLD are registered to the public at the second level or third level: <name>.name or <name1>.<name2.>.name. Various possible names are reserved and may not be registered. See Appendix L, Part 0, and the references cited in that part.
  • In general, domain name registrations in the .name TLD will be made on a first-come, first-served basis. (Exceptions include the landrush process and dispute resolution.)
  • Registrants must meet the Eligibility Requirements stated in Appendix L, Part 1.
  • The initial registration term may be from one to ten years, in one-year increments , with the exception of any start-up phase restrictions as described in Appendix J.
  • Domain name registrations may be renewed prior to their expiration for a period of years up to ten years (in one-year increments), provided that the expiration date of a domain-name registration can never be more than ten years in the future. A renewal that would set the expiration date further than ten years in the future will lead to the expiration date being set to ten years in the future. Any remaining time will be forfeited.
  • All domain-name registrations must be made pursuant to the requirements of the Approved Registrar's RRA with the Registry Operator. Among other things, the RRA requires that the registrar and registrant have a registration agreement.
  • The Approved Registrar will collect registration information from the registrant and do quality checking of the data to ensure the validity of the domain-name registration. The registrar must submit through the Shared Registration System complete, accurate, and valid registration data, and must update that data when changes occur.

The above criteria are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement or otherwise.

During their term, domain name registrations will be maintained in the .name Shared Registration System. They will be reported by the .name Whois service, as described in Appendix O. In addition, domain names with registrations including the names and IP addresses (Ipv4) of at least two nameservers will be delegated in the .name TLD zone or a sub-zone, as described in Appendix C, Part 4.

B. Defensive Registrations

Defensive Registrations in the .name TLD may be made through Approved Registrars, according to the following criteria:

  • Defensive Registration names must be of the format specified in Appendix L, Part 0. The Approved Registrar will collect registration information from the registrant and do quality checking of the data to ensure the validity of the Defensive Registration.
  • Registrants must meet the Eligibility Requirements stated in Appendix L, Part 2.
  • The initial registration term of Defensive Registrations is ten years. They may be renewed in ten year terms, provided that the expiration date of a Defensive Registration can never be more than ten years in the future. A renewal that would set the expiration date further than ten years in the future will lead to the expiration date being set to ten years in the future. Any remaining time will be forfeited.
  • All Defensive Registrations must be made pursuant to the requirements of the Approved Registrar's RRA with the Registry Operator. Among other things, that RRA requires that the registrar and registrant have a registration agreement.
  • The registrar must submit through the Shared Registration System complete, accurate, and valid registration data, and must update that data when changes occur. The Defensive Registration request will include all the information supplied by the registrant and along with additional information about the Registrar, as set out in Appendix L and Appendix C, Part 2.

The above criteria are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement or otherwise.

During their term, Defensive Registrations will be maintained in the .name Shared Registration System. They will be reported by the .name Whois service, as described in Appendix O. A Defensive Registration will not resolve in the DNS. Domain names that would match a Defensive Registration may be registered following the judgement of dispute resolution proceedings or if the Defensive Registration has expired. After such point, the domain name would resolve in the DNS.

Please refer to Appendices G, L and M for more information related to Defensive Registrations.

C. NameWatch Service

The NameWatch Service is a monitoring service available through registrars that notifies subscribers to the service when domain names or SLD E-mail addresses are initially registered in the .name registry. When a domain name or an SLD E-mail address registration matches (i.e. is identical to or includes) a watched string, the NameWatch registrant(s) will receive a notice that the registration was made.

Only initial registrations are watched. Renewals, expirations, changes in contact data, changes in nameservers, transfers between registrars or registrants, and other activity are not watched. The domain name or SLD E-mail address registration will not be blocked or otherwise restricted as a result of a match with a Watched String.

The NameWatch Service allows, at the user's option, for the following matches/comparisons between the string on watch and the domain name or SLD E-mail registration:

  • The watched string matches directly a third level domain (or SLD E-mail user name)
  • The watched string matches directly a second level domain
  • The watched string is a substring of a third level domain (or SLD E-mail user name)
  • The watched string is a substring of a second level domain

As an example, if the strings "exampleA", "exampleB" and "ampleB" are registered in the NameWatch service, registration of the domain name exampleA.exampleB.name, will trigger the a notification for all the above mentioned strings, but not for a watch on "exampleC".

The NameWatch service similarly applies to SLD E-mail registrations. As an example, if the strings "exampleA", "exampleB" and "ampleB" are registered in the NameWatch service, registration of the SLD E-mail exampleA@exampleB.name, will trigger the NameWatch service for all the above-mentioned strings, but not for a watch on "exampleC".

Watched strings must consist entirely of ASCII letters (case insensitive), digits, and hyphens and may not exceed 63 characters in length. The matching of a watched string against substrings will only be done on watched strings of at least three characters. This restriction is to avoid generic entries that will match enormous, and possibly irrelevant, datasets. Because of this restriction, watched strings consisting of only one or two characters will match only identically named domains of one or two characters, which are permitted only at the third level.

NameWatch Interface

The interface for registering NameWatch strings is implemented in the Registrar section of the .name registry website, rather than through the SRS. This web-site interface is protected through the use of SSL (Secure Socket Layer), and only Registrars will be able to access this part of the Registry Operator system.

The character set used for the information submitted through the website will be governed by the type of browser used. Some browsers specify character set types in the content type tag and can thus be handled by the Registrar Operator. However, input from browsers that do not support this feature will be handled with the default character set of ISO 8859-1.

Through the use of a form in the NameWatch interface new entries can be registered and automatically quality checked by the Registry Operator. The form will collect the information needed to add a NameWatch-monitored string, and the registration will be in effect as soon as the criteria for a valid NameWatch string is met, i.e. the string fulfils the maximum length, minimum length and character set requirements.

Information Requested from the Watcher

The ICANN Accredited Registrars will be the intermediate registration point for the Watcher. (I.e. only registrars may use the NameWatch Interface.)

The following information will be requested from the Watcher registering a string into the NameWatch service:

  • The string to be monitored
    Legal characters for this string are letters, digits, and hyphens as defined in the Domain Name Character Set section of Part 13 (Character Sets) of this Appendix. Minimum length is 3 characters and maximum length is 63 characters.

  • Level of monitoring.
    This field is a string that can be either "secondlevel", "thirdlevel" or "both". The character set used for this field should be the Reduced character set defined in Part 13 (Character Sets) of this Appendix.

  • Name of the Watcher registering the string. This could be a company name or the name of an individual. The character set used for this field should either be UTF-8 or ISO 8859-1. The name must be recognizable in ASCII.

  • Contact details of the Watcher registering the string, including but not limited to name and e-mail. The character set used for this field should either be UTF-8 or ISO 8859-1. The name must be recognizable in ASCII and the e-mail address must conform to the E-mail address character set defined in Part 13 (Character Sets) of this Appendix.

  • Expiry of service.
    This field will be a positive integer number specifying the number of years the service is subscribed for. The Character set used for this field is the Reduced character set as specified in section 13 (Character Sets) of this Appendix.

The Watcher will also be able to choose from a set of reporting schemes including:

  • Daily
  • Weekly
  • Monthly

The desired frequency of reporting applies to all NameWatch strings added by the Watcher. The Watcher will get a summary of all strings according to the chosen reporting scheme.

Information Returned to the Watcher

Whenever an initial registration is made that matches the criteria set by the Watcher, information will be gathered about the registration and stored in a logfile. This log will be sent to the Registrar through which the Namewatch registration was done, according to the schedule set up for each NameWatch string. The Registrar can then submit this log to the Watcher.

The logfile will consist of one entry per line. The data in the logfile will be given in the reduced character format with semicolon as the field separator.

Reporting will include status for the strings for which there have been no match and the log for strings for which there exist one or more matches.

The report will be an incremental summary of the integration period spanning from the time of the last report to the time of the new report.

For each entry the Watcher has registered, the following will be included:

If matches have been found in the last integration period:

  • NameWatch entry
    This is the string that the Watcher registered for monitoring in the NameWatch service. (e.g., McDonalds or Disney)
  • Registered domain name that matches string (e.g., Keith.McDonalds.name, or Kenneth.Disney.name)

If no matches were located in the last integration period:

  • Name of the NameWatch entry
    This is the string that the Watcher registered for monitoring in the NameWatch service. (e.g. McDonalds or Disney)
  • String notifying that there has been no matches for this entry.
    The string returned here will be "none".


D. SLD E-Mail Forwarding

Overview

For the purpose of this section D, "Corresponding Name Service" shall designate the relationship between the third level domain name and the SLD E-mail service. The Corresponding Name Service of a third level domain name firstname.lastname.name shall thus be the SLD E-mail address firstname@lastname.name, and vice versa. Further, "Name" shall cover both SLD E-mail addresses and third level domain names.

  • The Registry Operator will provide an e-mail forwarding service enabling firstname@lastname.name email addresses to be registered on second-level .name domain names. Upon receiving a registration request for an SLD E-mail address using a second-level domain name not previously used, the Registry Operator shall enter an MX resource record in the zone file for the second-level domain that references a mail exchanger operated by Registry Operator. This process will not block the chosen second-level domain from usage for normal domain-name registrations.
  • The service will accept incoming email to a firstname@lastname.name address and will forward that mail to an address specified by the user. The service will only offer incoming message forwarding to registered users, and will not provide outgoing SMTP relaying for any users.
  • The SLD E-mail will allow a user to have an email address of the type firstname@lastname.name. The registration of a Name does not obligate a user to purchase the Corresponding Name Service. The user name firstname must comply with the requirements for third-level labels in registered domain names within .name. The registrant has the following options:
    • Register both third level domain name and SLD E-mail (e.g. firstname.lastname.name, and firstname@lastname.name), if both are available;
    • Register the second and third level domain name only, if it is available (e.g. firstname.name or firstname.lastname.name); or
    • Register the SLD E-mail address only, if it is available (e.g. firstname@lastname.name).
  • Upon registration of a Name, the Corresponding Name Service will be reserved for 120 days, if it is not already registered. During this period, a person attempting to register the domain name firstname.example.name would be prevented from doing so if a different person had already registered the SLD E-mail address firstname@example.name. During this reservation period, the registrant will have the option to register the Corresponding Name Service. During the reservation period, only the Authorized Registrar that registered the Name may register the Corresponding Name Service to the registrant. If the Corresponding Name Service remains unregistered after the reservation period expires, it will be released from reservation. Registry Operator reserves the right to change the reservation period upon ninety (90) days notice to the Authorized Registrars.
  • The SLD E-mail registration will be administered and registered through the same interface as for domain names.
  • The eligibility requirements set forth in Appendix L and the enforcement procedures as set forth in Appendix M also apply to SLD E-mail registrations.

Terminology

The following terminology, specific to the e-mail forwarding service, is used throughout this section:

  • forwarding user: A Registrant that has enabled e-mail forwarding
  • forwarding address: E-mail address that a forwarding user wants his/her mail sent to
  • Mail-exchangers: The servers running the email forwarding application.

Implementation details

Multiple mail-exchangers placed in one or more of the Registry Operator's facilities will run this service; these will consist of SMTP mail server software, as specified later in this section, as well as the mail-forwarding server application.

The forwarding application will have access to a local copy of the forwarding database, for the purpose of looking up a user account, and transferring messages from the incoming queue to the outgoing queue, redirected to the forwarding address. A maintenance application is scheduled to run at regular intervals, not to exceed 24 hours, in order to transfer updates and/or an up-to-date copy of the complete forwarding database.

The local copy of the forwarding database shall contain the user's SLD E-mail address as registered with the Registry Operator, and the user-provided forwarding address. No other information about the forwarding user shall be transferred to the mail-exchangers.

Registration interface

The Registry Operator provides a mechanism to register e-mail forwarding information via the SRS interface, as specified in the "SRS interface" section elsewhere in this Appendix. The "SRS interface" section details the specific data required and commands to be used.

As specified in the launch plan, the launch of live registrations for the e-mail forwarding service will occur at the same time as the live SRS interface is launched, and all such registrations will be handled by the live SRS interface. No special provisions are needed to handled e-mail forwarding registrations except for the above mentioned extensions to the SRS interface.

Effect on DNS

E-mails for the forwarded addresses will be sent to one of Registry Operator's mail-exchangers as directed by MX records inserted in the DNS servers for each-second level domain, as referenced in the DNS section in Appendix C, Part 4. This setup will comply with all sections related to mail routing and DNS in RFC 2821, and will be periodically reviewed in order to ensure compliance with updated standards as they become available, to the extent feasible. Changes to DNS MX records will be required only when adding or removing mail-exchangers, and will be handled manually by the operations staff responsible for DNS administration. MX records will be added (or deleted) to reflect the SLDs used by SLD E-mail registrations, as described in Appendix C, Part 4.


Distribution of the forwarding database

A complete copy of the forwarding address database will be distributed to all Registry Operated mail-exchangers at regular intervals, and at least once every 24 hours. This database shall be used by the mail exchangers to determine whether e-mails received have been sent to an existing forwarding user or not.

If the address is valid, the database will be used to determine which address to forward the message to. The distribution of the full forwarding database to each mail-exchanger enables the Registry Operator to increase system stability, as any mail-exchanger in any location can continue providing forwarding service to all forwarding users regardless of the state of the other mail-exchangers.

Standards compliance

The mail-exchangers shall comply with RFC 2821 - Simple Mail Transfer Protocol, including the service extension mechanism, and the specific service extensions "8bit-MIMEtransport", as specified in RFC 1652, and "SMTP Command Pipelining," as specified in RFC 2920.

The e-mail forwarding system shall be 8bit clean, but shall not assume that receiving systems are 8bit clean, except as allowed by the service extension defined in RFC 1652, as mentioned above.

This service places no restrictions on the content encoding or character sets used in the headers or body of a mail message, as long as such encodings and character sets comply with internet mail standards, and specifically that the encoding of headers and body follows the requirements set out in RFCs 2822 - Internet Message Format, 2076 - Common Internet Message Headers, and 2045-2049 (MIME).

This includes, but is not limited to, accepting messages using MIME encoding to support alternative character sets and character set encodings for internationalization purposes both in the message header and body.

However, the service shall not actively attempt to reject messages violating the requirements mentioned in the above paragraph, unless such violations result in the system being unable to reliably determine the intended recipient, and/or such violations lead to the message being rejected by the receiving mail system. The Registry Operator shall not be responsible for updating its software in order to prevent the rejection of any messages that violate above-mentioned standards.

Further SMTP Service Extensions will be implemented at the Registry Operator's discretion as the need arises, to ensure proper interoperability with common mail systems and expected client functionality. Further Service Extensions will be documented as and when they are added.

The mail-exchangers shall forward any message which meets with the requirements stated above, except in the cases where such messages exceed size or rate limits defined in the e-mail forwarding service definition (such definition to be provided to ICANN during the implementation process); in the case of messages exceeding those limits, the decision to allow or deny forwarding of such messages is at the Registry Operator's discretion. Such decisions should apply to the entire system, and not be applied to specific users or groups of users (except in the case that multiple service levels at differentiated fees are introduced), and should be enforced without regard for the actual content of such messages.

Registry Operator shall monitor applicable standards development, and seek to adopt updates, security fixes and related changes on an ongoing basis to ensure secure and stable email delivery to the forwarding users.

Unsolicited Commercial Email

To reduce the problem of Unsolicited Commercial Email (UCE or "spam"), the Registry Operator shall seek to implement the relevant parts of RFC 2505 - Anti-Spam Recommendations for SMTP MTAs. Specifically, the Registry Operator's mail-exchangers will not allow un-authenticated relaying in any form.
The Registry Operator will further, in line with the recommendations in RFC 2505, ensure that forwarded e-mail contains the appropriate header information to facilitate tracing of the original sender in the case of abuse, and will maintain logs of forwarded mails to the extent required and allowed by applicable law, in order to be able to assist in tracing the originator of traffic that violate terms of use, or in cases where Registry Operator is required by law to do so.

Registry Operator reserves the right to implement recommendations in RFC 2505 at its discretion regarding rate control of messages, blocking of specific domains or users, and restrictions to SMTP commands not required for normal operators.

In the case of blocking of users or domains, or rate control targeting specific users or domains, such blocking or rate control shall not be done arbitrarily, and should be the result of documented abuse of the system to send unsolicited commercial e-mail to Registry Operators forwarding users. Commands that may be restricted include, but are not limited to, "VRFY" and "EXPN"", as defined in RFC 2821.

Registry Operator further reserves the right to implement additional anti-spam measures, such as using MAPS RBL, to block UCE or mail from systems with a history of abuse from entering the Registry Operator's mail-forwarding service. However, due to the nature of such systems which actively block messages, Registry Operator shall make public any decision to implement such systems a reasonable time in advance, so as to allow Registrars or Registrants to give feedback on the decision.

In order to facilitate reactions to unsolicited commercial e-mail, or other abuse of the system, the Registry Operator shall publish an e-mail address that can be used by users of the mail-forwarding service and/or third parties that wish to complain about abuse of the forwarding service or the forwarding addresses. Registry Operator reserves the right to cancel forwarding service for users that systematically abuse the system.

Acceptable use policy

An "Acceptable Use Policy" which specifies what constitutes abuse of the email forwarding system shall be made available to the Registrant either from the Registrar that the Registrant registers through, or from the Registry Operator's website. The Registry Operator may update this "Acceptable Use Policy" when required, and will inform Registrars about such updates, making the updated version available to the public.

Unless significant changes are made, the Registry Operator is not required to directly contact Registrant to inform about such changes, and in the event of significant changes, sending e-mail to all registered forwarding addresses shall be considered as proper notice.

Handling of outgoing mail and delivery errors

Messages received by the mail-exchangers addressed to a valid forwarding user will be placed in the outgoing mail queue. Messages will stay in the queue until successfully delivered, until the receiving mail server has rejected the message with a fatal error message (as defined in RFC 2821) that indicate that message can not be delivered, or until a fixed number of days (not fewer than five) have passed. The Registry Operator may at its own discretion implement features to give the originator of the message a warning of delays, but is not required to do so.

In the case that the mail-exchanger is unable to deliver a message within the period, whether due to local or remote errors, or Registrant or Registrar error when registering the forwarding address, an error message will be sent to the originator of the message, stating the technical nature of the error.

Such a message shall at least contain the intended recipient of the message, the subject of the failed message, the date as found in the message headers, whether the error was local or remote, and a readable English text message identifying the type of problem.

The message should also include an e-mail address that can be used in the case that the user has questions about the reasons of failure. Registry Operator does not guarantee individual responses in the case of major failures in the system, and can in such circumstances respond to users by automated messages explaining the nature of the problem.

E-mail communication and mass mailings to forwarding users

Registry Operator is allowed to use the forwarding address to inform the forwarding users about important technical and/or operational issues that may affect the availability of the forwarding service in the case of unavailability or scheduled maintenance. Registry Operator is however not required to do so except as mandated by courts of law or in the case that Registry Operator choose to promise such updates to Registrants.

Registry Operator will not use the forwarding address for sending e-mails of a commercial nature unless permission for such mailings is explicitly granted by Registrant (known as the "opt-in").

Operating parameters

The service will be running on multiple servers in multiple locations each holding a complete copy of the forwarding database. This enables the Registry Operator to increase capacity and redundancy when needed, and enables the system to remain fully operational as long as at least one mail-exchanger is operational.

Adding additional mail-exchanger requires only that a copy of the required mail forwarding software be installed, and a copy of the forwarding database be transmitted to the new mail-exchanger, followed by adding the new mail-exchanger in Registry Operator's DNS servers, and can thus be made without disrupting other services provided.

Reporting

The Registry Operator will create statistics on the number of users on the service, amount of email traffic forwarded and other network statistics for internal operations. As required by courts of law or allowed by Registry Operators Acceptable Use Policy for the email forwarding service, Registry Operator may also make reports documenting usage patterns and log information available to appropriate parties for the purpose of tracing any person or persons using the service for unlawful purposes or in violation of said policy document.

Security

General security measures such as password aging policy, firewalls, IDS and network traffic monitoring systems will be provided for the email forwarding servers by using the facilities already available to the rest of the system. In addition, the email forwarding servers may employ measures outlined in RFC 2505 or elsewhere to limit incoming traffic from systems that threaten the stability or security of the forwarding service by abuse or user error.

Previous Version:

3 July 2001


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 12-Aug-2003
(c) 2001, 2002, 2003  The Internet Corporation for Assigned Names and Numbers. All rights reserved.