Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

["Gould, James" <[e-mail]>]

Martin,

This approach looks good to me.  It has the advantage of providing the unhandled information in an element that is meant for machine processing instead of using the <msgQ><msg> element that’s meant is meant to be human readable.  The other advantage is that the contents of the <value> element is not processed by the XML parser (e.g., processContents=”skip”), meaning it would not cause an XML parser error.

This approach could include the entire unhandled extension block without causing client-side parsing or unmarshalling issues.  Below is an example of a change poll message where the client does not support either the domain or changePoll namespaces.  This is unlikely, but it demonstrates how it would work for an object and a command / response extension.  As Patrick has pointed out, a client could process the contents of the <extValue><value> data offline.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1301">
      <msg>Command completed successfully; ack to dequeue</msg>
      <extValue>
        <value>
         <domain:infData
          xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
           <domain:name>domain.example</domain:name>
           <domain:roid>EXAMPLE1-REP</domain:roid>
           <domain:status s="ok"/>
           <domain:registrant>jd1234</domain:registrant>
           <domain:contact type="admin">sh8013</domain:contact>
           <domain:contact type="tech">sh8013</domain:contact>
           <domain:clID>ClientX</domain:clID>
           <domain:crID>ClientY</domain:crID>
           <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
           <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
         </domain:infData>
        </value>
        <reason>Message incomplete due to missing "urn:ietf:params:xml:ns:domain-1.0" objURI in login services</reason>
      </extValue>
      <extValue>
        <value>
         <changePoll:changeData
           xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
           state="before">
           <changePoll:operation>update</changePoll:operation>
           <changePoll:date>2013-10-22T14:25:57.0Z</changePoll:date>
           <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
           <changePoll:who>URS Admin</changePoll:who>
           <changePoll:caseId type="urs">urs123</changePoll:caseId>
           <changePoll:reason>URS Lock</changePoll:reason>
         </changePoll:changeData>
        </value>
        <reason>Message incomplete due to missing "urn:ietf:params:xml:ns:changePoll-1.0" extURI in login services</reason>
      </extValue>
    </result>
    <msgQ count="1" id="201">
      <qDate>2018-06-14T13:46:33.453Z</qDate>
      <msg>Registry initiated update of domain.</msg>
    </msgQ>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>



—

JG

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

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

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of Martin Casanova <[e-mail]>
Date: Thursday, June 14, 2018 at 5:23 AM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


Hello

While implementing, another idea came to mind, which I want to put to discussion here:

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1301">
      <msg lang="en">Command completed successfully; ack to dequeue</msg>

      <extValue>
        <value>
          <extURI>urn:ietf:params:xml:ns:changePoll-1.0</extURI>
        </value>
        <reason lang="en">Msg incomplete due to missing extURI at login cmd! To fix include at epp/command/login/svcs/svcExtension/extURI</reason>
      </extValue>
      <extValue>
        <value>
          <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
        </value>
        <reason lang="en">Msg incomplete due to missing extURI at login cmd! To fix include at : epp/command/login/svcs/svcExtension/extURI</reason>
      </extValue>



It is validating against the schemas. The value is referring to a MISSING client provided element in this case. The reason is again human readable and referring to a server error which is

not quite the case here but still is indicating a condition that is not ideal..

from RFC-5730

      o  Zero or more OPTIONAL <extValue> elements that can be used to

         provide additional error diagnostic information, including:



         *  A <value> element that identifies a client-provided element

            (including XML tag and value) that caused a server error

            condition.



         *  A <reason> element containing a human-readable message that

            describes the reason for the error.  The language of the

            response is identified via an OPTIONAL "lang" attribute.  If

            not specified, the default attribute value MUST be "en"

            (English).

Regards.
Martin

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone [phone], direct [phone]

[e-mail]<mailto:[e-mail]>, www.switch.ch<http://www.switch.ch>



Working for a better digital world


On 24.05.2018 10:31, Martin Casanova wrote:
Hello

Sorry I have not been checking the mails of this mailing list for a while...

In my opinion as registries we have a special role and should stick to the RFC’s as close as possible for a strong EPP standard everybody can rely on. Therefore I find it valuable to discuss the RFC’s and get everybody's input.

I think that there is an issue with potentially breaking some clients, although for some clients it may not be a problem as was pointed out.

Also I don't see a big problem for clients to not receive full information in a message of a freshly implemented Change Poll Extension response since they didn't get it at all before the extension was implemented.

The suggestion of James Gould to give a hint about the missing extension part in the <msg> field of the poll response may be a way to go. This filed is intended for humans and thats what we want to do: Inform a human to prepare his client and configure the Login command accordingly if he wants to receive the information of the extension.

However the ChangePoll Extension is not the only one we need to inform about. How should we inform about a changes in DNSSec Data? We also would have to indicate that the DNSSec extension should be configured in order to include something like

<secDNS:infData xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"><secDNS:dsData><secDNS:keyTag>2371</secDNS:keyTag>
<secDNS:alg>13</secDNS:alg>
<secDNS:digestType>2</secDNS:digestType>
<secDNS:digest>F991B7FDE40A2C4CD7BEFBBE9A1073D1FC3E34EC6DC31E2931320D1CD8392390</secDNS:digest>
</secDNS:dsData>
</secDNS:infData>

in the extension part..

We are planing to do something like this as we are going to implement the RFC-8078 / RFC-7344 CDS feature. Of course there will also be an out of band communication with our registrars about this.

Martin

--

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone [phone], direct [phone]

[e-mail]<mailto:[e-mail]>, www.switch.ch<http://www.switch.ch>



Working for a better digital world








_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext



--

---

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone [phone], direct [phone]

[e-mail]<mailto:[e-mail]>, www.switch.ch<http://www.switch.ch>



Working for a better digital world