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

["Liu, Hong" <Hong.Liu@neustar.biz>]

Scott,

Thanks for taking the time to look at the draft and for being receptive to
our suggestion. Your idea of being consistent with transfer handling is well
taken. I would like to carry this discussion further along your line of
thinking.

When I wrote the draft at the beginning, I was actually thinking exactly
your way since the pending action is performed on a specific object mapping.
But after I finished the writing, I realized that I have to add <paData> to
every object mapping (i.e., domain, contact, and host) that may need this
feature. The advantage for doing so, as you explained, is that more object
specific information can be added in. The downside is that <paData> will
have to be defined in every object mapping (existing and to-be-defined).
Since my main goal is to minimize the changes to existing schemas, after
some struggle myself, I took the approach to extract the basic elements for
notification that are object independent. But this may be just my personal
preference in schema design. Both your suggestion and mine should work. I
will leave it to the WG to decide which way to go.

Just to be complete, taking your input, <paNotify> can be defined as
follows:

<complexType name="paNotify">
  <sequence>
    <element name="paTRID" type="epp:trIDType"/>
    <element name="paDate" type="dateTime"/>
  </sequence>
  <attribute name="paResult" type="boolean" use="required"/>
</complexType>

The <paTRID> will consist of the OPTIONAL clTRID and the svTRID.

I fully agree with you regarding the usage of <msg> in <msgQ>. I also
support your idea to allow more structural information to be included in
<msg> for service messaging. For example, <paNotify> (or <paData>) just says
that the pending action has failed. The <msg> element in <msgQ> may be used
to construct more specific error code and text explaining why it failed.
These error codes and accompanying texts can be defined by each registry.

Cheers, 

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Wednesday, July 31, 2002 8:50 AM
To: 'ietf-provreg@cafax.se'
Subject: RE: I-D on Uniform Treatment of Pending Action Notification in
EP P


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-