Re: [regext] REGEXT Interim Meeting 2018OCT16

"Patrick Mevzek" <pm@dotandco.com> Tue, 27 November 2018 04:02 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 8E7A8130DF9 for <regext@ietfa.amsl.com>; Mon, 26 Nov 2018 20:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=e/hscRis; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J/m/bqmC
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 dDWEYVM0Fh4r for <regext@ietfa.amsl.com>; Mon, 26 Nov 2018 20:02:21 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B68E130E00 for <regext@ietf.org>; Mon, 26 Nov 2018 20:02:21 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5AE1420A0E for <regext@ietf.org>; Mon, 26 Nov 2018 23:02:19 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Mon, 26 Nov 2018 23:02:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= message-id:in-reply-to:references:date:from:to:subject :content-type:content-transfer-encoding; s=fm1; bh=FCcUWCD+XjFPr xw12S/Hi99SR4oXmsxX4XyEXnJ0L64=; b=e/hscRisU+1nfaqwj82RstQUPScd9 a1dYDqpRJ7mi7iHFS6nkRYEnBfbzmT/jjKQkgK8aBuU/OksbxldJYHI2/0VENAeE /GIVfd/CL7uZWDf14EhW/00sdBfnIUR6lL7zbvyBYXdMA8BJcJZn/L8n1E9BtH8v OpwRLKRsEbk/mUZINWab0CM1Iy+iTPkGSKykfsiENliMR7Q4mOg18tqoXhs7oT+U rlb/RoC200RXMRQiyQ1Pi1x6YVl3WijdBk0WPKAXFssBI8oUycFi4zA9GBH2/q5X Wt2CN1H1ZFRNGtEQgfXWmJh9vrSxaXpeQDlZY+2tK7jCIaBqxvWWh6pCA==
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:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=FCcUWCD+XjFPrxw12S/Hi99SR4oXmsxX4XyEXnJ0L64=; b=J/m/bqmC 3cbtU1Xd/1qx+1KrgsaNjtJGkbBJ9FQLGAXSd8EuCPGuKkdtHbyPMR+KJLqn09Al ekghT6tpn9uVJ7ihrPhdG/sYe4Pvmxjw0ouVVevXfd8Wvle6c5lMVDR1mEGohoa/ nGg/rXcfvVCoj6dGfdjCGM2Jnvn0gk/vwmtlUsrIF0U5HtkD/kTkKjrAfsmso1+p Hzgwz2onPt9N8j9UUR5Xg87ZCYD/oHd8kh5CjkPxnGR+IxxwRuHXUvS2oXtdC88Y mqGDvqVigG1jiK87y6KfRgRDDjnkORVBErxYeEU3YIrVT9eslBbvUudVUqZ/l8Sq cNv4rTbUuw49qA==
X-ME-Sender: <xms:ysH8W2J8fe3Fk0MHZOUCVlQS5YJvmIoQFN4qTT6atAgWlpNJuuyv0W_ODK0>
X-ME-Proxy: <xmx:ysH8W-znnNJtsuMFlohnghNgEN78iVDRSKElkcjz7Lgw4wH-Mh2otw> <xmx:ysH8W50G27gRdyYxIMXw77si0hyyaiPGSWZpNaFM8wG4T1SGhQuimg> <xmx:ysH8W0pyap4jn2kGxXeTv6RF907lDMpo8cl48Sce-qXk1Ra2aTdBsA> <xmx:ysH8W3ClGd_e25g05oauVUhtDntm9b6XHBIdsvNnNnw4b7N3K0IHnA> <xmx:ysH8W9qhie79grOXyWj9R-P3ifx5TQ-JLhbyCq5wh8r2uJI_asogHw> <xmx:y8H8W1fa4OWapyEsu2fKPPjbE07sgEs8QKl5JCFoH0E3xFzkgd9UBQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 84E0FD47CA; Mon, 26 Nov 2018 23:02:18 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
Message-Id: <ca14342a-2778-41a0-b570-cd5383640a6f@sloti1d3t01>
User-Agent: Cyrus-JMAP/3.1.5-656-g84f879f-fmstable-20181126v1
X-Me-Personality: 66173168
In-Reply-To: <DM6PR02MB4906A4A5CA54F0EC02B8473AB1D70@DM6PR02MB4906.namprd02.prod.outlook.com>
References: <DM6PR02MB4906897BBA44E67A6F8C44B5B1FE0@DM6PR02MB4906.namprd02.prod.outlook.com> <DM6PR02MB4906A4A5CA54F0EC02B8473AB1D70@DM6PR02MB4906.namprd02.prod.outlook.com>
Date: Mon, 26 Nov 2018 23:02:18 -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/awcsbaeHLom1vXapdhgjwnk4li8>
Subject: Re: [regext] REGEXT Interim Meeting 2018OCT16
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: Tue, 27 Nov 2018 04:02:24 -0000

On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
>  * I still don’t like the use of the <validate:kv> elements as a 
> “flexible mechanism to share data between the client and the server”. 

There are many registries going this route, and it is very sad, even
if easy to understand why.
It voids any usefulness of the schema attached to the (XML) documents,
and basically will only need to interoperability problem because this content
will not be described in an automated content, and relying on human
documentation is not enough.

>     * The schedule format to use with the <registry:batchJob> 
> <registry:schedule> element 
> <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/5>    * 
> *Discussion*
>  * This particular topic is not straight forward, since we need a 
> condensed mechanism to define the batch schedules. 

I do not see why "condensed". We are in XML land already, which is not
known for its small size anyway so why would there be a need here to
condense things?

>     * Ensure that the hostAddr model of RFC 5731 is supported 
> <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/1>    * 
> *Discussion*
>  * In the case of a zone that supports domain:hostAddr instead of 
> domain:hostObj, 

No. It is not "instead".
Have a look at the example on page 19 of some registry documentation
at https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

You will see that both options can cohabit.

Now, I already know that some people will say: this is not allowed per EPP specifications.

But besides that it is important to be clear on the purpose of this extension:
being as "pure" and perfect as possible, with the hope that non-conforming current
cases will then suddenly decide to fix their thing in order to be able to use it, or
being as inclusive as possible so that as many registries as possible are using it
as is.

I think this extension can be very useful if many registries implement it.
If it is only a few, it will not give registrars a lot of useful data, and hence
they will not profit from it.

And I do not think that "not conforming" cases will feel the need to change just
to be able to implement this extension.

This is a generic point I may try to raise again later in the past threads about
this extension. It is an important question, that is itself tied to the amount
of energy devoted to each extension, which extension becomes working group documents
and which extensions really solve problem of more than one registry and hence
may have the chance to be implemented by a sizeable chunk of current players.

HTH,

-- 
  Patrick Mevzek