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
