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

"Andrew Newton (andy)" <andy@hxr.us> Wed, 04 September 2024 15:05 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 EADA1C1D8752 for <regext@ietfa.amsl.com>; Wed, 4 Sep 2024 08:05:56 -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 YGW-fIGiVshE for <regext@ietfa.amsl.com>; Wed, 4 Sep 2024 08:05:56 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 4CDFCC1D61F3 for <regext@ietf.org>; Wed, 4 Sep 2024 08:05:55 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6c3567a143eso24286206d6.2 for <regext@ietf.org>; Wed, 04 Sep 2024 08:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20230601.gappssmtp.com; s=20230601; t=1725462355; x=1726067155; 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=VYMwsuqDZ2sd2gibzaqrPConQJHnFIl0uw4g4445Pjo=; b=dgzlDzY9h0yIUvBm6I8DZmwcPX60Uz5+I2PIu/71aUhAwvyaWwO+GdDOcukdTPsVwi UK8N9DQ3RFfEoRjx8RpygqRFNqV7nITkHKevlLlbVJ1Q4yHLvmWb/gYJiL+B1QdCoSqb 3x38VdgSLbJ1/pTQuzUh7jVZl1gMqmuwXfdADnnR4ftWo7qPEpeGZVtBx68jukqla4Tt YO4eIeEAIm1Dcm0rYbFom+DsHKwm9MFPqlWg/FOS2duwEeFPRqyexJPynuef8bcEfvlE qX7I8w0t4BvWSK9p8jdCib71c0W2s463oO9sWX1KtLd76yUpcOn8qQPrzVRi2PNNRIDQ OPrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725462355; x=1726067155; 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=VYMwsuqDZ2sd2gibzaqrPConQJHnFIl0uw4g4445Pjo=; b=q6wjCIhaHrgpdc9OzLiGHKY+/j9bHAalEBA+eM7Op6m0v7wkCA1nHHIAbwWiMG5+N1 FrtLDTr5/3co56S3DwuLoHd3y/m5q4BP5hDdEFcYBcCC4nqN38k/VGO2Ns7jsYpSfMhB 8qTKJLzPH6RB5CCwm6de6LEZ2jqKlbO/9t+CatUS9KZQl6mIAGOdPzeLJ2biPN5FZVej puHpCB4P4v6ye6/dhY9jw/S/sjJ+xZ9nGRFIGmA25CPRplao4nqLnfQRg8HLPjyKWw3z /KWlsEaxTg91FaNBKi1OSgCetjgZQ68cOnCB7PQloBGIhSrU73JLW/WnE7f6Du1Yf/X6 Nn2w==
X-Forwarded-Encrypted: i=1; AJvYcCUlsCGSYJjnrYgXmYudkTZ1tuAEeQYZj4DVsxls8+pF8nkLtlJnXz4gpUC+eCc2LaMacVS9i1M=@ietf.org
X-Gm-Message-State: AOJu0YxtWNTkfq5aFy6QiW5d9vmx7X+uCyZHPiypYgy+vckJP8QYgUvH 4nksqXzOmtnFG8wIGl/IjJPnIzF+OsufTXkZtiuFnG/UmL8k9VJ26b+c9xdcYxGQ+QQfK9DILQB Z
X-Google-Smtp-Source: AGHT+IEk3A69vJn5zQEjE0l458Pfwf1hnoVGNWsvg5uxMTmfwUvgebEzXeuIiOhqepIncZgNzYhfHQ==
X-Received: by 2002:ad4:5511:0:b0:6c3:55c4:cc1c with SMTP id 6a1803df08f44-6c355c4cdd5mr132373326d6.1.1725462354409; Wed, 04 Sep 2024 08:05:54 -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-6c340c2ac0csm64152846d6.53.2024.09.04.08.05.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Sep 2024 08:05:53 -0700 (PDT)
Message-ID: <77102919-b8ce-482a-ace4-30278e28bed1@hxr.us>
Date: Wed, 04 Sep 2024 11:05:53 -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>
Content-Language: en-US
From: "Andrew Newton (andy)" <andy@hxr.us>
In-Reply-To: <B0B74EBF-6A29-4529-BE5B-EBB70B64B815@verisign.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Message-ID-Hash: CUFMPOLPM6ARYBCZLYPHAZ2IPCVVH7CS
X-Message-ID-Hash: CUFMPOLPM6ARYBCZLYPHAZ2IPCVVH7CS
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/hefwP2QjWjWFRUIi0Qv09yXGdvQ>
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>

Hi James and Scott,

I posted a PR to address your discussion points.

https://github.com/anewton1998/draft-regext-rdap-extensions/pull/30/files

Let me know what you think.

-andy

On 8/23/24 10:00, Gould, James wrote:
> Andy,
>
> It may be useful to include guidance for RDAP extensions use of the RDAP JSON Values registry in the extensions draft.  I believe that new RDAP extensions should be encouraged to support standard values to increase interoperability, where extending the RDAP JSON Values registry is better than creating a new registry specific to the RDAP extension and certainly better than not leveraging the RDAP JSON Values registry at all.  The Redacted Extension did this to define three new types with "redacted name", "redacted reason", and "redacted expression language", and the language used in the first paragraph of section 6.2 supported the extension of the types.  We could look to have any new types define the expected format of the values to help support the review by the DEs, where some types may be more freeform than others (e.g., support mixed case).  For example, the "redacted name" values did use mixed case to match the source policy and I believe the "redacted reason" values would be in more sentence form with mixed case and potentially punctuation.  The "redacted expression language" is more of an identifier, so it could be predefined as being only lowercase.  The Versioning Extension has a similar extension of the RDAP JSON Values registry types with the "versioning" type and registration of the values of "opaque" and "semantic".  I view the "versioning" type as more of an identifier, where being lowercase makes sense.
>
> The extensions draft could clarify the expected value format for the predefined types in the RDAP RFCs and provide the guidance for how to define new types with the expected value format for future RDAP extensions.
>