[gtld-tech] [eppext] Publishing of the Change Poll EPP Extension IETF Draft
Patrick Mevzek
pm at dotandco.com
Sat Jun 20 16:39:42 UTC 2015
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
More information about the gtld-tech
mailing list