After some iterations of reading your reply and the draft I think I start to get it :-)
The extension is to be used only in a response of an EPP info command. The whole poll thing confused me, because, how I interpret RFC 5730, an EPP poll response is the response to the epp:poll command (with the "op" attribute either "req" or "ack"), but here, poll response has a different meaning. It means any response having a msgQ element. To me, a response having a msgQ element is not a poll response, but just a response (check response, info response, poll response, create response, delete response, ...) containing a "hint" there are poll messages available. This makes me thinking: wouldn't it be useful to allow the use of the extension in case of a transform response (like domain update) or a poll response (like poll ack, which I initially had in mind when reading the draft for the first time)? I think it is :-) Best regards Pieter On 08 Jan 2018, at 14:28, Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Pieter, Thank you for your review and feedback. The extension is a command / response EPP extension of any object (e.g., domain, host, contact) that the server needs to inform the client of changes via a poll message that is an extension of the object’s info response. A poll response is a standard EPP response with the msgQ element populated. The key choice for a poll message is which concrete EPP response to use. In the case of draft-ietf-regext-change-poll, the extension of an object-specific info response is used. The change poll message could have leveraged an object extension (e.g,. change record), but that would have required finding some mechanism to replicate the state attributes of an extensible set of objects (e.g., domain, host, contact). The title of section 3.1.2 as EPP <info> Command is in line with other command / response EPP extensions. I believe the example reference to “poll <info> response” is accurate, since a poll command does result in a poll response which in this case is an extended object-specific info response. Does referring to it as “poll message <info> response” make it a little bit clearer in the examples? Thanks, — JG <image001.png> James Gould Distinguished Engineer jgo...@verisign.com<x-msg://46/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of Pieter Vandepitte <pieter.vandepi...@dnsbelgium.be<mailto:pieter.vandepi...@dnsbelgium.be>> Date: Monday, January 8, 2018 at 3:11 AM To: "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-change-poll-06.txt Just a small note... Shouldn't section 3.1.2 be renamed to EPP <poll> Command? I think the purpose of the extension is to extend poll messages, no? Moreover, the draft talks about Example poll <info> response I think that's an error. Poll info does not exist. It should be poll req Pieter On 05 Jan 2018, at 14:08, internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions WG of the IETF. Title : Change Poll Extension for the Extensible Provisioning Protocol (EPP) Authors : James Gould Kal Feher Filename : draft-ietf-regext-change-poll-06.txt Pages : 25 Date : 2018-01-05 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client sponsored objects that were not initiated by the client through EPP. These operations MAY include contractual or policy requirements 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-regext-change-poll-06 https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
