Re: [regext] Questions about RDAP extensions and registration at IANA, role of prefix and version

Andrew Newton <andy@hxr.us> Thu, 07 November 2019 15:02 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 4304512089A for <regext@ietfa.amsl.com>; Thu, 7 Nov 2019 07:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com
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 ctnFTq1vNl2a for <regext@ietfa.amsl.com>; Thu, 7 Nov 2019 07:02:08 -0800 (PST)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43227120862 for <regext@ietf.org>; Thu, 7 Nov 2019 07:02:08 -0800 (PST)
Received: by mail-il1-x135.google.com with SMTP id m5so2096221ilq.0 for <regext@ietf.org>; Thu, 07 Nov 2019 07:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QElOFb4em2T37JjcsRziTS8ddjYD14KyR11WG/5YhCA=; b=ajzA2J+1ppWaSVw2K5rr0wgCla5eybtKMbobdf0Y+j2UPBN9LKzIM81oe//v7CbytM RwqqxkBB8U4sa14x14x7TLO9nrHKT+T7zAsjV4UfVhivSMyUn7Uwg/yNwKC+t9qBnRR9 72PIb7OYGjuUkEgyiZeQLoVhfhxDt4JF886UUea//OlTfYTPpvJivmqHWm72KbUlHZ0R zKylhnauNAEy8uG2iipSv0tNyqcf3/FngxqoElHE4P84DLb9Un7Qw7mlDp1s53FVBZYF kaPXnFn2BQedOMxJ9mswYK87OzaoGqR2nGA3IXAbHc3SxSVwM385WIIaCLcGBkxCkHkd jXOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QElOFb4em2T37JjcsRziTS8ddjYD14KyR11WG/5YhCA=; b=ofWivnkNoAZx8quScVG3WF2fQ0Bnouo5Hr8MIYZbjNCVOe4uXBTLA4v6sUp8nwKMc7 UjwM4JUDTY1wwnyIicop2DMYje3dnHwZV+p+354Dp4zxOSJqXTrs7m/8nkWO9zQF7UO/ EasPTT1ct+TntoieyCpV+euWrQMgUmdyVdKE5qwYYHhBeXAEz0qWYRJpTkdE7V0rijSE knbVkttOkckxCTa8ju8ZQlwDN4ECb9pO0aS/2wVdmS2RWxOFLS94jKU0zZTiegu3nzdO z12DLgfJA6QdN9GgVa5P7bxVgIhWIApKNzGLUlr4Oq75a3e1eAXPnNh+B9ri22/QWVBg PowQ==
X-Gm-Message-State: APjAAAUm8UIR9Ek1X2v+vi7KD6jtfewEOiS45PYDGUxnwwNvrv96B/ro AAvb8SVbpTS0ay2oe/92xYvpJSA3m8QdsVdL5IpVTQ==
X-Google-Smtp-Source: APXvYqyu0RW+ozM4Yd5shShZ0U29NUWH2nuqRy1Gqb/Ht7O6qQeuDomgauC/aXOIrewiDuaz3fQkOV+vT3be7DoyXdE=
X-Received: by 2002:a92:1613:: with SMTP id r19mr4898403ill.10.1573138925053; Thu, 07 Nov 2019 07:02:05 -0800 (PST)
MIME-Version: 1.0
References: <cd67ca1a-febf-4304-afdb-e70b39026cd8@www.fastmail.com> <0851ad33353441189ae5d5b4baa3e9fa@verisign.com>
In-Reply-To: <0851ad33353441189ae5d5b4baa3e9fa@verisign.com>
From: Andrew Newton <andy@hxr.us>
Date: Thu, 07 Nov 2019 10:01:34 -0500
Message-ID: <CAAQiQReKtfVxD6XvnoA1kqEp9qEEXEMdcGoEaZ3m6CUkc5wwzg@mail.gmail.com>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: "pm@dotandco.com" <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>, "marc.blanchet@viagenie.ca" <marc.blanchet@viagenie.ca>, "andy@arin.net" <andy@arin.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/fykapsIRSNRz9czmI5F1-UMD2bo>
Subject: Re: [regext] Questions about RDAP extensions and registration at IANA, role of prefix and version
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: Thu, 07 Nov 2019 15:02:15 -0000

I agree with Scott. The idea is to prevent collision and provide an
easy way to lookup the spec in the IANA registry.

These are supposed to be opaque identifiers. If an extension author
wants to add their own sub-label versioning, I guess that is ok but in
my opinion they are making things more complicated than necessary.

-andy

