[eppext] Implementation of draft-mayrhofer-eppext-servicemessage-00.txt

[Patrick Mevzek <[e-mail]>]

Hello Alexander,

I'm implementing your draft
draft-mayrhofer-eppext-servicemessage-00.txt in the Net::DRI EPP
client.

I have the following feedback:

- while making no change technically, I would strongly recommend to
  defined another namespace, to convey more information.
I'm specifically concerned on the "resData" part which seems to me too
generic. Maybe something called "servicemessage" like the draft name
itself?

- "their contents MUST be from the same EPP transaction."
You should defined "EPP transaction".
Why not just saying that the response element, if present must be the
response given by the server to the "request" element?

RFC5730 speaks more of command/response instead of request/response.
("An EPP client interacts with an EPP server by sending a command to
   the server and receiving a response from the server.")
For homogeneity, shouldn't you use command instead of request?

- the first example in §3.3 still has resData-1.0 while the draft
  defines resData-1.1

- I fear it to be too generic, specifically that part:
An OPTIONAL "any other" element from "any other" namespace

which is exhibited by this example:
        <data>
          <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <response>

indeed as noted, if things go forward, the <epp> node should disappear
since the response node is defined as possible direct child of data.

- in your first example you have:
<epp xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
[…]
      <message xmlns="http://tld-box.at/xmlns/resdata-1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      type="TransferApproved">

The xsi namespace declaration should be put on the epp node instead.
Also the domain namespace is not defined anywhere.

Also for this example, the only one where <message> is not the only
child of <resData> you may wish to give some advices to know if for
this specific case it is expected to have both trnData & message in
the same notification, or if it may happen/if it is allowed that they
are carried separately in 2 messages.

- I believe you should add an example with the reftrID element
Especially in the third case (type=ResponseRecovered), shouldn't there
be a reftrID element with the clTRID/svTRID from the inner message?

- for the ResponseRecovered type, should the client expect that the
  message qDate corresponds to when the connection has been
interrupted?
If not, for example if the message is asynchronously added by the
registry, shouldn't there be somewhere a timestamp telling when the
connection was broken and the messages generated?

Also, I believe there should be some considerations added for this
case: when some registrars are attempting to do operations as fast as
possible, during races (domain name grabbing, landrushes, etc…) with
this feature some registrars may decide to cut (on the TLS level) the
connection as soon as their message is sent in order not to wait for
the server reply nor parse it at that time since they know they will
get the server reply anyway later through a service message.
So going for a rare case and a failback, this case can become the
standard way of operating, which is probably not suited. The
specification should discuss that I believe, even if it is mostly
registry policy.

- I believe the 4th example shows the problem with a simple list of
  key/value:
<entry name="status">serverUpdateProhibited</entry>
<entry name="comment">testcase comment freeze (2014-12-28T13:48:22.097813Z)</entry>
<entry name="status">serverTransferProhibited</entry>
<entry name="comment">testcase comment freeze (2014-12-28T13:48:22.097813Z)</entry>

entries are linked together, each comment is probably specific
to its previous sibling.

This may be obvious for a human in this example, but makes no generic
way for a computer to derive this. So another schema should be found
if possible.
It strikes me specifically for the status element since the core EPP
already allows an optional free text attached to status values…

HTH,

-- 
Patrick Mevzek