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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49EA63A121D for <>; Wed, 21 Oct 2020 09:21:49 -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=AIE0xKlA; dkim=pass (2048-bit key) header.b=CQcfcnET
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qmORhfEbRN5X for <>; Wed, 21 Oct 2020 09:21:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3EB73A1048 for <>; Wed, 21 Oct 2020 09:21:47 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6211B5C01F6 for <>; Wed, 21 Oct 2020 12:21:46 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Wed, 21 Oct 2020 12:21:46 -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=O5fp2LZ51BKbtaVM+7Jg8CYsYgq+yT2 c0Qq95a39zb0=; b=AIE0xKlAL0+7/YVzgtpEJVtFxg978n8cDDil21kpRLHh1b1 m+ptouU1DwuywW5oJXQDgLFT/LVbvx6uLBTUm2fJmyrtMJfv7bZRFg3NDja/Eexq e86YqpdZ4VhbZnzAJl3USP1a/b4cnRrgAs7bGzxAA5pF7KfY+Tr6QZcd1b5SWZfC 4XbBDp3FSqoRvXI2c374s8Vfw2x3wWfe6fjhzlwpB+b06x5W4ajDVvpCr7B83RtZ iGwFyR+/R9a45A+GfwzuSNhvpa7TPVSV4BFWlVX11R72Cuz7uqv6fT8xm+Vsm8KO z35gQpjXoqMrhtOcV1y2h967Y6qTH5UXCfr9ECQ==
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=O5fp2L Z51BKbtaVM+7Jg8CYsYgq+yT2c0Qq95a39zb0=; b=CQcfcnET5oDXwRoSLNJXHK 3nEhabmxFBnzlLE6u6i81tGW3f48CgK1nggGGfISWCU2QCOEA6eFPq5xZyfpAcK4 lwFqQURViSIIwhTvppWBoOkcqr9MgQ0dAfD60/9ecvyuIaKqXju30Uu86D8yCmfP Q3aJmZV3Anwohtv7rNKwVPbPUbP44a1lMdOtJRj2jN8jCkunQ9Iqi/NMC8t6y2Gn 2QDfO53s4oCrYUfHr8Iw9V3NzKmMCZCA2qluyDc2CLJq+1OTo/Ny7BOvUlNIG3O1 6tueduo5eYKcYOKm+7f10EsK2a7uPSZRbf33ldKppvoCOtzWtlT4NwPwsgdr9Aig ==
X-ME-Sender: <xms:GmCQX4Hjnzl1tbadcPeA6ZkbtyLP_HD---zBTL1USSuH-fSYavhG4JiQ-MU> <xme:GmCQXxXgWxAR9CTfnXIRHFf_rgsOIVlFx8rDVTqY0Pv9DljsUENgQVd-39p_09ai9 sC5ofoM3P_9yR5mAg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeehgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedugfffieehffejkeduhfdvke evffdufeeuieekheeuffejfeejieetieehudfgkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:GmCQXyKfLUP0F8bB8Csky5Ky7eBL26HVGdMAaj_12mmwvCYVL_nzRw> <xmx:GmCQX6G5oAv67WpMRZ-mlxX2C_2XSa-WSWUD4apN_EbCfeb4nRljhg> <xmx:GmCQX-Vz5VSllAP5z8_Y3nsTlE1X85EBv8BKaW5NhoC9uQ1WfE-M-g> <xmx:GmCQX2jd3kgFiVMOxO8cmu8iOQ2Scdqtua0iuaj9sQX4WECKpVmlGw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C8E04668007A; Wed, 21 Oct 2020 12:21:45 -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 11:21:19 -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 16:21:49 -0000


On Mon, Oct 19, 2020, at 08:31, Gould, James wrote:
>     Considering a default opt-in puts all currently existing EPP 
> clients at risk.
> JG - draft-ietf-regext-unhandled-namespaces addresses an 
> interoperability issue with the server returning extensions that the 
> client specified is not supported.  The <extValue> element is already a 
> feature supported by RFC 5730, so this is not something "forced on 
> them".  

You are misreading me or misquoting me.
What your draft forces on is the use of extValue
as NOT described by RFC 5730 hence putting all current clients at risk,
because you "silently" change some core expectations of RFCs 5730+.

I know the problem you are trying to address (I even think I was one of the people
raising it in the first place but note that in 20 years or more that EPP exists, it obviously 
did not move people so much even if it is a real problem),
I am just trying to explain that this draft
creates an interoperability problem by just changing the semantics of RFC 5730
without letting clients decide if they want it or not, they are forced by the server,
hence this default opt-in migration of the current park of EPP clients will
create problems.

> This is not a new feature from a protocol 
> perspective that will cause an interoperability issue.  

It is, because extValue is defined as containing *client* data that created an error,
and you are stuffing it with *server* data.

Plus the return code of 1000 + extValue case that I tried to explain, which doesn't seem to me
really covered by existing RFCs, so you are just redefining things, hoping that
all clients immediately will just implement your draft and hence everything is fine
but unfortunately that is not what is going to happen...

Maybe all of this is fine, redesigning EPP from scratch today, I could agree
with all this. But I am just pointing out that specifications already exist
and are NOT aligned with the way you try to use them in this draft. This is the
interoperability problem, not the features themselves, the fact that you add
them on top of things where they do not fit 100%.

> There is no normative language in RFC 5730 that would 
> prohibit the use of <extValue> for the use case covered in 
> draft-ietf-regext-unhandled-namespaces.   

I believe there is and I quoted you so. Note the mention of "client-provided element", but
you seem to just ignore that point.

A specification can not list everything prohibited. It lists what is allowed
(and it says clearly "client-provided element") and then as a safe view you can expect
the rest not to be allowed.

>     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.
> JG - RFC 5730 did not envision this case, which is the point with the 
> standardization of draft-ietf-regext-unhandled-namespaces.  

Which is the core of the problem and the interoperability risk.
You redefine core parts of RFC 5730 without taking into accounts that clients
may not be aware of your change (your draft) and hence will have problems
if the server forces that new view on them, without any possible negotiation.

At this point it seems we are just repeating our own arguments on both side,
so I don't think either will move their position and we have to keep our
disagreement, which is fine.

I wanted to record my disagreement on this draft during WGLC, that is all.

  Patrick Mevzek