Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Patrick Mevzek <[e-mail]>]

On Fri, Oct 2, 2020, at 15:52, James Galvin wrote:
> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
> 
> https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/

This specification will create interoperability problems as drafted.

Even if the server announces this extension, all current clients not knowing
about it will have this new behavior forced on them,
which contradicts what RFC 5730 says (see below).
So the mechanism should be that the server does not enable this behavior
until having explicit acknowledgement by the client that it is ok to do so.

Considering a default opt-in puts all currently existing EPP clients at risk.

Especially since this specification redefines what is in RFC 5730,
which says:
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.

Note the "client-provided element" and compare to this example
in the draft:
S:      <extValue>
S:        <value>
S:          <domain:trnData
S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:            <domain:name>example.com</domain:name>
S:            <domain:trStatus>pending</domain:trStatus>
S:            <domain:reID>ClientX</domain:reID>
S:            <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>
S:            <domain:acID>ClientY</domain:acID>
S:            <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>
S:            <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S:          </domain:trnData>
S:        </value>


<domain:trnData> was not client-provided, yet it is in extValue > value node.
(so an existing client sticking to RFC5730 may see this content and believe
it has made an error, and not understanding anything about the content
provided since it is not at all a content coming from it, the client).

It is also not really a "server error condition".

The value/extValue of RFC 5730 have been stretched out as of their use
in so many proprietary extensions, that I do not think it is a good
idea to have  standard even doing that.

Going deeper, it is not even clear if RFC 5730 allows really a return code of
success but still have value/extValue nodes. There may be nothing at it 
in the schema, but the text says:

Success and failure results
   MUST NOT be mixed.
[..]

Zero or more OPTIONAL <value> elements [..] that caused a server error condition.

Zero or more OPTIONAL <extValue> elements that can be used to
         provide additional error diagnostic information


Note how both nodes are specifically tied to "errors".

There may be clients out there that will consider value/extValue only for error
return codes (>=2000) and will get confused when getting back 1000 but with extValue
as this draft calls for.

Finally,
It should certainly not be "Best Current Practice".
It is neither proved to be "best" nor is it "current practice".

-- 
  Patrick Mevzek
  [e-mail]