[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt

"Andrew Newton (andy)" <andy@hxr.us> Thu, 05 September 2024 14:12 UTC

Return-Path: <andy@hxr.us>
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 18F3DC14F68D for <regext@ietfa.amsl.com>; Thu, 5 Sep 2024 07:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEgbxA0f9hJY for <regext@ietfa.amsl.com>; Thu, 5 Sep 2024 07:12:31 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE1CC14F60E for <regext@ietf.org>; Thu, 5 Sep 2024 07:12:31 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-45680233930so4868061cf.3 for <regext@ietf.org>; Thu, 05 Sep 2024 07:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20230601.gappssmtp.com; s=20230601; t=1725545550; x=1726150350; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=TPaxedwwdRzAnnifsyQCMpn5yipGGTEnXsh2aXkSdTM=; b=M03acL+rwapfeExZ+yQ4kGmcdoOLMzuj5zo79yGaNnON1I/oHgmi91xNCVQWejsDsv bH+dhdij+4AADlact3mcR4ZfUXHKZgDPLy52lrgoqxL1SZxoJ2/7AI4Fd9DWsVK0QsoZ slTiSmEqTsiXApJWMTDXfcOyFvLHasgyaEIy7jEIk6AWOqvQVJolXy+6N8fA8vksIxCF GkrjQ5qo2fPgXM4pXCB8qQt9QaZlFxTUGTAQiEZZDHX3hPkAis3vWLtdDlJedw1FvHWa 5Ktv0cI7yBUNoWtEC5E+xhGAjHDrVmGdEe0mTQE6msZk5EuFdxtKjClxCkx6PDFD2meg Eojg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725545550; x=1726150350; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TPaxedwwdRzAnnifsyQCMpn5yipGGTEnXsh2aXkSdTM=; b=p8zRRDPuVMH9Ar2rIjSZfMllUHrAcTFwtfUbORKKMiq5+NAiGRB5aXbpqNTsOu1sSj Z51Dc0jnMgYmh4ztowtWjd8h1AX6bKCR/0stJlAxDx1WpVBw+WeEFGnZFX8ahvw3YSt3 MWdS5uNZ0rXJecp3HU7frrggf+J9jBGw3QQnSDENd4ZW9k0HQgTeQuZUywmQ2N83j8wE JXyoGZFExIIVfZ0U9SG9icCpLgX+C1cDxFHuIOHI+pH95j/PiHs2VOOe5/WYAsfrQlFT vcwgHvBiptuan6cLMCkfxdFNC1GCpfNeh9mzfjQHftZjvy8bMkikPVDdyOER5XB9ZYl3 UiqQ==
X-Forwarded-Encrypted: i=1; AJvYcCU3PnuOJZSuDI/Uqh9jsNENGHm9/Kx/fPkp76LarjYe6JaYCmII2xlN+PgyRNZL5v+VlKoM3xg=@ietf.org
X-Gm-Message-State: AOJu0YwcM0sKzC8UO+OCrSurUuBHx2VdcEySal4dpr9vuK1Vq8DVb96y ufkA41zaN7Qw8IWocXgS2wQFHJNTOAf/Jy2vzNs5aCygOwFwtIqVrTWX7xGQ+Hs=
X-Google-Smtp-Source: AGHT+IG3S+wlDCKliVX2g3ZQOsYMuUAEXNqvDAiFnjFnFnSHzIWeB0MiSruzojiYXQA4u8cEFCJzTA==
X-Received: by 2002:a05:6214:3b8a:b0:6c3:8360:583c with SMTP id 6a1803df08f44-6c383605a57mr108190096d6.23.1725545549894; Thu, 05 Sep 2024 07:12:29 -0700 (PDT)
Received: from [10.2.8.27] (pool-72-83-25-32.washdc.fios.verizon.net. [72.83.25.32]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6c5201dee90sm7783106d6.22.2024.09.05.07.12.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Sep 2024 07:12:29 -0700 (PDT)
Message-ID: <8c10fdcd-8959-4b0c-9d93-48585dc8ecd2@hxr.us>
Date: Thu, 05 Sep 2024 10:12:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
References: <172415634166.2088655.15896242296287714306@dt-datatracker-6df4c9dcf5-t2x2k> <7f9c41fc-9582-4c08-9320-ad4d844079b1@hxr.us> <16F179E7-855A-45BA-A491-512960F5B464@verisign.com> <7a574cd8-16a1-43fe-ad1e-fef03e9af068@hxr.us> <B0B74EBF-6A29-4529-BE5B-EBB70B64B815@verisign.com> <77102919-b8ce-482a-ace4-30278e28bed1@hxr.us> <35492F7E-FB26-422F-A861-6642B41AB225@verisign.com>
Content-Language: en-US
From: "Andrew Newton (andy)" <andy@hxr.us>
In-Reply-To: <35492F7E-FB26-422F-A861-6642B41AB225@verisign.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: DOWKNXXCQW4RNMUZ7T5HVW5OXFVEUIUB
X-Message-ID-Hash: DOWKNXXCQW4RNMUZ7T5HVW5OXFVEUIUB
X-MailFrom: andy@hxr.us
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-02.txt
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Z-8OZPHsAI6Q93ExIE8-1Q3gAvc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>

On 9/5/24 07:54, Gould, James wrote:
> Andy,
>
> That language looks better.  I believe it would be good for draft-ietf-regext-rdap-extensions to cover how new RDAP JSON Values types are defined.  The RDAP JSON Values registry can be extended by Type and by Value.  The definition of a new RDAP JSON Values type could include the expected format of the values.  Should clients do an exact match of the values or a case insensitive match of the value?  I believe there should be no conflicting values based on case in the registry and clients should implement a case insensitive match instead of an exact match.  Some values may benefit from the use of case and some values may not.  The values for the "notice and remark type" and the "redacted reason" could benefit from the use of mixed case since they're not identifiers but use sentence form.
>
> Thanks,
>
James,

Good additions.

WRT to the expected format for types, the current language says that a 
new type MUST be registered with a stable reference (actually, the 
language has a double negative which needs to be fixed). If we are to 
have the DE's looking at values and evaluating if they meet an expected 
format of a type, I think types should only be added via IETF action. 
That is, the DE's should not be expected to evaluate formats that are 
poorly specified.

Thoughts?

-andy