On Thu, Nov 7, 2019 at 7:05 AM Hollenbeck, Scott
<shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
>
> Patrick, my expectation is that the value registered with IANA is the exact value that should appear in an rdapConformance section. The purpose of these values is to clearly identify an associated specification, so one should be able to extract an identifier from an RDAP response, look it up in the IANA registry, find an exact match, and unambiguously identify the associated specification. We clearly need to clean up this part of 7483 if/when we do 7483bis.
>
> Scott
>
> > -----Original Message-----
> > From: Patrick Mevzek <pm@dotandco.com>
> > Sent: Wednesday, November 6, 2019 1:37 PM
> > To: regext@ietf.org
> > Cc: Andrew Lee Newton <andy@arin.net>; Hollenbeck, Scott
> > <shollenbeck@verisign.com>; marc.blanchet@viagenie.ca
> > Subject: [EXTERNAL] Questions about RDAP extensions and registration at
> > IANA, role of prefix and version
> >
> > Hello,
> >
> > (after having written all the below, I see it is touched already by
> > https://tools.ietf.org/html/draft-blanchet-regext-rdap-deployfindings-
> > 05#section-2.2 for most points, so there is some overlap but still sending my
> > views below, because that draft hints at just changing things in the current
> > IANA registry, where I think some RFC changes are needed too) (so CCing
> > the designated experts for the IANA registry, and Marc as author of the
> > above draft)
> >
> > IANA registry at
> > https://www.iana.org/assignments/rdap-extensions/rdap-
> > extensions.xhtml#rdap-extensions-1
> > lists extensions names.
> >
> > The examples in RFC7483 with lunarNic makes me think that
> > * the prefix is lunarNic
> > * which is what should be registered at IANA
> > * the conformance list has lunarNic_level_0
> > * fields have lunarNic as prefix.
> >
> > So "_level_0" is a kind of suffix, under control of the relevant party (of the
> > namespace being registered), but is it free-form or should it be always
> > _level_XXXX?
> > Once "foobar" is registered at IANA, what is its owner allowed to do?
> > Can it uses any of the following in rdapConformance:
> > - foobar
> > - foobar_0
> > - foobar0
> > - foobar_level_0
> > - foobar_buzz
> > - foobar_level_0_sublevel_42
> > ?
> >
> > RFC7483 §4.1 goes over this without explaining it.
> >
> > So some observations/questions:
> >
> > 1) _level_0 is not the only case.
> > "fred" as registered, appears in rdapConformance as "fred_version_0"
> >
> > So this would make me think the _level_0 syntax is not mandatory
> >
> > 2) some extensions do not appear used with any suffix:
> > "arin_originas0" and "cidr0" as registered as such and appear as such in
> > rdapConformance.
> >
> > However, the final 0 seems like a "version" indicator, so why "cidr0" vs
> > "cidr_level_0"?
> > If so, should the registration be instead for "arin_originas" and "cidr" so that
> > the relevant owners can "upgrade" to a later version without a new IANA
> > registration?
> > But if so, this creates a collision. Shouldn't the RFC mention that when you
> > register X you own X_anything, not Xanything, that is make at least a _
> > character mandatory after the prefix if what is used in the rdapConformance
> > is not exactly the prefix?
> >
> > 3) kind of same case for:
> > icann_rdap_response_profile_0
> > icann_rdap_technical_implementation_guide_0
> >
> > they are used as is in rdapConformation, but shouldn't the IANA registration
> > really be for the prefix, without consideration of the "version"? And they do
> > not use either _level_0, _version_0, or 0 like other extensions, but now _0.
> >
> > Even their own specification says:
> > At the time of publication,"icann_rdap_technical_implementation_guide" is
> > pending registration in the IANA RDAP Extensions Registry
> >
> > So what was registered at IANA is not what the specification says, there is a
> > "_0" difference.
> >
> > Again, it seems the _level_0 part is completely optional, is that the intent?
> >
> >
> > 4) RFC 7480 says about extension prefixes: "and they
> >    SHOULD NOT begin with an underscore character, numerical digit, or
> >    the characters "xml"."
> >
> > I would suggest this is amended at some point in the future to reserve
> > everything starting with "rdap_" to only be used by extensions defined in
> > RFCs, like RFC8521 does.
> > (I am not sure what is the gain by refusing "xml" as prefix, even if I do not see
> > it as a useful prefix either. RDAP is far more JSON than XML stuff so if we had
> > to restrict something "json" would have made more sense than "xml" to me,
> > even if neither makes sense to me in some way here; explanations in
> > RFC7480 §6 do not really convince me there)
> >
> >
> > What do I miss for the above discussion on prefix/suffix/version?
> > Are there other documents explaining in more details this prefix/version
> > schema and its rules?
> >
> > I am not asking all the above for the beauty(?) of it, things like that have
> > strong interoperability consequences and needs to be taken into account to
> > properly design a client connecting to various servers, which I sadly discover
> > only now as working in RDAP-land.
> >
> >
> > PS: unrelated additional petpeeve, for here or anywhere else, any link taken
> > to a "reference" but which points to a git repository, without enforcing in the
> > URL a specific commit, is not really a reference. It points to the latest
> > "master" version of that file, which can change over time, as a branch tip is
> > not a stable reference. Links to repositories should be refused if they do not
> > include a stable reference, which means a commit ID (a tag can also move, so
> > it is not good enough)
> >
> > Of course for any other link, the content can also change at any time.
> > Wikipedia solves that by adding to each link something like "retrieved on
> > XXXX-XX-XX" so that you have at least a timestamp. IANA registration could
> > at least include a timestamp (when the extension was registered)
> >
> > PS2: seeing that all of the above come from the fact that we are basically
> > trying to reinvent XML namespaces but in JSON... and arriving at the situation
> > where we get all the drawbacks without any strong advantage, at least not
> > until things are clearer/stricter.
> >
> > --
> >   Patrick Mevzek
> >   pm@dotandco.com
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext