Our data structure has been changed to align more closely to the EPP standard data structure.

Our current data structure is account centric - customers have accounts with services attached to them. All accounts are the same - registrants have an account with a registrant service, whilst registrars have accounts with a registrar service and potentially other services such as PRSS and Membership.

The registrant data is split out from other account data which will change the data structure for registrants to match that of the domain schema for the EPP RFCs. The resultant structure for domain data will be simpler and is shown in the following diagram:



Domain names will have a registrant contact, which is the equivalent of the current registrant account along with the main admin contact. There will be no additional admin contacts.

Data elements of the domain contact

The following table shows the data elements of the domain contact, as accessible through Standard EPP, Nominet EPP and Automaton domain name templates.

Standard EPP	Nominet EPP	Automaton domain	Description
<contact:id>	<account:roid>	account-id	Identifier of registrant contact
<contact:name>	<contact:name>	a1-name	Contact name
<contact:org>	<account:name>	account-name	Organisation name. This is the name of the registrant
<contact-nom-ext:trading>	<account:trad-name>	roitrad-name	Trading name
<contact-nom-ext:type>	<account:type>	type	Organisation type
<contact-nom-ext:co-no>	<account:co-no>	co-no	Company number
<contact-nom-ext:opt-out>	<account:opt-out>	opt-out	Whois opt out field
<contact:street>	<account:street>	addr	Address line
<contact:city>	<account:city>	city	City
<contact:sp>	<account:county>	county	County
<contact:pc>	<account:postcode>	postcode	Postcode
<contact:cc>	<account:country>	country	Two letter country code
<contact:voice>	<contact:phone>	a1-phone	Phone number
<contact:email>	<contact:email>	a1-email	Email address

Summary of changes

Description of changes to operations

Nominet EPP

<domain:create> operation

<contact:create> elements with order attribute of "2" or "3" will be deprecated. Any data provided in these fields will be deleted and a warning generated.

The <contact:mobile> element will no longer be used. Data provided in this element will be ignored and a warning message will be provided.

The response to a <domain:create> operation will include identifiers of any new contact objects created. The account identifier and the first contact identifiers given will both give the registrant contact identifier and will be identical. For example:

 ...
     <domain:name>example.co.uk</domain:name>
      <domain:account>
       <account:creData>
         <account:roid>100029-UK</account:roid>
         <account:name>Mr R. Strant</account:name>
         <account:contact order="1">
          <contact:creData>
           <contact:roid>C100029-UK</contact:roid>
           <contact:name>Mr R. Strant</contact:name>
          </contact:creData>
         </account:contact>
       </account:creData>
      </domain:account>

<update> operations

All <contact:update> or <contact:create> fields with order attribute of "2" or "3" will be deprecated. Any data provided in these fields will be ignored and a warning generated.

The facility to include <contact:roid> or <contact:create> elements within a <domain:update> or <account:update> operation will be withdrawn.

The <contact:mobile> element will no longer be used. Data provided in this element will be ignored and a warning message will be provided.

The <contact:update> operation will be withdrawn. The <account:update> and <domain:update> operations can also be used to update the contact name, phone and email address along with other fields.

<info> operations

The <contact:info> operation will be withdrawn.

The <contact:mobile> fields will be deprecated and will no longer be returned.

For <account:info> and <domain:info>, only the first admin contact details will be returned.

The <account:id> field will contain the registrant contact identifier. The first <contact:id> field returned will also contain this identifier.

<account:fork> operation

This will be used to move domain names associated with a registrant contact to a copy of that contact.

<account:merge> operation

This operation will be withdrawn. This change will be coupled with a change to online services to allow group operations on domain names with the same log-in credentials and so it will no longer be necessary to merge accounts in order to conveniently perform registrant transfers.

Notifications

The registrar change and registrant transfer notifications include the <account:contact> element. For the first of these, the <contact:id> sub-element will be identical to the <account:id> field.

The <contact:mobile> fields will be deprecated and no longer included in any notifications.

<domain:transfer> operation

The <domain:account> field in this operation will be withdrawn. Any transfer requests containing this field will be rejected.

<domain:list> operation

The response to list requests where the <domain:fields> field is set to "all" contains <domain:infData> objects, and so the changes described above to the <domain:info> operation applies.

Standard EPP

