| gTLD | Full Legal Name | E-mail suffix | Detail | | .tci | Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. | nsline.com | View |
CoCCA was among the first registry providers to embrace the EPP standard seven years ago. CoCCAʹs traditional clients have been small to medium sized ccTLD operators un-encumbered by the legal, contractual and governance issues that often result in protracted delays in rolling out new policy, technology or standards in larger ccTLDs or in the gTLD environment. CoCCA and the users of its SRS software have been historically free to trial and introduce innovative technology policy.
The CoCCA SRS is an ʺall in oneʺ software package ( RDDS⁄ EPP⁄ GUI ⁄ Accounting ) however this does not prevent it from being deployed in a clustered environment where multiple instances answer for a specific protocol under a load balanced, high availability environment. Using a load balance appliance EPP traffic can be sent to one or more servers which are in turn connected to the same database. In all small to medium sized deployments tested to date load balancing the EPP service is not required - the load balancer is simply configured to provide failover and HA.
An aggressive three-year development program commenced in January 2009 with the objective of ensuring CoCCAʹs software was compliant with ICANNʹs new gTLD requirements - as well as the meeting needs of new and existing users in the ccTLD community.
25.1 Current EPP RFC Compliance:
RFC 5730 Extensible Provisioning Protocol (EPP)
This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The pamoja SRS fully implements the service discovery, commands, responses, and the extension framework described.
RFC 5730
This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The pamoja SRS fully implements the service discovery, commands, responses, and the extension framework described.
RFC 5731
This RFC explains the mapping of the primary EPP registry object, the domain object. It reviews associated attributes and states of the domain object as well as child object relationships (hosts). It also details associations with other contact objects. The pamoja SRS complies with the full XML examples and descriptions and applies flexibility where permitted. For example, 5731 allows operators to implement the info command with different responses for a “sponsoring registrar” and a “non-sponsoring registrar” in regards to many domain object attributes. The pamoja SRS implements this as a base protocol document for EPP.
RFC 5732
The pamoja SRS implements this as a base protocol document for EPP. The pamoja SRS notes this RFC describes the mapping of relationships to host objects, which are by definition subordinate to the superordinate domain name object. Host objects that are defined as internal or in the namespace of the registry must be related to a superordinate domain object to be created. Internal hosts, as full child objects, face restrictions associated with the management of their superordinate domain object. External hosts are hosts belonging to another domain namespace and as such are not subordinate in the present namespace. Internal hosts can have a glue or an A record associated with them, external hosts refer to another namespace or zone for the associated A record.
RFC 5733
Another RFC implemented in the The pamoja SRS server, this RFC describes the contact object mappings in EPP. Contact objects are used to contain related data surrounding the standardized contacts types in TLD registries including attributes such as contact type, country, telephone numbers, email addresses, etc. As a standalone object, a contact object can be created and associated with no domain objects or with any number of domain objects available in the registry. This is used commonly by registrars to update common contact information associated across large numbers of domains in a single transaction. Like the domain object, it can be secured with a passphrase or “authinfo” code. Contact object data represents the definitive data source for authoritative RDDS (WHOIS) in new TLDs.
RFC 5734
The pamoja SRS implements this RFC as the preferred industry transport and in compliance with ICANNʹs requirements. This RFC describes a standard implementation of TCP incorporating TLS. The transport of choice for the EPP registry community has been TCP. Implementers are encouraged to take precautions against denial of service attacks through the use of standard technologies such as firewall and border router filters.
RFC 5735
The pamoja SRS implements this RFC as applicable to any extensions it utilizes as this RFC provides specific and detailed guidance on EPP extensions. An important principle in creating extensions to, as opposed to modifying, the EPP protocol was to fully preserve the integrity of the existing protocol schema. Additionally, a valid extension itself should be extensible. Another important requirement in the RFC is to include announcements of all available extensions in the EPP server greeting element before establishing an interactive client session.
RFC 3915
The pamoja SRS supports this extension since this all CoCCA managed TLDs implement the grace period implementation known as the Redemption Grace Period or “RGP”. When RGP is in use, domains are deleted into the RGP where Registrars may request a restoration of the domain. This is a billable event and requires a three-step process: placement of the domain into a pending restore state, submission of a restore report explaining why the domain is being restored, and finally the restoration of the domain. The RFC extends the domain update command, adds related domain statuses, such as ʺredemptionPeriodʺ and ʺpendingRestore,ʺ and extends the responses of domain info and other details. The RFC provides a lifecycle description of the RGP and defines the format and content for client to server submission of the associated restore reports.
RFC 5910
The pamoja SRS will support DNSSEC and therefore will also support this extension from initiation of the registration process. DNSSEC is a mechanism for cryptographically verifying that each delegate zone in the DNS hierarchy has been referred to or is referring to its genuine parent or child zone respectively. Since TLD zone files are generated from authoritative registry data, this extension specifically provides the ability to add elements to the domain-create and domain-update functions and to the domain-info responses, allowing registrars to submit associated delegated signer (DS) information of the child zone indicating it is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone.
SRS General
The pamoja SRS Session Management - pamoja listens on port 700 for client requests.
The pamoja SRS Message Exchange - pamoja complies with the EPP message exchange rules
The pamoja SRS Data Unit Format - pamoja uses the prescribed packet formats
25.2 EPP Security:
CoCCAʹs SRS performs username⁄clid⁄password⁄ssl certificate checks and also contains application level code to restrict connections to a set of IP addresses for each client and login.
Additional security is provided by firewall IP restrictions that restrict port 700 access to the SRS to trusted IPʹs and the use of stateful firewalls and load balancing devices to mitigate DoS attacks or other malicious activity.
25.3 EPP - Demonstrating Capability
CoCCA authors the most widely deployed EPP SRS solution and has a long history of both development of and production experience operating an EPP SRS. The CoCCA NOC currently has 12 TLDs on itʹs production EPP SRS, over 20 TLD managers have deployed the CoCCA EPP solution locally for production use.
In order to demonstrate capability and compliance with the RFCʹs in 24.1 and CoCCAʹs Extensions in 25.3. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has instructed CoCCA to make available to evaluators an Operational and Testing and Evaluation (OTE) EPP interface should they desire to evaluate CoCCAʹs RFC compliance. Alternatively, evaluators may download CoCCAʹs pamoja SRS, install locally and contact CoCCA for configuration advice.
The URL to download pamoja is https:⁄⁄downloads.coccaregistry.net. Installers are available for Linux64x ( Centos ⁄ Ubuntu ), OSX (10.6+) and WIN7+ servers.
25.3 EPP Extensions
The CoCCA SRS currently provides several extensions to EPP, using the practices defined in RFC-3735. The CoCCA greeting currently defines the following four extensions:
...
〈svcMenu〉
...
〈objURI〉urn:ietf:params:xml:ns:host-1.0〈⁄objURI〉
〈svcExtension〉
〈extURI〉urn:ietf:params:xml:ns:rgp-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-ip-verification-1.1〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-contact-proxy-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-contact-proxy-create-update-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-reseller-1.0〈⁄extURI〉
〈⁄svcExtension〉
〈⁄svcMenu〉
...
25.3.1 Registry Grace Period Extension
〈extURI〉urn:ietf:params:xml:ns:rgp-1.0〈⁄extURI〉
Implemented as defined in RFC-3915 - http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt
25.3.2 Reseller Mapping Extension
〈extURI〉https:⁄⁄..⁄cocca-reseller-1.0〈⁄extURI〉
Extensions for Domain:Create and Domain:Update
This extension tags a domain as being registered via one of registrarsʹ resellers. The reseller reference is provided in the reference section, and is recorded against the domain as it is registered or updated. The reseller list must be maintained by the Registrar through the CoCCA Registry web interface.
If a registrar decides to load reseller information and map domains, the .tci WHOIS server (port 43 and 443), Historical Abstracts, and Premium WHOIS will display the reseller contact information as well as the Registrar information. If ICANN advises that display of reseller information in the port 43 WHOIS is inconsistent with the response format required in Specification 4, 1.4.2 then CoCCA will disable port 43 and or port 443 display of reseller data for the .tci TLD. Reseller information would still be stored and available for Historical Abstracts and users of the CoCCAʹs Premium WHOIS service.
〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺʺ〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:element name=ʺextensionʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ type=ʺxs:stringʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:schema〉
〈extension〉
〈reseller:extension xmlns:reseller=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ〉
〈reseller:reference〉XXXXX〈⁄reseller:reference〉
〈⁄reseller:extension〉
〈⁄extension〉
25.3.3 Clearinghouse for Intellectual Property Extension
Extension to connect to an external database to validate IP rights.
〈extURI〉https:⁄⁄..⁄coccaregistry.net⁄cocca-ip-verification-1.1〈⁄extURI〉
Extension for Domain:Create
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-ip-verification-1.1ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:annotation〉
〈xs:documentation〉
Extensible Provisioning Protocol v1.0
Extension for providing IP Verification to CoCCA Registries
v1.1 adds extra fields for trademark verification
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈xs:element name=ʺextensionʺ〉
〈xs:complexType〉
〈xs:choice〉
〈xs:element name=ʺchipʺ type=ʺchipTypeʺ⁄〉
〈xs:element name=ʺtrademarksʺ type=ʺtrademarkTypeʺ⁄〉
〈⁄xs:choice〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈xs:complexType name=ʺchipTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺcodeʺ〉
〈xs:simpleType 〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈xs:complexType name=ʺtrademarkTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺtrademarkʺ minOccurs=ʺ1ʺ maxOccurs=ʺunboundedʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺregisteredMarkʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺregistrationNumberʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺregistrationLocalityʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:pattern value=ʺ[A-Z]{2}ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcapacityʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:enumeration value=ʺOWNERʺ⁄〉
〈xs:enumeration value=ʺASSIGNEEʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcompanyNumberʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:schema〉
This extension allows registrars to provide proof of their Intellectual Property claim for a name, when registering. It can be used to specify Clearing House for IP codes, or Trademarks. A CHIP request XML is as follows:
〈extension〉
〈coccaip:extension xmlns:coccaip=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ〉
〈coccaip:chip〉
〈coccaip:code〉XXXXXXX〈⁄coccaip:code〉
〈⁄coccaip:chip〉
〈⁄coccaip:extension〉
〈⁄extension〉
An extension containing trademark information is as follows:
〈extension〉
〈coccaip:extension xmlns:coccaip=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ〉
〈coccaip:trademarks〉
〈coccaip:trademark〉
〈coccaip:registeredMark〉CoCCA〈⁄coccaip:registeredMark〉
〈coccaip:registrationNumber〉12345〈⁄coccaip:registrationNumber〉
〈coccaip:registrationLocality〉NZ〈⁄coccaip:registrationLocality〉
〈coccaip:capacity〉OWNER〈⁄coccaip:capacity〉
〈coccaip:companyNumber〉1234〈⁄coccaip:companyNumber〉
〈⁄coccaip:trademark〉
〈⁄coccaip:trademarks〉
〈⁄coccaip:extension〉
〈⁄extension〉
At the time of application it is not envisioned that this extension will be used for the .tci TLD. However it demonstrates an existing technical capacity to query and synchronize data with external databases in order to validate IP or other rights.
25.3.4 Contact Proxy Extension
〈extURI〉https:⁄⁄ epp.ote.tci.coccaregistry.net⁄cocca-contact-proxy-1.0〈⁄extURI〉
Extension to allow registrars to lodge several sets of contact details for a given domain and select which one is displayed in the port WHOIS.
https:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0 and https:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0 - extensions for Contact:Create and Contact:Update.
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ
xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
xsi:schemaLocation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0 cocca-contact-proxy-1.0.xsdʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:import namespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ schemaLocation=ʺcocca-contact-proxy-1.0.xsdʺ⁄〉
〈xs:annotation〉
〈xs:documentation〉
Extensible Provisioning Protocol v1.0
Extension for creating or updating a contact, with proxy information. This proxy information
is provided as a WHOIS response, instead of the contactʹs real information if zone settings
allow. Proxy information may be specified in full, by providing all the details or by using a
reference to a previous contact proxy info. If you want to clear a contactʹs proxy info, send
an existingProxy type request with an empty reference string.
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈xs:element name=ʺextensionʺ〉
〈xs:complexType〉
〈xs:choice〉
〈xs:element name=ʺnewProxyʺ type=ʺproxyTypeʺ⁄〉
〈xs:element name=ʺexistingProxyʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ type=ʺproxy:referenceTypeʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:choice〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈xs:complexType name=ʺproxyTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺproxyDetailsʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ minOccurs=ʺ0ʺ type=ʺproxy:referenceTypeʺ〉
〈xs:annotation〉
〈xs:documentation〉
This is an optional field you can use to give this proxy info a particular reference.
Each reference must be unique, so if you have an existing contact proxy info record
with this reference value, you will UPDATE that record, changing the proxy info for
any existing contact referencing that proxy.
If you donʹt specify a reference, one will be created for you and returned in the EPP
response.
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈⁄xs:element〉
〈xs:element name=ʺemailʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺvoiceʺ type=ʺproxy:phoneNumberTypeʺ⁄〉
〈xs:element name=ʺfaxʺ minOccurs=ʺ0ʺ type=ʺproxy:phoneNumberTypeʺ⁄〉
〈xs:element name=ʺinternationalAddressʺ type=ʺproxy:addressTypeʺ⁄〉
〈xs:element name=ʺlocalAddressʺ type=ʺproxy:addressTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈xs:element name=ʺresDataʺ〉
〈xs:annotation〉
〈xs:documentation〉
If a contact is created or updated with contact proxy information specified, or if the registrar
creating the contact has a default proxy specified, then the reference value identifying the proxy
is returned in the response, in the extension⁄resData field described here. If the contact was updated to
clear the reference field (i.e. setting the contactʹs proxy using the existingProxy type, but leaving
the reference field empty) then the reference value will be empty, confirming the update.
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ type=ʺproxy:referenceTypeʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:schema〉
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:simpleType name=ʺreferenceTypeʺ〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ40ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈xs:complexType name=ʺphoneNumberTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺnumberʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ64ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺextensionʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ64ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈xs:complexType name=ʺaddressTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺstreet1ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺstreet2ʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺstreet3ʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcityʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺstateProvinceʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺpostcodeʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcountryCodeʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:pattern value=ʺ[A-Z]{2}ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:schema〉
This extension allows the association of a contact proxy with a contact.
The contact:create and contact:update extensions can specify an existing proxy contact by ID. or create a new proxy contact. To associate a contact with an existing contact proxy, use this form:
〈extension〉
〈proxyupdate:extension xmlns:proxyupdate=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ〉
〈proxyupdate:existingProxy〉
〈proxy:reference xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ〉XXXXX〈⁄proxy:reference〉
〈⁄proxyupdate:existingProxy〉
〈⁄proxyupdate:extension〉
〈⁄extension〉
where XXXXX is the ID of the proxy contact you wish to use. To create a new contact and associate it with a contact, use this form of the create or update extension:
〈extension〉
〈proxyupdate:extension xmlns:proxyupdate=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ〉
〈proxyupdate:newProxy〉
〈proxyupdate:proxyDetails〉
〈proxy:reference〉XXXXX〈⁄proxy:reference〉
〈proxy:email〉XXXXX〈⁄proxy:email〉
〈proxy:voice〉
〈proxy:number〉XXXXX〈⁄proxy:number〉
〈proxy:extension〉XXXXX〈⁄proxy:extension〉
〈⁄proxy:voice〉
〈proxy:internationalAddress〉
〈proxy:street1〉XXXXX〈⁄proxy:street1〉
〈proxy:street2〉XXXXX〈⁄proxy:street2〉
〈proxy:city〉XXXXX〈⁄proxy:city〉
〈proxy:stateProvince〉XXXXX〈⁄proxy:stateProvince〉
〈proxy:postcode〉XXXXX〈⁄proxy:postcode〉
〈proxy:countryCode〉XXXXX〈⁄proxy:countryCode〉
〈⁄proxy:internationalAddress〉
〈⁄proxyupdate:proxyDetails〉
〈⁄proxyupdate:newProxy〉
〈⁄proxyupdate:extension〉
〈⁄extension〉
At the time of application it is not envisioned that this extension will be used for the .tci TLD.
Other:
In addition to the above statuses, the CoCCA Registry provides additional lifecycle statuses over and above those defined in RFC-5731. The CoCCA Activation statuses are provided using namespaced status elements in the Domain:Create and Domain:Info responses, and are accompanied by an RFC-3735 compliant extension section. A Domain:Create response for a newly registered domain would appear as follows:
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈response〉
〈result code=ʺ1000ʺ〉
〈msg〉Command completed successfully〈⁄msg〉
〈⁄result〉
〈msgQ count=ʺ229ʺ id=ʺ21192ʺ⁄〉
〈resData〉
〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉info.confirm.test〈⁄domain:name〉
〈domain:roid〉234511-CoCCA〈⁄domain:roid〉
〈domain:status s=ʺinactiveʺ〉Delegation information has not been supplied〈⁄domain:status〉
〈activation:status xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ s=ʺpendingActivationʺ〉
This domain requires acceptance of AUP and registrant agreement by 2012-02-29 10:19
〈⁄activation:status〉
〈domain:registrant〉regis-80ESBqGtje〈⁄domain:registrant〉
〈domain:clID〉registrar〈⁄domain:clID〉
〈domain:crID〉registrar〈⁄domain:crID〉
〈domain:crDate〉2012-02-21T21:19:32.887Z〈⁄domain:crDate〉
〈domain:exDate〉2013-02-21T21:19:33.006Z〈⁄domain:exDate〉
〈domain:authInfo〉
〈domain:pw〉Hh7Wz3c9dC〈⁄domain:pw〉
〈⁄domain:authInfo〉
〈⁄domain:infData〉
〈⁄resData〉
〈extension〉
〈rgp:infData xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsdʺ⁄〉
〈activation:extension xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ〉
〈activation:url〉https:⁄⁄registry-adam⁄activate.jsp?activationCode=ITIhi1kma8SmbCsYefY18uEaJikwOXKNL0MLu0HHXkXjZUynrDZZUh6SB2h8h1D8〈⁄activation:url〉
〈activation:link〉⁄activate.jsp?activationCode=ITIhi1kma8SmbCsYefY18uEaJikwOXKNL0MLu0HHXkXjZUynrDZZUh6SB2h8h1D8〈⁄activation:link〉
〈⁄activation:extension〉
〈⁄extension〉
〈trID〉
〈clTRID〉CR-4〈⁄clTRID〉
〈svTRID〉1329859182069〈⁄svTRID〉
〈⁄trID〉
〈⁄response〉
〈⁄epp〉
25.4 EPP Access Requirements
1. IP Address white listing ( firewall and application layer )
2. Signed registry issued SSL certificates
3. Username⁄Password
Authentication requires that the IP address the connection is made from be white listed IP, that the entity connecting use a CoCCA-issued SSL certificate and that correct clientID and passwords be used. By default registrars have only GUI access to the SRS, EPP is enabled by request and only after a Registrar has been certified on CoCCAʹs OT&E platform.
25.5 CoCCA GUI Environment
In addition to providing the standard implementation of EPP that runs on Port 700, CoCCA also provides a secure web based Graphical User Interface running on Port 443 that allows Registrars to register and manage domains in their portfolio without connecting by EPP.
25.6 EPP Via the GUI
In cases where a registrar uses the SRS GUI, all domain, host and contact operations supported by the RFCʹs are executed by pamojaʹs internal EPP engine to ensure that GUI and port 700 EPP interfaces behave identically.
These methods of authentication include:
1. IP Address white listing
2. Using a one-time password (ʺOTPʺ) delivered via hardware token, soft token or SMS is issued by CoCCA.
3. The use of a Username⁄Password
25.7 Registrars
A list of registrars that have already successfully integrated and connected to CoCCAʹs SYD SRS is attached. CoCCAʹs SYD SRS is used by 200+ Registrars, many of which currently utilize the XML based EPP protocol for the purpose of providing automated services to their clients.
25.8 Resourcing and Continuous Development
CoCCAʹs software development team and systems administrators support both their own in-house SRS and that of over 23 other TLD managers who have deployed the pamoja SRS software locally on their own infrastructure. Development is on-going and active. The CoCCA SRS has been developed over the past 9 years, the bulk of the development on the EPP platform has been completed, however two full time developers are employed by CoCCA to customize, maintain and improve the software for the TLDʹs that use it.
Because of the co-operative nature of the development process CoCCA works closely with over a dozen developers and network engineers employed by users of CoCCAʹs TLD software to resolve bugs, continuously improve pamojaʹs performance and add new features.
| gTLD | Full Legal Name | E-mail suffix | Detail | | .рус | Rusnames Limited | gmail.com | View |
CoCCA was among the first registry providers to embrace the EPP standard seven years ago. CoCCAʹs traditional clients have been small to medium sized ccTLD operators un-encumbered by the legal, contractual and governance issues that often result in protracted delays in rolling out new policy, technology or standards in larger ccTLDs or in the gTLD environment. CoCCA and the users of its SRS software have been historically free to trial and introduce innovative technology policy.
The CoCCA SRS is an ʺall in oneʺ software package ( RDDS⁄ EPP⁄ GUI ⁄ Accounting ) however this does not prevent it from being deployed in a clustered environment where multiple instances answer for a specific protocol under a load balanced, high availability environment. Using a load balance appliance EPP traffic can be sent to one or more servers which are in turn connected to the same database. In all small to medium sized deployments tested to date load balancing the EPP service is not required - the load balancer is simply configured to provide failover and HA.
An aggressive three-year development program commenced in January 2009 with the objective of ensuring CoCCAʹs software was compliant with ICANNʹs new gTLD requirements - as well as the meeting needs of new and existing users in the ccTLD community.
25.1 Current EPP RFC Compliance:
RFC 5730 Extensible Provisioning Protocol (EPP)
This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The pamoja SRS fully implements the service discovery, commands, responses, and the extension framework described.
RFC 5730
This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The pamoja SRS fully implements the service discovery, commands, responses, and the extension framework described.
RFC 5731
This RFC explains the mapping of the primary EPP registry object, the domain object. It reviews associated attributes and states of the domain object as well as child object relationships (hosts). It also details associations with other contact objects. The pamoja SRS complies with the full XML examples and descriptions and applies flexibility where permitted. For example, 5731 allows operators to implement the info command with different responses for a “sponsoring registrar” and a “non-sponsoring registrar” in regards to many domain object attributes. The pamoja SRS implements this as a base protocol document for EPP.
RFC 5732
The pamoja SRS implements this as a base protocol document for EPP. The pamoja SRS notes this RFC describes the mapping of relationships to host objects, which are by definition subordinate to the superordinate domain name object. Host objects that are defined as internal or in the namespace of the registry must be related to a superordinate domain object to be created. Internal hosts, as full child objects, face restrictions associated with the management of their superordinate domain object. External hosts are hosts belonging to another domain namespace and as such are not subordinate in the present namespace. Internal hosts can have a glue or an A record associated with them, external hosts refer to another namespace or zone for the associated A record.
RFC 5733
Another RFC implemented in the The pamoja SRS server, this RFC describes the contact object mappings in EPP. Contact objects are used to contain related data surrounding the standardized contacts types in TLD registries including attributes such as contact type, country, telephone numbers, email addresses, etc. As a standalone object, a contact object can be created and associated with no domain objects or with any number of domain objects available in the registry. This is used commonly by registrars to update common contact information associated across large numbers of domains in a single transaction. Like the domain object, it can be secured with a passphrase or “authinfo” code. Contact object data represents the definitive data source for authoritative RDDS (WHOIS) in new TLDs.
RFC 5734
The pamoja SRS implements this RFC as the preferred industry transport and in compliance with ICANNʹs requirements. This RFC describes a standard implementation of TCP incorporating TLS. The transport of choice for the EPP registry community has been TCP. Implementers are encouraged to take precautions against denial of service attacks through the use of standard technologies such as firewall and border router filters.
RFC 5735
The pamoja SRS implements this RFC as applicable to any extensions it utilizes as this RFC provides specific and detailed guidance on EPP extensions. An important principle in creating extensions to, as opposed to modifying, the EPP protocol was to fully preserve the integrity of the existing protocol schema. Additionally, a valid extension itself should be extensible. Another important requirement in the RFC is to include announcements of all available extensions in the EPP server greeting element before establishing an interactive client session.
RFC 3915
The pamoja SRS supports this extension since this all CoCCA managed TLDs implement the grace period implementation known as the Redemption Grace Period or “RGP”. When RGP is in use, domains are deleted into the RGP where Registrars may request a restoration of the domain. This is a billable event and requires a three-step process: placement of the domain into a pending restore state, submission of a restore report explaining why the domain is being restored, and finally the restoration of the domain. The RFC extends the domain update command, adds related domain statuses, such as ʺredemptionPeriodʺ and ʺpendingRestore,ʺ and extends the responses of domain info and other details. The RFC provides a lifecycle description of the RGP and defines the format and content for client to server submission of the associated restore reports.
RFC 5910
The pamoja SRS will support DNSSEC and therefore will also support this extension from initiation of the registration process. DNSSEC is a mechanism for cryptographically verifying that each delegate zone in the DNS hierarchy has been referred to or is referring to its genuine parent or child zone respectively. Since TLD zone files are generated from authoritative registry data, this extension specifically provides the ability to add elements to the domain-create and domain-update functions and to the domain-info responses, allowing registrars to submit associated delegated signer (DS) information of the child zone indicating it is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone.
SRS General
The pamoja SRS Session Management - pamoja listens on port 700 for client requests.
The pamoja SRS Message Exchange - pamoja complies with the EPP message exchange rules
The pamoja SRS Data Unit Format - pamoja uses the prescribed packet formats
25.2 EPP Security:
CoCCAʹs SRS performs username⁄clid⁄password⁄ssl certificate checks and also contains application level code to restrict connections to a set of IP addresses for each client and login.
Additional security is provided by firewall IP restrictions that restrict port 700 access to the SRS to trusted IPʹs and the use of stateful firewalls and load balancing devices to mitigate DoS attacks or other malicious activity.
25.3 EPP - Demonstrating Capability
CoCCA authors the most widely deployed EPP SRS solution and has a long history of both development of and production experience operating an EPP SRS. The CoCCA NOC currently has 12 TLDs on itʹs production EPP SRS, over 20 TLD managers have deployed the CoCCA EPP solution locally for production use.
In order to demonstrate capability and compliance with the RFCʹs in 24.1 and CoCCAʹs Extensions in 25.3. [REGISTRY-OPERATOR] has instructed CoCCA to make available to evaluators an Operational and Testing and Evaluation (OTE) EPP interface should they desire to evaluate CoCCAʹs RFC compliance. Alternatively, evaluators may download CoCCAʹs pamoja SRS, install locally and contact CoCCA for configuration advice.
The URL to download pamoja is https:⁄⁄downloads.coccaregistry.net. Installers are available for Linux64x ( Centos ⁄ Ubuntu ), OSX (10.6+) and WIN7+ servers.
25.3 EPP Extensions
The CoCCA SRS currently provides several extensions to EPP, using the practices defined in RFC-3735. The CoCCA greeting currently defines the following four extensions:
...
〈svcMenu〉
...
〈objURI〉urn:ietf:params:xml:ns:host-1.0〈⁄objURI〉
〈svcExtension〉
〈extURI〉urn:ietf:params:xml:ns:rgp-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-ip-verification-1.1〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-contact-proxy-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-contact-proxy-create-update-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-reseller-1.0〈⁄extURI〉
〈⁄svcExtension〉
〈⁄svcMenu〉
...
25.3.1 Registry Grace Period Extension
〈extURI〉urn:ietf:params:xml:ns:rgp-1.0〈⁄extURI〉
Implemented as defined in RFC-3915 - http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt
25.3.2 Reseller Mapping Extension
〈extURI〉https:⁄⁄..⁄cocca-reseller-1.0〈⁄extURI〉
Extensions for Domain:Create and Domain:Update
This extension tags a domain as being registered via one of registrarsʹ resellers. The reseller reference is provided in the reference section, and is recorded against the domain as it is registered or updated. The reseller list must be maintained by the Registrar through the CoCCA Registry web interface.
If a registrar decides to load reseller information and map domains, the .рус (.xn--p1acf) WHOIS server (port 43 and 443), Historical Abstracts, and Premium WHOIS will display the reseller contact information as well as the Registrar information. If ICANN advises that display of reseller information in the port 43 WHOIS is inconsistent with the response format required in Specification 4, 1.4.2 then CoCCA will disable port 43 and or port 443 display of reseller data for the .рус TLD. Reseller information would still be stored and available for Historical Abstracts and users of the CoCCAʹs Premium WHOIS service.
〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺʺ〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:element name=ʺextensionʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ type=ʺxs:stringʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:schema〉
〈extension〉
〈reseller:extension xmlns:reseller=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ〉
〈reseller:reference〉XXXXX〈⁄reseller:reference〉
〈⁄reseller:extension〉
〈⁄extension〉
25.3.3 Clearinghouse for Intellectual Property Extension
Extension to connect to an external database to validate IP rights.
〈extURI〉https:⁄⁄..⁄coccaregistry.net⁄cocca-ip-verification-1.1〈⁄extURI〉
Extension for Domain:Create
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-ip-verification-1.1ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:annotation〉
〈xs:documentation〉
Extensible Provisioning Protocol v1.0
Extension for providing IP Verification to CoCCA Registries
v1.1 adds extra fields for trademark verification
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈xs:element name=ʺextensionʺ〉
〈xs:complexType〉
〈xs:choice〉
〈xs:element name=ʺchipʺ type=ʺchipTypeʺ⁄〉
〈xs:element name=ʺtrademarksʺ type=ʺtrademarkTypeʺ⁄〉
〈⁄xs:choice〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈xs:complexType name=ʺchipTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺcodeʺ〉
〈xs:simpleType 〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈xs:complexType name=ʺtrademarkTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺtrademarkʺ minOccurs=ʺ1ʺ maxOccurs=ʺunboundedʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺregisteredMarkʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺregistrationNumberʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺregistrationLocalityʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:pattern value=ʺ[A-Z]{2}ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcapacityʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:enumeration value=ʺOWNERʺ⁄〉
〈xs:enumeration value=ʺASSIGNEEʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcompanyNumberʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:schema〉
This extension allows registrars to provide proof of their Intellectual Property claim for a name, when registering. It can be used to specify Clearing House for IP codes, or Trademarks. A CHIP request XML is as follows:
〈extension〉
〈coccaip:extension xmlns:coccaip=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ〉
〈coccaip:chip〉
〈coccaip:code〉XXXXXXX〈⁄coccaip:code〉
〈⁄coccaip:chip〉
〈⁄coccaip:extension〉
〈⁄extension〉
An extension containing trademark information is as follows:
〈extension〉
〈coccaip:extension xmlns:coccaip=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ〉
〈coccaip:trademarks〉
〈coccaip:trademark〉
〈coccaip:registeredMark〉CoCCA〈⁄coccaip:registeredMark〉
〈coccaip:registrationNumber〉12345〈⁄coccaip:registrationNumber〉
〈coccaip:registrationLocality〉NZ〈⁄coccaip:registrationLocality〉
〈coccaip:capacity〉OWNER〈⁄coccaip:capacity〉
〈coccaip:companyNumber〉1234〈⁄coccaip:companyNumber〉
〈⁄coccaip:trademark〉
〈⁄coccaip:trademarks〉
〈⁄coccaip:extension〉
〈⁄extension〉
At the time of application it is not envisioned that this extension will be used for the .рус TLD. However it demonstrates an existing technical capacity to query and synchronize data with external databases in order to validate IP or other rights.
25.3.4 Contact Proxy Extension
〈extURI〉https:⁄⁄ epp.ote.рус.coccaregistry.net⁄cocca-contact-proxy-1.0〈⁄extURI〉
Extension to allow registrars to lodge several sets of contact details for a given domain and select which one is displayed in the port WHOIS.
https:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0 and https:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0 - extensions for Contact:Create and Contact:Update.
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ
xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
xsi:schemaLocation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0 cocca-contact-proxy-1.0.xsdʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:import namespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ schemaLocation=ʺcocca-contact-proxy-1.0.xsdʺ⁄〉
〈xs:annotation〉
〈xs:documentation〉
Extensible Provisioning Protocol v1.0
Extension for creating or updating a contact, with proxy information. This proxy information
is provided as a WHOIS response, instead of the contactʹs real information if zone settings
allow. Proxy information may be specified in full, by providing all the details or by using a
reference to a previous contact proxy info. If you want to clear a contactʹs proxy info, send
an existingProxy type request with an empty reference string.
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈xs:element name=ʺextensionʺ〉
〈xs:complexType〉
〈xs:choice〉
〈xs:element name=ʺnewProxyʺ type=ʺproxyTypeʺ⁄〉
〈xs:element name=ʺexistingProxyʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ type=ʺproxy:referenceTypeʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:choice〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈xs:complexType name=ʺproxyTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺproxyDetailsʺ〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ minOccurs=ʺ0ʺ type=ʺproxy:referenceTypeʺ〉
〈xs:annotation〉
〈xs:documentation〉
This is an optional field you can use to give this proxy info a particular reference.
Each reference must be unique, so if you have an existing contact proxy info record
with this reference value, you will UPDATE that record, changing the proxy info for
any existing contact referencing that proxy.
If you donʹt specify a reference, one will be created for you and returned in the EPP
response.
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈⁄xs:element〉
〈xs:element name=ʺemailʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺvoiceʺ type=ʺproxy:phoneNumberTypeʺ⁄〉
〈xs:element name=ʺfaxʺ minOccurs=ʺ0ʺ type=ʺproxy:phoneNumberTypeʺ⁄〉
〈xs:element name=ʺinternationalAddressʺ type=ʺproxy:addressTypeʺ⁄〉
〈xs:element name=ʺlocalAddressʺ type=ʺproxy:addressTypeʺ minOccurs=ʺ0ʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈xs:element name=ʺresDataʺ〉
〈xs:annotation〉
〈xs:documentation〉
If a contact is created or updated with contact proxy information specified, or if the registrar
creating the contact has a default proxy specified, then the reference value identifying the proxy
is returned in the response, in the extension⁄resData field described here. If the contact was updated to
clear the reference field (i.e. setting the contactʹs proxy using the existingProxy type, but leaving
the reference field empty) then the reference value will be empty, confirming the update.
〈⁄xs:documentation〉
〈⁄xs:annotation〉
〈xs:complexType〉
〈xs:sequence〉
〈xs:element name=ʺreferenceʺ type=ʺproxy:referenceTypeʺ⁄〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:element〉
〈⁄xs:schema〉
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈xs:simpleType name=ʺreferenceTypeʺ〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ40ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈xs:complexType name=ʺphoneNumberTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺnumberʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ64ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺextensionʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ64ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈xs:complexType name=ʺaddressTypeʺ〉
〈xs:sequence〉
〈xs:element name=ʺstreet1ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺstreet2ʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺstreet3ʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcityʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ1ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺstateProvinceʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺpostcodeʺ minOccurs=ʺ0ʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:maxLength value=ʺ255ʺ⁄〉
〈xs:minLength value=ʺ0ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈xs:element name=ʺcountryCodeʺ〉
〈xs:simpleType〉
〈xs:restriction base=ʺxs:tokenʺ〉
〈xs:pattern value=ʺ[A-Z]{2}ʺ⁄〉
〈⁄xs:restriction〉
〈⁄xs:simpleType〉
〈⁄xs:element〉
〈⁄xs:sequence〉
〈⁄xs:complexType〉
〈⁄xs:schema〉
This extension allows the association of a contact proxy with a contact.
The contact:create and contact:update extensions can specify an existing proxy contact by ID. or create a new proxy contact. To associate a contact with an existing contact proxy, use this form:
〈extension〉
〈proxyupdate:extension xmlns:proxyupdate=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ〉
〈proxyupdate:existingProxy〉
〈proxy:reference xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ〉XXXXX〈⁄proxy:reference〉
〈⁄proxyupdate:existingProxy〉
〈⁄proxyupdate:extension〉
〈⁄extension〉
where XXXXX is the ID of the proxy contact you wish to use. To create a new contact and associate it with a contact, use this form of the create or update extension:
〈extension〉
〈proxyupdate:extension xmlns:proxyupdate=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ〉
〈proxyupdate:newProxy〉
〈proxyupdate:proxyDetails〉
〈proxy:reference〉XXXXX〈⁄proxy:reference〉
〈proxy:email〉XXXXX〈⁄proxy:email〉
〈proxy:voice〉
〈proxy:number〉XXXXX〈⁄proxy:number〉
〈proxy:extension〉XXXXX〈⁄proxy:extension〉
〈⁄proxy:voice〉
〈proxy:internationalAddress〉
〈proxy:street1〉XXXXX〈⁄proxy:street1〉
〈proxy:street2〉XXXXX〈⁄proxy:street2〉
〈proxy:city〉XXXXX〈⁄proxy:city〉
〈proxy:stateProvince〉XXXXX〈⁄proxy:stateProvince〉
〈proxy:postcode〉XXXXX〈⁄proxy:postcode〉
〈proxy:countryCode〉XXXXX〈⁄proxy:countryCode〉
〈⁄proxy:internationalAddress〉
〈⁄proxyupdate:proxyDetails〉
〈⁄proxyupdate:newProxy〉
〈⁄proxyupdate:extension〉
〈⁄extension〉
At the time of application it is not envisioned that this extension will be used for the .рус TLD.
Other:
In addition to the above statuses, the CoCCA Registry provides additional lifecycle statuses over and above those defined in RFC-5731. The CoCCA Activation statuses are provided using namespaced status elements in the Domain:Create and Domain:Info responses, and are accompanied by an RFC-3735 compliant extension section. A Domain:Create response for a newly registered domain would appear as follows:
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈response〉
〈result code=ʺ1000ʺ〉
〈msg〉Command completed successfully〈⁄msg〉
〈⁄result〉
〈msgQ count=ʺ229ʺ id=ʺ21192ʺ⁄〉
〈resData〉
〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉info.confirm.test〈⁄domain:name〉
〈domain:roid〉234511-CoCCA〈⁄domain:roid〉
〈domain:status s=ʺinactiveʺ〉Delegation information has not been supplied〈⁄domain:status〉
〈activation:status xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ s=ʺpendingActivationʺ〉
This domain requires acceptance of AUP and registrant agreement by 2012-02-29 10:19
〈⁄activation:status〉
〈domain:registrant〉regis-80ESBqGtje〈⁄domain:registrant〉
〈domain:clID〉registrar〈⁄domain:clID〉
〈domain:crID〉registrar〈⁄domain:crID〉
〈domain:crDate〉2012-02-21T21:19:32.887Z〈⁄domain:crDate〉
〈domain:exDate〉2013-02-21T21:19:33.006Z〈⁄domain:exDate〉
〈domain:authInfo〉
〈domain:pw〉Hh7Wz3c9dC〈⁄domain:pw〉
〈⁄domain:authInfo〉
〈⁄domain:infData〉
〈⁄resData〉
〈extension〉
〈rgp:infData xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsdʺ⁄〉
〈activation:extension xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ〉
〈activation:url〉https:⁄⁄registry-adam⁄activate.jsp?activationCode=ITIhi1kma8SmbCsYefY18uEaJikwOXKNL0MLu0HHXkXjZUynrDZZUh6SB2h8h1D8〈⁄activation:url〉
〈activation:link〉⁄activate.jsp?activationCode=ITIhi1kma8SmbCsYefY18uEaJikwOXKNL0MLu0HHXkXjZUynrDZZUh6SB2h8h1D8〈⁄activation:link〉
〈⁄activation:extension〉
〈⁄extension〉
〈trID〉
〈clTRID〉CR-4〈⁄clTRID〉
〈svTRID〉1329859182069〈⁄svTRID〉
〈⁄trID〉
〈⁄response〉
〈⁄epp〉
25.4 EPP Access Requirements
1. IP Address white listing ( firewall and application layer )
2. Signed registry issued SSL certificates
3. Username⁄Password
Authentication requires that the IP address the connection is made from be white listed IP, that the entity connecting use a CoCCA-issued SSL certificate and that correct clientID and passwords be used. By default registrars have only GUI access to the SRS, EPP is enabled by request and only after a Registrar has been certified on CoCCAʹs OT&E platform.
25.5 CoCCA GUI Environment
In addition to providing the standard implementation of EPP that runs on Port 700, CoCCA also provides a secure web based Graphical User Interface running on Port 443 that allows Registrars to register and manage domains in their portfolio without connecting by EPP.
25.6 EPP Via the GUI
In cases where a registrar uses the SRS GUI, all domain, host and contact operations supported by the RFCʹs are executed by pamojaʹs internal EPP engine to ensure that GUI and port 700 EPP interfaces behave identically.
These methods of authentication include:
1. IP Address white listing
2. Using a one-time password (ʺOTPʺ) delivered via hardware token, soft token or SMS is issued by CoCCA.
3. The use of a Username⁄Password
25.7 Registrars
A list of registrars that have already successfully integrated and connected to CoCCAʹs SYD SRS is attached. CoCCAʹs SYD SRS is used by 200+ Registrars, many of which currently utilize the XML based EPP protocol for the purpose of providing automated services to their clients.
25.8 Resourcing and Continuous Development
CoCCAʹs software development team and systems administrators support both their own in-house SRS and that of over 23 other TLD managers who have deployed the pamoja SRS software locally on their own infrastructure. Development is on-going and active. The CoCCA SRS has been developed over the past 9 years, the bulk of the development on the EPP platform has been completed, however two full time developers are employed by CoCCA to customize, maintain and improve the software for the TLDʹs that use it.
Because of the co-operative nature of the development process CoCCA works closely with over a dozen developers and network engineers employed by users of CoCCAʹs TLD software to resolve bugs, continuously improve pamojaʹs performance and add new features.