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

[Patrick Mevzek <[e-mail]>]

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
  [e-mail]