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