Re: [eppext] EPP Extension Registration Requests from DK-Hostmaster

Gavin Brown <> Thu, 17 September 2015 13:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7A2E71B2FFE for <>; Thu, 17 Sep 2015 06:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HynscWXL4i-L for <>; Thu, 17 Sep 2015 06:58:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B18B41B2FCA for <>; Thu, 17 Sep 2015 06:57:59 -0700 (PDT)
Received: from Gavins-MacBook-Pro.local (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D8FC2E0F87 for <>; Thu, 17 Sep 2015 13:57:57 +0000 (UTC)
To: "" <>
From: Gavin Brown <>
X-Enigmail-Draft-Status: N1110
Organization: CentralNic
Message-ID: <>
Date: Thu, 17 Sep 2015 14:57:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o6Lh6dOLxFxs2baL44uVPEgnEeiIHmCAi"
Archived-At: <>
Subject: Re: [eppext] EPP Extension Registration Requests from DK-Hostmaster
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Sep 2015 13:58:01 -0000

As a designated expert I have reviewed the registration requests and the
specifications submitted. I think they meet the criteria for
registration. Specifically, they meet the requirements of RFC 3735,
including the Security Considerations; and there are no privacy
consequences that I can determine.

However, I do have a couple of points that I'd like to suggest be
considered by the authors:

* Use an element naming convention that's consistent with the main EPP
standards. The extension mixes camelCased element names like
<domainAdvisory> with underscore_separated names like <domain_confirmed>.

* Consider using a single element under <extension> with the data
elements as its children - this would follow the convention used by
other extensions.


On Wed, 9 Sep 2015 11:20:12 +0000, "Hollenbeck, Scott" <shollenbeck at> wrote:
>> -----Original Message-----
>> From: EppExt [mailto:eppext-bounces at] On Behalf Of Hollenbeck,
>> Scott
>> Sent: Wednesday, September 09, 2015 7:02 AM
>> To: eppext at
>> Subject: [eppext] EPP Extension Registration Requests from DK-
>> Hostmaster
>> Yesterday I received 10 requests from IANA to review EPP extensions
>> submitted by DK-Hostmaster. I'll forward each of them to this list
>> momentarily. I've reviewed all of them and I'm going to suggest that
>> they be considered as one request since each describes an element that
>> is part of the same schema and the same specification.
> More detail:
> The specification for each of the registration requests can be found here:
> The current version of the schema can be found here:
> Each of the registration requests refers to an element that is defined in this schema:
> <element name="userType" type="dkhm:userType" /> 
> <element name="EAN" type="dkhm:EAN" /> 
> <element name="CVR" type="dkhm:CVR" /> 
> <element name="pnumber" type="dkhm:pnumber" /> 
> <element name="contact" type="dkhm:contact" /> 
> <element name="trackingNo" type="dkhm:trackingNo" /> 
> <element name="domainAdvisory" type="dkhm:domainAdvisory" /> 
> <element name="orderconfirmationToken" type="dkhm:orderconfirmationToken" /> 
> <element name="domain_confirmed" type="dkhm:domain_confirmed" /> 
> <element name="contact_validated" type="dkhm:contact_validated" /> 
> <element name="registrant_validated" type="dkhm:registrant_validated" />
> Each of these elements ultimately refers to an XML schema simpleType that includes a restriction for a base of type token. Based on my reading of the specification I believe the last three elements could be more efficiently represented as booleans, but what's there certainly works.
> As I said in my first message in this thread I'd like to recommend to IANA that they process these requests as a single addition to the registry since each request describes an XML element that is part of the same schema and namespace. Could the other DEs please share your thoughts?
> Scott

Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,