Re: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search

Patrick Mevzek <pm@dotandco.com> Fri, 31 July 2020 16:29 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 9E1EF3A0AEB for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 09:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=KL4WLhPu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sN6D7Qgb
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 GtQcjoXL6q5I for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 09:29:05 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558EB3A0AD9 for <regext@ietf.org>; Fri, 31 Jul 2020 09:29:05 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 985CF5C0129 for <regext@ietf.org>; Fri, 31 Jul 2020 12:29:04 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Fri, 31 Jul 2020 12:29:04 -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; s=fm3; bh=uZPFLf/RkCechtdtWckjE5nal4Rcw33 hPz70gfWGNHE=; b=KL4WLhPuUpXoH7J+yk2ZNWbY7p7f4HNNNdc7nr/ri+E0P6a kffuF5ZwsRDheB3ZDCn7BGIKpvHzLrs864S7u1OABW9l9HxlxRie9+L6yDoc7Iyx sJvV4j7rcvYTldu1UPtEEsYyCzEBWKh02xlMOqRU7jIgf4EamL/DuTRWPt0i9ELO NR0O+dnqYuQu81ngPeC7x0B08wcA6d55a5Z1AOJHeXpJZkNT616LblRrpUiTg4Ju enXm7Pyl4fu43AlQoxOHhdTly2vzjtyJ7uzC+joJg6Jom2UBk18y0HNB/HzaR9cN CEGtiEEglBmXBNX3SwkHQturgTdO9k0mrSbdUjQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=uZPFLf /RkCechtdtWckjE5nal4Rcw33hPz70gfWGNHE=; b=sN6D7QgbyWMKuDHoLrQmBW yj4mQc334tZgXuDcMj2YXRZJOQl3vWN37H7eAdD6bINUzI80VkgVNWMPCx3s4RkG NAxR83h0/fI3521wd+Lg4t6+MzBjAIe5XwY4aw3gC/30IncAQUZAJgA2jXjFe9z5 SQ4nS+pb8MHbg5LL4O3y99TIcSVP2lqzexA2nx00a8plsIpuOrmWICXGiNFCDl9m PvwDxrM3NO+j47K6kbcm3gN8Y+leByyrGnc4i1DmSEA7pdZF/xaNgHzrFFFWlWqu 0UnN2sX05kRhTnw3GPjK92oCPfk1X5eWyXiqfwwQm3CAQFLiZfdWEFGX8OQoTTAg ==
X-ME-Sender: <xms:0EYkXxG_EEz0WAWCepvVq8tKKZ8DXng66eov0BXEoeaYgrGpFBFadbkyyH8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieekgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpeefueeuieefffdvleeuvefhte dugfehjeevjeetfeduhfevgfeltdfhgeehjeehveenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:0EYkX2W8bJgk9D1zg0B9G79QnErBD9GJBNM-5BFnm4r-KuL1AZoCsw> <xmx:0EYkXzJNC9I-Hgw9doWSwc4v84J3JAx_p9Eglue0s23d20XLAtaxxw> <xmx:0EYkX3E2JmGh9Yxiq2GtjYNGs4juXS6JKGckVpwQSjzQ7KIFSIAtqg> <xmx:0EYkX0U3Vo_rL_7SS4AcEPrwFpy4u6RlnDhXFe329EyL-TMe6TUgtg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA7606680078; Fri, 31 Jul 2020 12:29:03 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328
Mime-Version: 1.0
Message-Id: <b52e75cd-0cdd-4ff8-8335-2e7423cfe94d@www.fastmail.com>
In-Reply-To: <abb138473ef245ce9eb3e263f2e85a57@verisign.com>
References: <1cb2fde4261748afa8163333d090b84a@verisign.com> <df404a43-8284-5466-7d83-88e27d5691ef@iit.cnr.it> <0f361bcb-cd2d-4336-8f71-f06f72430e48@www.fastmail.com> <234b29a5-ab00-6f1e-64f7-1da48673dbe2@iit.cnr.it> <65ee0574-0a07-4bf4-a73c-2d5fe8ec57f4@www.fastmail.com> <abb138473ef245ce9eb3e263f2e85a57@verisign.com>
Date: Fri, 31 Jul 2020 11:28:43 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/gJhpJQJMrEdojVnUG3zelJ7OeGQ>
Subject: Re: [regext] =?utf-8?q?IANA_Considerations_in_draft-ietf-regext-rdap?= =?utf-8?q?-reverse-search?=
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: Fri, 31 Jul 2020 16:29:07 -0000

On Fri, Jul 31, 2020, at 11:21, Hollenbeck, Scott wrote:
> Note "supported extensions". This is why I'm saying that we need to 
> register all extensions with IANA

I agree.

> and include them in the 
> rdapConformance data structure even if they don't describe a response 
> extension. 

I agree, everything should be listed in the reply to an help query.

I am just saying that for any other reply that is a specific one on a specific resource
then the rdapConformance should just list the "extensions" needed to understand this
specific response, and not list absolutely all extensions the server knows about
(and that are irrelevant for this specific response).

The list of what is written in the response should certainly not be just server policy,
especially if there is no automated way to learn about this policy. Otherwise if you include
options like that (the list presented might be the list of all server extensions OR only the subset needed for this specific response) AND there is no way for the client to know which
case he is in, it immediately creates interoperability problems. I prefer no such options
and the protocol clearly defining the content. Or if such options are really needed
(if help response is always all extensions, and any other response is just the specific extensions needed, then nothing more is needed), there should be  a signal to know which
case we are in.

> The help response should include supported 
> extensions that are available to that client.

Yes, the help response allows to "discover" all possible extensions from a specific client.

-- 
  Patrick Mevzek
  pm@dotandco.com