[gtld-tech] [eppext] Publishing of the Change Poll EPP Extension IETF Draft

[Patrick Mevzek]

Gould, James <JGould at 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