Patrick, In this case the server is communicating an error condition, but the condition does not result in an error code being returned. A poll message really cannot fail, otherwise you get into the poison message scenario. Even if we disagreed that this is an error condition, the RFC 5730 description does not use a normative SHOULD or MUST so it can be used in a 1301 response . The <extValue> element can contain the entire extension XML along with a reason for each unhandled extension for later processing. By inclusion of the unhandled XML in the <extValue> element, the client can get the entire poll message for acking, and there is no issue with returning extensions that may cause client-side XML parsing errors or marshaling errors. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/16/18, 12:11 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Thu, Jun 14, 2018, at 11:22, Martin Casanova wrote: > 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> First on a technical level, replying to registrar basically "fix your client", is not really something nice, nor what registries should be doing. Notifications are external to registrars, they can appear without any action triggered by them so basically you are filling their "inbox" with some external messages they may or may not care about, and then you are taxing them of being bad because they can not read all messages, and maybe they would not like to. Some registrars may wish, for their own reasons, not to support some extensions and then at the same time you can not have one message in their queue that blocks all others after. But more important, on a technical level, I believe the spirit of RFC5730 is that value/extValue element appears for *error messages*, that is all having code 2000 or more. Hence they would not fit for a 1301 return code. Also note: A <value> element that identifies a client-provided element (including XML tag and value) that caused a server error condition. => a client-provided element... the message you describe is in the response of a poll command by a client, and this poll command has none of that data you put in the <value> element of the server reply. So while I see the underlying idea, I think you are bending RFC5730 quite a lot to achieve it. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
