Re: [regext] Signaling BCP support in EPP for draft-ietf-regext-secure-authinfo-transfer and draft-ietf-regext-unhandled-namespaces

Patrick Mevzek <pm@dotandco.com> Mon, 27 April 2020 05:07 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5653A0BCE for <regext@ietfa.amsl.com>; Sun, 26 Apr 2020 22:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=zrFJbCMG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e81K6VuD
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4l8uC5RqjNP for <regext@ietfa.amsl.com>; Sun, 26 Apr 2020 22:07:43 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A833A0BB1 for <regext@ietf.org>; Sun, 26 Apr 2020 22:07:43 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C46405E8 for <regext@ietf.org>; Mon, 27 Apr 2020 01:07:41 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 01:07:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=iT00A 84RlPmWkk1SrIV3Aik1mScn/IR+HXv8s52N1Kc=; b=zrFJbCMGSUd96aXbBEx5P MQSmjjUlRKG1Vw0o7U36Dn244uawXfhyxJOC5vKh32dNH3f1ggbTDXKFwhkvClzy FNnIB9pKNlPT3vVTC2yRmQpw6kp+VDYnlR5I2SWIehXnto3frWevlM8uPmKmXX2+ W7gzICakHaPOClLdkFGRd/ID8J/cQkzScdtEv6XYyDnD4A8zhIqWnku1nfbykUYw rqta8kMyjMbuzqMCpK927YARv27kjCKkF0xctyZstSWW/65m5JJ7wBfjjP9h+rIU Hpk8VsiDsfHiAHvn6Z+vY1VERFjIg4BGmV4orM0tnS7zSUkWu8uEuH+sbwbeUzPL A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm2; bh=iT00A84RlPmWkk1SrIV3Aik1mScn/IR+HXv8s52N1 Kc=; b=e81K6VuDkEZ0OcHexIUlJOWeo1i4vRcuVEaLlwpAZOglhgEcimCcJIMkU i3ApRYwWgEUB67/1zsBqvei9iX6Edqe5lT9xx6du8cULpNIm+J1S4JBtBDPNmo0s 6PVqZa+z/qTE34vpe4H9iT0+Pu+R/8nLlvcVcYQQ8rE7xLN+oGB4ggQ+6gjEuH8W vOOjD41dBB+T3dzmjgZMJ/wq5v9PLyw3gmY4x/6P5uYQ5VYQmPw8pDaoxM9kSpR4 k0Agm3T0sJMvtVQUUgph1k9qz4QJYJCawXrf+JNY2h9HWIUaq2iAUtAYPyrUPpim PcTD62eJVKPuF9M/I3c9ZBggt9/YQ==
X-ME-Sender: <xms:nWimXtcqo0-7OdB5Q9iTslQQzEFjyNcDA35wiX-j9oqwlA_srk87gnQpMg8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:nWimXkn5apVKFK1YBYGW70UoZotoQ0W6_RWoio0vXHeP_g4B2VBCQw> <xmx:nWimXvo48uZlbx87A9jDk5XKr4FKdfEPeglTlsj0tvykNTGFds5gkA> <xmx:nWimXp8MqIFJZ0sSbkU3maPhYJnY31B_kszBVTvAy9MmNkAi_zaCcA> <xmx:nWimXh3rT3jxR23VY3YEfwiVJVJX4TDiwBjkdkwg9dmi5JnPJIh4pw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0639B6680073; Mon, 27 Apr 2020 01:07:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <5045e9f9-c35a-4a71-a394-44791596a90f@www.fastmail.com>
In-Reply-To: <05FCD17E-1868-4B58-B873-276013142D3C@verisign.com>
References: <05FCD17E-1868-4B58-B873-276013142D3C@verisign.com>
Date: Mon, 27 Apr 2020 00:07:17 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/5xkbRcuMnZ7xYDQM44GQmAuirPM>
Subject: Re: [regext] =?utf-8?q?Signaling_BCP_support_in_EPP_for_draft-ietf-r?= =?utf-8?q?egext-secure-authinfo-transfer_and_draft-ietf-regext-unhandled-?= =?utf-8?q?namespaces?=
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 05:07:46 -0000

On Mon, Mar 16, 2020, at 09:28, Gould, James wrote:
>  
> One question that was raised by Patrick Mevzek on the mailing list was 
> associated with signaling the implementation of a BCP by the server 
> that I believe would also apply to the client. This question applies to 
> the two REGEXT BCP drafts draft-ietf-regext-secure-authinfo-transfer 
> and draft-ietf-regext-unhandled-namespaces.

Aside, for this last one that is using extValue I think the extValue should
be more properly categorized to be related to this extension.

Rationale:
1) even if you put a message in <reason>, this part is clearly for humans,
so no software should have to rely on this content
2) extValue can be used for many things. In fact the way the draft is using it
is kind of violating what RFC 5730 says about it:
"A <value> element that identifies a client-provided element
            (including XML tag and value) that caused a server error
            condition."

What will now be put there is NOT client-provided but server-provided.
Which is also one of the reason why I have mixed feelings to handle
unhandled namespaces that way even if there are no other proposals.

So at least maybe something like:
<extValue>
<value xmlns:unhandled="....">
<unhandled:content>

(here would appear the XML part that the server wants to give but can't 
because the associated namespace was not selected by client at login)

</unhandled:content>
</value>
</extValue>


Introducing new content can break existing client without proper signalling.
You might say that if clients have to be updated to do that, they might as well
be updated to correctly handle the unhandled namespace part, but as discussed
previously already, things are not so simple in real life.

> The only existing signaling 
> mechanism in EPP is the use of the greeting and login services. A 
> namespace URI could be assigned for each BCP draft that is included as 
> an <objURI> or an <extURI> in the greeting to inform the client of the 
> support of the BCP by the server, and in the login command to inform 
> the server of the support of the BCP by the client. Between the two 
> options, I prefer the use of the <extURI>. The questions for the 
> working group include:
> 
> 
>  1. Is signaling needed in EPP for the implementation of BCPs?

I think so.

>  2. If signaling is needed:    1. Will the existing signaling mechanism 
> in EPP with the greeting and login services meet the purpose?

There is currently no other option.
Contrary to TLS handshake for example where each part is able to offer
details on its capabilities before deciding to pursue the exchange or not,
in EPP the client has to accept what the server says, or do nothing.

>    2. Of the two service URIs <objURI> and <extURI>, which is the 
> preferred URI to use?

extURI is the only one matching semantically.
RFC 5730 says:
" One or more <objURI> elements that contain namespace URIs
         representing the objects that the server is capable of
         managing. "


If the namespace URI is not about an object, then it shouldn't be
an objURI.

>    3. What URI scheme should be used? 
> i. One proposal is to include bcp in the namespace, such as 
> “urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-<version>” and 
> “urn:ietf:params:xml:ns:epp:bcp:unhandled-namespaces-<version>”. The 
> <version> would be updated based on material updates to the BCP draft 
> and bumped to 1.0 after WGLC. 

I am not sure of what I think, but I am not immediately a huge fan of 
putting bcp in the namespace. I do not know if there are other examples
in other working group/the IETF, but the main problem I see is that
BCPs can change during time, and you won't be able to change the namespace
once it has this in its name.

-- 
  Patrick Mevzek
  pm@dotandco.com