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

Thomas Corte <> Mon, 26 October 2020 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B2E23A0B2B for <>; Mon, 26 Oct 2020 09:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.144
X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a9xYHuP6yfux for <>; Mon, 26 Oct 2020 09:39:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63E933A0AB4 for <>; Mon, 26 Oct 2020 09:39:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CKgXs4CNQz4vDj for <>; Mon, 26 Oct 2020 17:39:41 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 407F270FA0 for <>; Mon, 26 Oct 2020 17:39:41 +0100 (MEZ)
References: <> <>
From: Thomas Corte <>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <>
Date: Mon, 26 Oct 2020 17:39:41 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
X-Rspamd-Server: v1117
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:, country:DE]; LOCAL_WL_IP(0.00)[]
X-Rspamd-Queue-Id: 4CKgXs4CNQz4vDj
Authentication-Results:; none
Archived-At: <>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Oct 2020 16:39:46 -0000


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,


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

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:
     Software-Entwicklung        E-Mail:

                                 Amtsgericht Dortmund, HRB 13728

                                 Dietmar Knipp, Elmar Knipp