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

Patrick Mevzek <> Wed, 21 October 2020 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DA153A0976 for <>; Wed, 21 Oct 2020 14:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=KG2Aon8l; dkim=pass (2048-bit key) header.b=gkvxBzCH
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZREmITe_U_la for <>; Wed, 21 Oct 2020 14:26:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F7963A096C for <>; Wed, 21 Oct 2020 14:26:30 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 310B95C05F7 for <>; Wed, 21 Oct 2020 17:26:29 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Wed, 21 Oct 2020 17:26:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=JkL+4gw+XRGrzobj0+E9H+uop5yYKuw XFzU5zzF0DJM=; b=KG2Aon8lozEe3Ha3jxav0PdjtAG1cQvIIiRm/vNnUXv8evL /bPoqkibBGiU3WpRpqorXVrR9zGPdhBoDIb9wUFrhSklOYtfSXYNu5Eq8dETDuGP MJo0pnthjaJYQzc3RhMWJOC9C6eluDRhSwM8K2PDrFmP4I5BlqTIanWFG0ZbZ7hs NWYfRYWR80MYTcGvmNYIOY2166re01xxGlbt0LA57ozIbcRe338Jno8P45iIQuPs ejK41MO4UIhzHuBX3DzYwBCLZyn6yWNqVplqBgRTp5jIJYBe2/MBy055nXefRJYq DTsQpcosBGIXtShqDgAv3HzdIzP2hSFYCkt/vog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JkL+4g w+XRGrzobj0+E9H+uop5yYKuwXFzU5zzF0DJM=; b=gkvxBzCHrFt4t1PYPbyawR Z2VPv39yXaBTDaiYB2+XCTcleWrfAURupR6bSP9C4uN0sD37ZpIuThQFhLM2vZXZ 9P3YsWEGJ1SoIhuXjlUUyC+6nHHpAPYkW9HEJin+hqt4XFQqNA2h6zYWfSVhcxau xL7Xq6KuoqtNLmcXVhZhzMtJSepfCJ0HPtNeVai9FEYNslxbfQQqXt3K+KAQ1vsO aJO/Q/EodlOcdVtTVDNPXq+i6VmwD87EQHOWSEHQXuFwh5BdkkdDtDWjUF5oICje n7IQYlFKJz/KkaY+Iv+dCRU3v2px7x2daK/f8DH3sKvXZ53liOrOinA/VvY5C8Dg ==
X-ME-Sender: <xms:hKeQX5JL4YBacZ6k088SWirhGlVU5wgG3uZCVBY1Zao5pw6kLsnx1bQcZmg> <xme:hKeQX1J1YNj6jwWxUQTlCVfheU6RysTYf-fsE2sASYow9wxNmShQUpZqutgea9L1n XCo8ZDyrrXzIfQYNA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeehgdduiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedugfffieehffejkeduhfdvke evffdufeeuieekheeuffejfeejieetieehudfgkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:hKeQXxv4cQXRuZkSKJV42S7vaGGVjJKz8OX208m7lrrIxV5Wb5s8ag> <xmx:hKeQX6ZRNh5Q2yNmp373y5lKttnmd9iUQglggGrSXwG33LJwJ6sEqw> <xmx:hKeQXwasxx-ic05W2aKufDeigcO5UUEVdwbKUwREOuEeVpNawt6cnQ> <xmx:haeQX5nWZLEtlEvaYqL-RtSaVi7tPyfWHjuwNWhQeZeUPq2F4Fmycg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 648626680078; Wed, 21 Oct 2020 17:26:27 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-502-gfef6c88-fm-20201019.001-gfef6c888
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 21 Oct 2020 16:26:07 -0500
From: Patrick Mevzek <>
Content-Type: text/plain
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: Wed, 21 Oct 2020 21:26:32 -0000

On Wed, Oct 21, 2020, at 15:56, Gould, James wrote:
> JG - I'm not clear of the risk of returning information in the 
> <extValue> element to clients.  There won't be a schema validation 
> error like the case of returning a non-supported extension to a 
> validating client.  There won't be a marshaling error for the client, 
> since unmarshaling the <extValue> in the <result> element should 
> already be supported.  The most likely issue is that the client will 
> ignore the information, which does not pose an operational risk.

That is purely a judgment call.
The specifications say: this part is filled with content from client.
This is clear and non-ambiguous.

Hence a client parsing it is expecting to see there... data it already sent
since it is the client, per the specification. You can say it is a bad client
if it starts to misbehave because it sees other things there, but you can't 
also know or take into account all servers and clients out there, and their

> I've 
> implemented draft-ietf-regext-unhandled-namespaces on the server side 
> and in a validating client within the Verisign EPP SDK, and I don't see 
> any potential risk for the client. 

Again, you take as granted that everyone will update their clients at the moment
your specification becomes RFC (That won't happen as it doesn't happen for any RFC, no matter how good it is) or the fact that all clients work the
same as yours.

And for all clients not updated or doing things differently than yours, this draft may break them as soon as the EPP servers they connect to implement it.

> Martin implemented 
> draft-ietf-regext-unhandled-namespaces in a Production server and 
> hasn't come across any reported client-side issues.  A server can 
> choose to implement draft-ietf-regext-unhandled-namespaces and when 
> doing so should notify the clients ahead of time, so this is not 
> something that would be thrown onto clients without notice. 

Yes, in theory.
In practice, deployments do not happen like that, unfortunately.
I am just trying to give some data about past experiences.

>  A draft can be defined to 
> cover the usage of an existing element in the RFC for a specific 
> feature,

No, you are explicitly redefining usage as described in RFC 5730.

It looks minor in your eyes, not in mine, so our vision will remain separate.

> JG - Yes for an error it makes sense to include the "client-provided 
> element".  The case defined in draft-ietf-regext-unhandled-namespaces 
> is not an error and the use of the <extValue> element for this use case 
> is defined in draft-ietf-regext-unhandled-namespaces. 

... and not defined in RFC 5730 which is the problem for every client out there
that won't or can't or not yet upgrade to your specification.

> The description 
> of the element does not prohibit the use of the element to address a 
> specific well-defined problem solved by 
> draft-ietf-regext-unhandled-namespaces.  

Yes, it does prohibit because it says "client provided" and you are putting
things in it that are not "client provided".
Your specification redefines core parts of the current EPP specification.

And to be honest, one moment you say "RFC 5730 couldn't predict the need
to handle undefined namespaces hence does not speak about them" (obviously)
so that you can justify overriding one of its specification
and here you say "RFC 5730 does not prohibit what this draft is trying to do
(as if RFC 5730 could have known that in advance)". I believe this is one
argument and its opposite so difficult to have both at the same time, but 
maybe I am just getting at my limits in English, which is very possible.
> JG - We can agree to disagree on the value and risks associated with 
> draft-ietf-regext-unhandled-namespaces.  The Document Shepherd can 
> include a reference to your disagreement in his writeup, but I don't 
> believe there is consensus to make a change.

I am not saying otherwise and I sure don't expect a change because
it is already presented as the best or unique solution on the problem, it 
has been discussed extensively and to me this specific solution creates its
own set of problems, hence my disagreement.

If I am the only one seeing that the text redefines RFC 5730 in 
different and incompatible ways, and the only one believing that not all clients will suddenly
be upgraded to use this specification (as if all EPP servers out there will
be updated...), then so be it, it does not really matter.

Again, I am not trying to convince anyone, I know it won't happen,
I just phrased my justifications on the problems I see.

  Patrick Mevzek