IETF Logo Mail Archive

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

Andrew Newton <andy@hxr.us> Tue, 19 July 2022 15:56 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 8742FC14CF0F for <regext@ietfa.amsl.com>; Tue, 19 Jul 2022 08:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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.20210112.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 be763ByGnfvF for <regext@ietfa.amsl.com>; Tue, 19 Jul 2022 08:56:02 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D61EC14CEFC for <regext@ietf.org>; Tue, 19 Jul 2022 08:56:02 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id q26so13778418vsp.11 for <regext@ietf.org>; Tue, 19 Jul 2022 08:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=na0nsYk38gszOWOWgYXfO2ZdvAf/GAAlpaDIk7OjjGw=; b=eWlGf/NB6cbHj9Ta5CHTAxiA/p1KCNt7OkS3mqDaGW5afYrVfytE18gTp2JoRWulHe NroHZO1anoNlEJqlZVq9PRPf8dT4RYYwlTwdOfCS7iLp0g3Wv781Hfg7MO5gXSgYN0Cx 0d04aETmuSkN6adbCR4KE9HvNqI8pVc0HOARWBBlbviyCIU7f2RaI5zbt5ihwSAvUOrT b8qSq4EL5zOLQttvmM28r0ERTsNB3HmGfOYCiBZN7saEK6u0os6Dv8OCzT+kQxL+Syjh cUhDalVk32tMuVDHGGt8BqJ0hquXY2HPzOOjqTgc0YeMC22bpucpIvkzZCSLhZ1BUYvm Odbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=na0nsYk38gszOWOWgYXfO2ZdvAf/GAAlpaDIk7OjjGw=; b=mKQOpNToFqgWmWGA1OIA9OhYtN3T4N1na2qllV9FK9AGEHkaqW4FsrYLSpccb7nkRA Q1meqY3ilr8KstcyfSldlDVuMT8lkaLAzKLkoh4Fod+7am45E51JAK77pOOHSeCW9qK+ /0002xQTkYY2v3lh4irrjEhQDtbaiwoIDoNW2ER1DZf1S0yBNudnQ+Zqwmox95xpMepo ukhQDpng02gnB/y5mJBaSAqUA5o63tQhTmjMjizs+hM534E69G5ooNS8+QZ2MSSwOjic apSUq2hGKDB4IepmmXzsP0q123tVEgey10kmu9fugW6WXLcLMc3/RfjwXcsF3s75+CsB Xrhw==
X-Gm-Message-State: AJIora/WeYYQy7aAWTab+jLhFirrhQm/veW9WBHqDz62Z9gxOF10LH9M AoT41LGINQz9CgnftcCIHd6CuWzX2WR9uzIgAiM4Np5aFdPCqi5T
X-Google-Smtp-Source: AGRyM1vtZW8j8mtS6Fr7+ozRKjyTf2JuoszpMdOtPQZnkHRmvVUyeKwXC2caJA8mgksHIQu/J0u4QKnb04KBBKEJboo=
X-Received: by 2002:a05:6102:2432:b0:357:4793:d267 with SMTP id l18-20020a056102243200b003574793d267mr11869841vsi.83.1658246161197; Tue, 19 Jul 2022 08:56:01 -0700 (PDT)
MIME-Version: 1.0
References: <64394414-B420-417D-A01E-1333D81FE5B4@verisign.com>
In-Reply-To: <64394414-B420-417D-A01E-1333D81FE5B4@verisign.com>
From: Andrew Newton <andy@hxr.us>
Date: Tue, 19 Jul 2022 11:55:50 -0400
Message-ID: <CAAQiQReNAfxRk49gmBgJYw=JAPoSt8_FpgQyEa2KP32uENdOKw@mail.gmail.com>
To: "Gould, James" <jgould@verisign.com>
Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/lG_fPuiTQtefAp9RhKmrSl45Nz4>
Subject: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
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, 19 Jul 2022 15:56:03 -0000

On Tue, Jul 19, 2022 at 11:27 AM Gould, James <jgould@verisign.com> wrote:
>
> Changing the definition of the rdapConformance from an array of strings to an array of objects is certainly new and has never been defined.

Correct, but that's not what I proposed. The example JSON from my
previous email is below. I proposed to use the existing mechanism
which is an array of strings.

{
     "rdapConformance" : [ "rdap_level_0", "exampleNicV1", "exampleNicV1_modA"],
     "exampleNicV1_foo": {
          "bar": "buz",
          "exampleNicV1_modA_bar": "bazz",
     }
     ....
}

> The existing definition of the /help query doesn't respond with anything formal for automatic consumption by software clients for the purpose of auto-discovery.

The /help query responds with a normal RDAP response, which will have
the rdapConformance string array used by clients to know the
extensions the server supports.

-andy

v2.23.0 | Report a Bug | By Email