Re: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt

Gavin Brown <> Wed, 25 November 2015 15:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BAA891B2DF5 for <>; Wed, 25 Nov 2015 07:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 92AqfVkitWUi for <>; Wed, 25 Nov 2015 07:11:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D55671B2DE6 for <>; Wed, 25 Nov 2015 07:11:43 -0800 (PST)
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 CA208E1385; Wed, 25 Nov 2015 15:11:41 +0000 (UTC)
To: Rik Ribbers <>, "Gould, James" <>
References: <> <> <> <> <> <>
From: Gavin Brown <>
X-Enigmail-Draft-Status: N1110
Organization: CentralNic
Message-ID: <>
Date: Wed, 25 Nov 2015 15:11:41 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="AMk7pQIetUfnIxvKC9L853BrJ2Rp2GmjI"
Archived-At: <>
Cc: "" <>
Subject: Re: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
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: Wed, 25 Nov 2015 15:11:49 -0000

Hi Rik,

> From a personal perspective I agree with Gavin: Yuck!  However the
> question is what the goal of this draft is:
> - Document the existing implementation for registration in EPP IANA
> registry? Then you can do whatever you like, get an expert review and
> leave the document as you wish
> - Ask for WG-adoption and go for Standards Track; Ai, you might end up
> in the same situation as the keyrelay draft where there was a status quo
> on how to continue with the XML structure. In the end there were four
> people expressing their opinion on this matter and I decided to follow
> that advice, beside my own personal preference.
> Can you tell us what your plans are for this draft? 

There are currently no existing implementations, and I am not especially
interested in going for WG adoption. I wrote the extension to address a
relatively common support request we get from clients (to reverse an
erroneous renewal), and submitted it to the list for feedback.

We will probably implement the extension in our server at some point
once the specification has stabilised following feedback.

> One other question: How does the server hello message look like with
> respect to this extension? 

The server would advertise the namespace of the extension in an <extURI>
element in the <svcExtension> section. It would not appear in an
<objURI> element.


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,