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

From: Martin Casanova <[email-masked]>
Date: Thu, 14 Jun 2018 11:22:12 +0200

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 +41 44 268 15 55, direct +41 44 268 16 25
[email-masked], 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 +41 44 268 15 55, direct +41 44 268 16 25
> [email-masked], www.switch.ch 
>  
> Working for a better digital world
>
>
>
>
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
[email-masked], www.switch.ch 
 
Working for a better digital world

---

From: "Gould, James" <[email-masked]>
Date: Thu, 14 Jun 2018 14:04:31 +0000

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

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of Martin Casanova <[email-masked]>
Date: Thursday, June 14, 2018 at 5:23 AM
To: "[email-masked]" <[email-masked]>
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:

      <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

            condition.

            (English).

Regards.
Martin

SWITCH

[email-masked]<mailto:[email-masked]>, www.switch.ch<http://www.switch.ch>

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

[email-masked]<mailto:[email-masked]>, www.switch.ch<http://www.switch.ch>

regext mailing list

[email-masked]<mailto:[email-masked]>

--

---

SWITCH

[email-masked]<mailto:[email-masked]>, www.switch.ch<http://www.switch.ch>

---

From: Martin Casanova <[email-masked]>
Date: Mon, 18 Jun 2018 10:41:36 +0200

James,

It is an nice possibility to include content in the <extValue><value>
field.

It gives the clients an effortless access to the extension content (not
having to configure anything) and at the same time is not creating a
poisoned message.

As reason I would mention that the client should configure parser and
login command with the missing schemas to have the benefits of
unmarshallable and validated data.

The only downside is that the <extValue><value> element would not
contain a client-provided element as stated by RFC-5730 but maybe that
is acceptable.

Best regard

Martin

SWITCH 

[email-masked] <mailto:[email-masked]>, www.switch.ch <http://www.switch.ch> 

On 14.06.2018 16:04, Gould, James wrote:
>
> 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. 
>
>  
>
>         <reason>Message incomplete due to missing
> "urn:ietf:params:xml:ns:domain-1.0" objURI in login services</reason>
>
>       </extValue>
>
>       <extValue>
>
>         <value>
>
>          <changePoll:changeData
>
>         <reason>Message incomplete due to missing
> "urn:ietf:params:xml:ns:changePoll-1.0" extURI in login services</reason>
>
>       </extValue>
>
>     </result>
>
> *James Gould
> *Distinguished Engineer
> Verisign.com <http://verisigninc.com/>
>
>  
>
> *From: *regext <[email-masked]> on behalf of Martin Casanova
> <[email-masked]>
> *Date: *Thursday, June 14, 2018 at 5:23 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] Poll messages with unhandled
> namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)
>
>  
>
> Hello
>
>         <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>
>         <reason lang="en">Msg incomplete due to missing extURI at
> login cmd! To fix include at :
> epp/command/login/svcs/svcExtension/extURI</reason>
>       </extValue>
>
>  
>
> MISSING client provided element in this case. The reason is again
> human readable and referring to a server error which is
>
> [email-masked] <mailto:[email-masked]>, www.switch.ch <http://www.switch.ch> 
>  
>     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.
>
>     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
>     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 
>
>     [email-masked] <mailto:[email-masked]>, www.switch.ch <http://www.switch.ch> 
>
>      
>
>     [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>, www.switch.ch <http://www.switch.ch> 
>