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

Rik Ribbers <> Wed, 18 November 2015 08:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 04FDF1B2A41 for <>; Wed, 18 Nov 2015 00:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.49
X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSO6ztQQh6gW for <>; Wed, 18 Nov 2015 00:49:38 -0800 (PST)
Received: from ( [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E42B1B2A39 for <>; Wed, 18 Nov 2015 00:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt;; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=QbCM9w0axa20htzaroF4Pnt5naBYc6SBMxRwMCdJQ9o=; b=lIixs2b5ZiLdfTHxJMbXbXjS3EuDkIAoiJjP5n65cJoXYkoNPbJ4NMY5/5X8g7Q8x3QXVONJAlg/D1rmdwX/OSgrUXpBzKnSasU/awvODaPwcePhXd20pCja3HjgU72bk1vrjDgR7JTO1JE4R9xXFxh1jW6ihbPguwS+AWVMQVuyGD+0C4NRBUqeqz5g8/6hcct57Q7p93uwPpOZLbNzAJk9h/dgNrk1LPmggO31ZBjW452yRkNmu2d8q0/NVaMecOa496At81H50WWUzuvjFoQu+lKrl3CUbkDZdy4lj9UcOWUdQRS3rX4QRC+HisNchzB2E0akxAAwqW3G9pMbtQ==
Received: from ka-mbx03.SIDN.local ([]) by with ESMTP id tAI8nYgR021439-tAI8nYgT021439 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Wed, 18 Nov 2015 09:49:34 +0100
Received: from ka-mbx02.SIDN.local ( by ka-mbx03.SIDN.local ( with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 18 Nov 2015 09:49:33 +0100
Received: from ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549]) by ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549%13]) with mapi id 15.00.1076.000; Wed, 18 Nov 2015 09:49:34 +0100
From: Rik Ribbers <>
To: "Gould, James" <>, Gavin Brown <>
Thread-Topic: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
Thread-Index: AQHRHhuO7Zkv6bXIZ0irq1Z8zwgWP56geI4AgAAZRoCAAN1IgA==
Date: Wed, 18 Nov 2015 08:49:34 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3096.5)
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_B5ABA15E-62AB-48C4-A66A-575A3E83391C"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
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, 18 Nov 2015 08:49:41 -0000

> On 17 Nov 2015, at 20:37, Gould, James <> wrote:
>>> My recommendation is to handle it in a similar fashion with
>>> draft-ietf-eppext-keyrelay in using strictly an object extension, where
>>> reverse:create is used to submit the reversal request
>> <imho>Yuck!</imho>
> I’m not sure why use of a create to submit a reversal request is not more natural then creating a protocol extension.  The advantage of the create is that you are creating a reversal request object that can be processed synchronously or asynchronously with all of the features of a object extension (transaction identifiers and command-response extensions).  The pending action poll message can asynchronously return the pending action result or you can provide support for an info command and response for retrieving the status of the reversal request on demand.  

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? 

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