Re: [provreg] [eppext] Publishing of the Change Poll EPP Extension IETF Draft
Patrick Mevzek <pm@dotandco.com> Sat, 20 June 2015 16:42 UTC
Return-Path: <patrick@shaktot.patoche.org>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894271A890E; Sat, 20 Jun 2015 09:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.788
X-Spam-Level:
X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhVEvmOBaSdJ; Sat, 20 Jun 2015 09:42:04 -0700 (PDT)
Received: from shaktot.patoche.org (shaktot.patoche.org [212.85.152.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756FD1A890A; Sat, 20 Jun 2015 09:42:04 -0700 (PDT)
Received: from shaktot.patoche.org (localhost.localdomain [127.0.0.1]) by shaktot.patoche.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t5KGdj5k028979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Jun 2015 18:39:45 +0200
Received: (from patrick@localhost) by shaktot.patoche.org (8.14.3/8.14.3/Submit) id t5KGdjdQ028978; Sat, 20 Jun 2015 18:39:45 +0200
Date: Sat, 20 Jun 2015 18:39:42 +0200
From: Patrick Mevzek <pm@dotandco.com>
To: "Gould, James" <JGould@verisign.com>
Message-ID: <20150620163942.GA30668@home.patoche.org>
References: <211D0420-18A3-43D7-9A3D-553B34C6DF43@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <211D0420-18A3-43D7-9A3D-553B34C6DF43@verisign.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: shaktot_dot_patoche_dot_org on 212.85.152.86
Archived-At: <http://mailarchive.ietf.org/arch/msg/provreg/yxT_YefEY4AYT3Mg-pgpb3euDdU>
X-Mailman-Approved-At: Sat, 20 Jun 2015 10:53:04 -0700
Cc: "gtld-tech@icann.org" <gtld-tech@icann.org>, "eppext@ietf.org" <eppext@ietf.org>, EPP Provreg <provreg@ietf.org>
Subject: Re: [provreg] [eppext] Publishing of the Change Poll EPP Extension IETF Draft
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jun 2015 16:42:06 -0000
Gould, James <JGould@verisign.com> 2015-01-20 14:50 > The first draft of the Change Poll EPP Extension ( > http://tools.ietf.org/html/draft-gould-change-poll-00 ) has been > submitted to the IETF. I co-authored this draft with Trung Tran > from Neustar to provide a mechanism within EPP to notify clients of > any server-side change, including but not limited to regular batch > processes, customer support actions, Uniform Domain-Name > Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) > actions, court directed actions, and bulk updates based on customer > requests. Since the client is not directly involved or > knowledgable of these operations, the extension is used along with > an EPP object mapping to provide the resulting state of the > post-operation object, and optionally a pre-operation object, with > the operation meta-data of what, when, who, and why. We would like > this draft to be included in a re-charting of the EPPEXT Working > Group. > > Please review the draft and provide any feedback. I've implemented version -02 in my toolkit Net::DRI Few minor comments: - I think it would make sense to work with Alexander Mayrhofer and his servicemessage extension, as they seem to have similar targets; (and semantically, I prefer the term "service message" or some variation of it - since for example, messages could be delivered by other means, such as email, so they are not necessarily 100% tied to the EPP poll operation) I do believe that the needs you describe above have to be covered by some EPP extension, hence I would welcome one document going forward through EPPEXT up to becoming a standard - among other things, since you already have a svTRID, an (optional) clTRID would be probably useful - I'm not 100% sure to understand the state attribute, however you write: The "state" attribute describes the state of the response data or <resData> block returned in the poll response. In the first example you write: The "before" state is reflected in the <resData> block: however the XML snippet has: S: <changePoll:changeData S: xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0" S: state="after"> Without this change, the first 2 examples are exactly the same (for the extension part). HTH, -- Patrick Mevzek
- [provreg] Publishing of the Change Poll EPP Exten… Gould, James
- Re: [provreg] [eppext] Publishing of the Change P… Patrick Mevzek
- Re: [provreg] [eppext] Publishing of the Change P… Gould, James