RE: I-D on Uniform Treatment of Pending Action Notification in EP P

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Hong et al:

Having spent some more time thinking about the suggestions presented in your
I-D, I now have a better feel for what you need and why I didn't
particularly care for the suggestion to add a <paNotify> element.  It's not
the "what" that concerned me, it was the "how", and my concern was driven
largely by a desire to use existing facilities and to treat notification
actions consistently.

We're already doing something similar when transfer actions are completed,
so I spent some time thinking about one of the options described in your
proposal -- use of the <resData> element.  I also thought it might be OK to
be a bit more verbose in the notification so that there can't be any
confusion when the client tries to synchronize the notification with their
own queue of pending activity.

Given that these pending actions operate on objects, just like transfers,
I'd like to suggest that we can do the notifications in the same way that
clients are notified of completed transfer activities.  That is, the
<resData> element can contain the information to identify the object, and
the few new elements needed to make this work get defined in the object
mappings.  A polled message could thus look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <response>
    <result code="1301">
      <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count="5" id="12345">
      <qDate>2000-06-08T22:00:00.0Z</qDate>
      <msg>Pending action completed successfully.</msg>
    </msgQ>
    <resData>
      <domain:paData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name paResult="1">example.tld</domain:name>
        <domain:clTRID>ABC-12345</domain:clTRID>
        <domain:svTRID>54321-XYZ</domain:svTRID>
        <domain:paDate>2000-06-08T21:59:00.0Z</domain:paDate>
      </domain:paData>
    </resData>
    <trID>
      <clTRID>BCD-23456</clTRID>
      <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>

Note that the <msg> element in the <msgQ> tells the client what happened,
and everything the client needs to figure out which object is involved is
carried in the <domain:paData> element.  I thought it best to include both
TRIDs (with an optional clTRID) to exactly mirror the TRIDs returned in the
server's response to the original request.  The <paDate> element notes when
the action was actually completed, just as we note dates and times related
to transfers.

OK, hack away.  We might be able to get by with less info to identify the
client's transaction, but doing it this way is consistent with the transfer
notification mechanism and it provides some detail that might make client
reconciliation easier.

-Scott-