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

[Martin Casanova <[e-mail]>]

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 

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 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. 
>
>  
>
> <?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

-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone [phone], direct [phone]
[e-mail], www.switch.ch 
 
Working for a better digital world