There will be no syntactic changes to standard EPP.

Automaton

Create operation

All a2- and a3- fields will be deprecated. Any data provided in these fields will be ignored and a warning returned. The a1-mobile field will also be deprecated.

The response to domain create operations will include the identifiers of the registrant contact if a new one is created.

...
and of our understanding that you have the applicant's full authority to
agree to such terms on the applicant's behalf.

The following identifiers were created as part of your registration:
Registrant Contact: 000000

Thank you.

Regards

Nominet

There will be no prefixes to contact identifiers.

Modify operation

All a2- and a3- fields will be deprecated. Any data provided in these fields will be ignored and a warning returned. The a3-mobile field will also be deprecated.

The contact modify operation will be withdrawn. The contact name, email address and phone fields can be modified using either the account modify or domain modify operations.

Query operation

All a2- and a3- fields will be deprecated and no longer returned. The a1-mobile field is also deprecated.

The a1-id field and account-id fields will contain the registrant contact identifier and will be identical.

Fork operation

This will be used to move domain names associated with a registrant contact to a copy of that contact.

Merge operation

This operation will be withdrawn. This change will be coupled with a change to online services to allow group operations on domain names with the same log-in credentials and so it will no longer be necessary to merge accounts in order to conveniently perform registrant transfers

Notifications

When the a1-id field is returned as part of a notification (registrar change and registrant transfer notifications), it will contain the registrant-contact identifier and will be identical to the account-id field.

All a2- and a3- fields, along with the a1-mobile fields will be deprecated and no longer included in any notifications.

Domain release operation

The account-id field will be deprecated from this operation. Release requests containing this field will be rejected.

List operation

The registrant contact name and organisation name will be returned as part of the default list in the following format:

Domain Name List follows...

Domain name|reg-status|registrar-tag|created|changed|expiry|first-bill|recur-bill|
auto-bill|next-bill|dns0|dns1|dns2|dns3|dns4|dns5|dns6|dns7|dns8|dns9|
account-id|account-name|reseller


Number of domains in the list: [Number].

If you have any questions please contact support@nominet.org.uk.

Documentation on the automaton can be found on the Nominet Web site 
at http://www.nominet.org.uk/go/automaton

If the following field

fields: all

is included in the list template then the reply template will be as follows:

Domain Name List follows...

Domain name|reg-status|registrar-tag|created|changed|expiry|first-bill|recur-bill|
auto-bill|next-bill|dns0|dns1|dns2|dns3|dns4|dns5|dns6|dns7|dns8|dns9|
account-id|account-name|trad-name|type|co-no|opt-out|addr|city|county|
postcode|country|a1-name|a1-phone|a1-email

Number of domains in the list: [Number].

If you have any questions please contact support@nominet.org.uk.

Documentation on the automaton can be found on the Nominet Web site 
at http://www.nominet.org.uk/go/automato

Bulk operation

It will be possible to use the fields shown in the following table in filter clauses.

Filter Field	Comparison operators	Other notes
auto-bill	=
city	=, like	Matches on city field in registrant contact
co-no	=, like	Matches company number on registrant contact
county	=, like	Matches county field in registrant contact
country	=	Matches country field in registrant contact
created	=, >, <, >=, <=	'rvalue' must be a valid YYYYMMDD date.
email	=, like
expiry	=, >, <, >=, <=	'rvalue' must be a valid YYYYMMDD date.
first-bill	=
key	=, like	Matches on email address for registrant contact
name	=, like	Matches on the registrant contact's name field
next-bill	=
nservers	=	Takes nameserver list as 'rvalue'; e.g. ['ns1.co.uk', 'ns2.co.uk'].
nservers	in	Takes nameserver as 'lvalue'; e.g. 'ns1.co.uk' in nservers.
notes	=, like
opt-out	=
account-name	=, like	Matches on the registrant contact's organisation name field
postcode	=, like	Matches on postcode field on registrant contact
recur-bill	=
account-id	=	Matches on the registrant contact identifier
reseller	=, like
trad-name	=, like	Matches on the trading name field in the registrant contact
type	=, like	Matches on the type field in the registrant contact.

All a2- and a3- fields along with the a1-mobile field will no longer be available to be used in select clauses. If the a1-id field is used in a select clause, the registrant contact identifier will be returned.