Re: [Uri-review] mt: scheme documentation (was: Matter "mt" URI permanent registration review request)

Ted Hardie <ted.ietf@gmail.com> Thu, 05 January 2023 09:39 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32EAC1524C1 for <uri-review@ietfa.amsl.com>; Thu, 5 Jan 2023 01:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HlhjswdJH9pi for <uri-review@ietfa.amsl.com>; Thu, 5 Jan 2023 01:39:02 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 36109C1524C0 for <uri-review@ietf.org>; Thu, 5 Jan 2023 01:39:02 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id j16so19558700edw.11 for <uri-review@ietf.org>; Thu, 05 Jan 2023 01:39:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j/R+Z8+cStTlUXxsy6fJAH5ntZb0mUlFlfWa9g690Ow=; b=VsySKihfmZ2hZHgtwbbGfUtKmTqqwGR0iHdJZzKvJGfC76PhV4SnI/qvlPRqALNMA0 OSEoyMjN7BiWv4gj3Ybb+A5V5sBCn3xkJQ3yTiBEy//EI6Ohtmcx34PeeQaaGJyBYekF TCsDzvQ9Z3phE62S6oFqVKbjNxoS94u7txxiQ26MDIvaFdGTl0epm4TAKJ44v6i6+LwP fdTQfvDC1LOP4m0OP2odrDG2kA/SCTdlSAU0vex6WQieYkSnaPBEp7kAgxeCBLAGEcnS R0vPbo+hcnjo7+ad6AE8e982q3kh4+1W3ODI/yxlDBx/Aw68iFsveLwePcXQrQmPHiXG KnBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j/R+Z8+cStTlUXxsy6fJAH5ntZb0mUlFlfWa9g690Ow=; b=tYbeiWLueSjbCS66KGcYQdIfc/Wrf/sp82caj2iYxxpwSDl2T0uPClYKhZG4ffKeBH ye7PvyaOPW1BYQ2jok6JJHazMP5qT9xNNdgwUdXCHSWbyzfpmKUGGXnKK3wilCOcBBZ6 NphIZP8yyT6y5pokZAirw+UDYkIO6IXm2OeHSTvaApQcHSHHvfcRh6umN3oMkm1hmgnL yhK2/g3YU0+cZLrt2POWv31XmGA+q698CMmDW2TW7MKh9Jqt/3aCyfy58L29YEYFhSoD +w5iY2FJEs3nsfn2QzChlfMdtjkK5vW/EYz6HIlM3cG0jaqznbRpKSKmWAXqx8HuXSmS IB9A==
X-Gm-Message-State: AFqh2ko+diuzq+JUn9BArJqF49Rwlk3R+ayS6Kgpj53pwO+HvFIrkE8v NH4A7EZ4szrnlEkd6MEhhChkTS2ti0PZgLGIo8A=
X-Google-Smtp-Source: AMrXdXu3geLg7Cy5tXA4/kcuqjTouKZXhaFe1L9F6PrdFdlvjkmUVJMYSAklM1/Tvqpmlh3VezNf2NhJznxET6GxynE=
X-Received: by 2002:a05:6402:2408:b0:47b:2514:f2e7 with SMTP id t8-20020a056402240800b0047b2514f2e7mr6169393eda.142.1672911540661; Thu, 05 Jan 2023 01:39:00 -0800 (PST)
MIME-Version: 1.0
References: <CA+XFNZ5T-JpiVoVr+FnBt1zqfBgjDqNKuPLcSBKigXyQE0pAZQ@mail.gmail.com> <D6BF5C49-793A-437F-B7EF-C6E54AE398CE@ninebynine.org> <CA+XFNZ4LyVe0rX1OOKwdjaqZTX8S6zfLYxA8uufjaitbaK4KLg@mail.gmail.com> <32bc7b67-8f3b-b21f-575d-2689aeba7b06@ninebynine.org> <CAL0qLwaQvANz6DU+1EMKVhF+diuy986XgTiSx4t=F=5eX6dVsA@mail.gmail.com> <3f55a517-dc72-ad9b-cec8-8425a9719e57@ninebynine.org>
In-Reply-To: <3f55a517-dc72-ad9b-cec8-8425a9719e57@ninebynine.org>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Thu, 05 Jan 2023 09:38:33 +0000
Message-ID: <CA+9kkMDm=Cng+4kyur1vmwy1+SAgj4JDjN6x2vKL6zGjE5pB4w@mail.gmail.com>
To: Graham Klyne <gk@ninebynine.org>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, Aron Rosenberg <arosenberg@logitech.com>, uri-review@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001f359a05f18112af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/5aOfd5TO2i8Qa3yYYX9oirXK4jw>
Subject: Re: [Uri-review] mt: scheme documentation (was: Matter "mt" URI permanent registration review request)
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2023 09:39:06 -0000

Hi Graham,

I've snipped most of this to comment on one particular matter, covered in a
couple of sections of your response:
<snip>
On Wed, Jan 4, 2023 at 6:18 PM Graham Klyne <gk@ninebynine.org> wrote:

>
>
>> The broad intention with any IETF technical specification is that there
>> is
>> sufficient information freely available to allow interoperable
>> implementations,
>> preferably between any two agents on the World Wide Web.  So what I'm
>> trying to
>> do here is interpret the explicit and implicit requirements in a way that
>> respects that intention.
>>
>
>> I agree with this as a statement of broad intention, but my reading of
the URI registration procedure history is that it has gone from a mechanism
with a fairly strong gatekeeping approach to one primarily focused on
ensuring that collisions do not occur.  The provisional registration
procedures are the primary signal for that, but even within permanent
registrations, I feel the same is true (witness the shift from "ietf" tree
to permanent).


<snip>
>
>

> OR (2) add a technical section to the registration template covering the
> above information.  This is probably the easier option, but it goes against
> the intent of the latest URI registration procedure, which was to defer all
> technical specifics a to a defining document.


 I don't disagree with this reading of the registration procedures, but I
feel the collision avoidance issue is even larger than the deferral to
external documents presumption.  That means that I personally would
support the inclusion of the relevant technical details in the template
if that turns out to be the easiest method to provide them to the IETF
and broader technical community.  The template could also include a
pointer to the broader matter specifications for those with the interest
 in getting the additional context, perhaps with a note that at the time
 of registration a EULA-style agreement was required to retrieve them.
But the key thing is that the registry would contain the scheme along
with sufficient information to identify the change controller and the
formal syntax; that's truly the *sine qua non* for me.

best regards,

Ted Hardie