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

[Thomas Corte <[e-mail]>]

Hello,

On 10/26/20 15:01, James Galvin wrote:

> Current consensus is to seek publication.  However, we are a relatively
> small group and we would like all comments considered by multiple
> people.  Would others please indicate their point of view in the active
> thread between James and Patrick?

As both an EPP client (and server) developer, I think that both James and
Patrick make valid points, though I tend to agree more with Patrick's
point of view.

I'd fully agree with Patrick that the draft is somewhat abusing the
<extValue> mechanism, as it was clearly designed in RFC 5730 to
communicate "error diagnostic information", with the <value> containing a
"client-provided element (including XML tag and value)". In fact, from
this wording one could even derive that it's *not* proper server behavior
at all to include anything in the <value> element that didn't also appear
in the client's EPP command, which this draft is asking servers to do.

One the other hand, I'd agree that it's probably the only place where
non-parsed XML can be included in responses, which is the only way to
keep the server's responses from violating the contract by including
namespaces not listed as supported by the client.

In our own current client implementation, we're only consulting the
<extValue> content if the result code indicates an error. I'd assume that
many clients do it this way, which is why I doubt that the inclusions
defined by the draft will do any real harm or even cause confusion.

However, at best this means that clients will completely ignore the
unhandled data, i.e. simply ignore the (apparently empty) poll messages
and acknowledge them without processing. While this is nice in terms of
not blocking any other (understood) poll messages, it also poses the
problem that important poll messages may go unnoticed, potentially for
extended periods of time, which may (depending on the nature of the
messages) be a greater operational risk than blocking further polling.
If an unhandled namespace simply showed up (violating the contract), at
least my validating EPP client would croak, and I'd be forced to take
action (ideally by adding support for the namespace and resume polling then).

I know it's late in the game to come up with suggestions, but anyhow:
a compromise to solve this, at least for the polling issue, *could* be to
use <extValue> as described, but to return an *error response* (with a
special result code) instead of a success response to the <poll> command.
This could (somewhat) justify the use of <extValue>, while still alerting
the EPP client about something that it might be missing. Of course, this
would still mean that polling of further messages would come to a halt
until the issue is fixed on the client side.

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    [phone]
     Thomas Corte                Fax:    [phone]
     Stellvertretender Leiter    SIP:    [e-mail]
     Software-Entwicklung        E-Mail: [e-mail]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp