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

Patrick Mevzek <> Mon, 19 October 2020 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BD703A1214 for <>; Sun, 18 Oct 2020 19:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=N5gwEhfN; dkim=pass (2048-bit key) header.b=TGA9Yy18
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MMqQKTl4wQ5O for <>; Sun, 18 Oct 2020 19:07:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8E083A1167 for <>; Sun, 18 Oct 2020 19:07:32 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id DFD155C0079 for <>; Sun, 18 Oct 2020 22:07:31 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Sun, 18 Oct 2020 22:07:31 -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=y3wKUtSt1clyWuxLT8u1qBXTuk1epQ2 HMmSEMSwdNAQ=; b=N5gwEhfNj5rSnfkgKqWSGmRJqJwpvOJsNwt2viPgW1xKkz1 KpV0aUdU668+lfytWLbhJIoebcqffYZ94XMz3cSy/3DqBLHOVugM3/ts4pZ2d6bg 2scVLszwUaSqY8ft4XdigqBgjLj5WIGhqIokWl1BbaZCgo3WZF7yBxLLfpRSm+eG 4cdspUkxOEH0ztfcuWENTvN1QJICuo9kHTqel5UfyQzyDFk4TurtbqwRj8dKFMOc SKcEWfRa4c3G8s4i27Z4GVVSmj6ZaITkczrx2a3h6zGaCX3KQv4qsXlllsWF7+Zq Zb/Qqha8XTq7VBggaT5d+TQPbsnMZL1wjKUD/KA==
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=y3wKUt St1clyWuxLT8u1qBXTuk1epQ2HMmSEMSwdNAQ=; b=TGA9Yy18/54IxVsJtlakF2 4tQ7U+ECLb4yOWU4q7dW2w3z9dHbfHo1xpeYtiNFFLZzNm4tjfyy6zCwgVm/Vjge itzSu0v9ScSPzD7QUzBpilTKBxTx6RNe2t3f2Htoeww+i2ljUwVEbEI8qV0hNAMB 9f0hjl7pKMv42fAX19f9ExEla415Wy8lMgnvBlqRAwSbKlvyEG7vTEN+5MtQHE5W MlwChBWq96AI4naqgcNrpEZ3H/hlzElufPvm8C405VF75FUQKROZFbDfqbAMx3sO KaUZPf4KK9KEinh6jjwxXcsTAYhSeaUap4C49r1m5bvnayIFNjG2AjL+sa366tjA ==
X-ME-Sender: <xms:4_SMX8GKEm1rTrmQgRwBG9nIgt6mTsIofZPP8BiQm7869qBdcEUua4GBLwI> <xme:4_SMX1WWcKkAOb38tmIv61Tn53ovSLCO7kHd_KNNoTq_DmTvoqXjErA3Vun_quTRa jIW5PpuMKfWB9woEA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjedtgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmseguohht rghnuggtohdrtghomheqnecuggftrfgrthhtvghrnhepleduhfegvdfhkedtueegffeiud dtgeevjeeiheeutdehtdeivefgveegfefhleevnecuffhomhgrihhnpehivghtfhdrohhr ghdpvgigrghmphhlvgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:4_SMX2K4vI-4_WXJEfrwfMCTkr0OdTMeroRO1aNaoZjytUPhee-xHA> <xmx:4_SMX-H5Pfw1TrW_6caflnyqaS2xgLNVO96fCZevYwKhO8KAyptyMw> <xmx:4_SMXyVPk8pfPOW8aZe8OMk7WQ9Jk-gSwlb0l-yU2mAA8p3_HIP-0w> <xmx:4_SMX6gsxwyqe8s6JPiP_xmqtd8Yk9miO-3zNCWYmLr0ynzqYwibdQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2DAD76680078; Sun, 18 Oct 2020 22:07:30 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Sun, 18 Oct 2020 21:07:09 -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: Mon, 19 Oct 2020 02:07:34 -0000

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:

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

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></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.

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

  Patrick Mevzek