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

[Gavin Brown <[e-mail]>]

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.

G.

On Wed, 9 Sep 2015 11:20:12 +0000, "Hollenbeck, Scott" <shollenbeck at
verisign.com> wrote:
>> -----Original Message-----
>> From: EppExt [mailto:eppext-bounces at ietf.org] On Behalf Of Hollenbeck,
>> Scott
>> Sent: Wednesday, September 09, 2015 7:02 AM
>> To: eppext at ietf.org
>> 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:
> 
> https://github.com/DK-Hostmaster/epp-service-specification
> 
> The current version of the schema can be found here:
> 
> https://github.com/DK-Hostmaster/epp-xsd-files/blob/master/dkhm-1.4.xsd
> 
> 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
https://www.centralnic.com/

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