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:[email protected]]
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: regext <[email protected]> on behalf of Martin Casanova
<[email protected]>
Date: Thursday, June 14, 2018 at 5:23 AM
To: "[email protected]" <[email protected]>
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 +41 44 268 15 55, direct +41 44 268 16 25
[email protected]<mailto:[email protected]>,
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 +41 44 268 15 55, direct +41 44 268 16 25
[email protected]<mailto:[email protected]>,
www.switch.ch<http://www.switch.ch>
Working for a better digital world
_______________________________________________
regext mailing list
[email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>,
www.switch.ch<http://www.switch.ch>
Working for a better digital world
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
