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

[Gould, James]

Patrick,

Thank you for your review and feedback.  My feedback is included below.


—


JG


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D at vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould at Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Jun 20, 2015, at 12:39 PM, Patrick Mevzek <pm at dotandco.com<mailto:pm at dotandco.com>> wrote:

Gould, James <JGould at verisign.com<mailto: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


Thank you

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

I see the purpose and makeup of the Change Poll extension and the EPP Service Message Extension as being fundamentally different.  The Change Poll is setup as an extension to any object mapping to provide the reason for a server-side change to an object that includes the object attributes (before the transaction, after the transaction, or both as separate messages).  The EPP Service Message Extension is more generic to cover a broader range of messages in the form of an object response.  Both do leverage the poll queue, but one is a targeted extension for server-side changes to objects (Change Poll) while the other provides a general messaging mechanism using key/value tuples and a freeform description.  It would be an interesting discussion at the EPPEXT WG meeting on whether there is sufficient overlap to warrant a merge of some sort.  I personally believe that they meet different purposes, so I would not be in favor of attempting to merge them.



- among other things, since you already have a svTRID, an (optional)
 clTRID would be probably useful


The Change Poll extension is associated with server-side changes that don’t include the client and the option for a client transaction identifier.

- 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).


I fixed the example to set state=“before” that will be included in an updated draft (03).  You are correct that the extension has the exact same values except for the value of the state attribute, which is intended.  The before state returns the state of the object prior to the server-side transaction and the after state returns the state of the object after the server-side transaction.  Trying to merge the before and after image of the object in a single poll message was too complex, so if both are supported they will be posted as separate poll messages.  The client can match up the poll messages using the <changePoll:svTRID> value to have access to both the before state and the after state of the transaction.  The “before” and “after” state examples are associated with a URS Lock, where the domain originally had the “ok” status (“before” state), and then has the “serverUpdateProhibited”, “serverDeleteProhibited”, and “serverTransferProhibited” statuses in the “after” state.  The <domain:upDate> was also added in the “after” state message.  So although the extension values have the same attribute values except for the state attribute, the contents of the object attributes are different to reflect the before or after image of the object.

HTH,

--
Patrick Mevzek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20150707/306ed9c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
Type: image/png
Size: 4109 bytes
Desc: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20150707/306ed9c2/BF09FAA4-32D8-46E0-BED0-CD72F43BD6E081-0001.png>