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