[Uri-review] [IANA #1271079] Re: Registration of dhttp Schema name (uri-schemes)

Amanda Baber via RT <iana-issues@iana.org> Wed, 24 May 2023 21:27 UTC

Return-Path: <iana-shared@icann.org>
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 04964C151B16 for <uri-review@ietfa.amsl.com>; Wed, 24 May 2023 14:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level:
X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 J6a2H-RxF9MR for <uri-review@ietfa.amsl.com>; Wed, 24 May 2023 14:27:31 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84037C151B1D for <uri-review@ietf.org>; Wed, 24 May 2023 14:26:46 -0700 (PDT)
Received: from request6.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 5E3E9E65F9; Wed, 24 May 2023 21:26:45 +0000 (UTC)
Received: by request6.lax.icann.org (Postfix, from userid 48) id 468C44AF59; Wed, 24 May 2023 21:26:45 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <iana-issues@iana.org>
Reply-To: iana-issues@iana.org
In-Reply-To: <rt-5.0.3-141872-1684932308-1083.1271079-37-0@icann.org>
References: <RT-Ticket-1271079@icann.org> <RT-Ticket-1270959@icann.org> <CAEp-PA_SGScCnxZjpFszTPR+uR==R2gjNV-QoBLiWHok7fvXWA@mail.gmail.com> <rt-5.0.3-126466-1681773256-807.1270959-37-0@icann.org> <24115C2D-8C2F-45D5-BB80-C30F653C019B@gbiv.com> <CA+9kkMAOiVqt5Ywr5ZpL1vNWZDQrraW+2E__ZzWJS6NVuc1rPw@mail.gmail.com> <1f06aca4-5aa1-a04c-6345-8f0b6895e95b@ninebynine.org> <rt-5.0.3-1407111-1682700344-1287.1271079-37-0@icann.org> <07ace9e7-cd2b-2cf2-f0b1-5d7cdc69271b@ninebynine.org> <rt-5.0.3-141872-1684932308-1083.1271079-37-0@icann.org>
Message-ID: <rt-5.0.3-173097-1684963605-301.1271079-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1271079
X-Managed-BY: RT 5.0.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
To: GK@ninebynine.org, duerst@it.aoyama.ac.jp, fielding@gbiv.com, melvincarvalho@gmail.com, ted.ietf@gmail.com
CC: superuser@gmail.com, uri-review@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Wed, 24 May 2023 21:26:45 +0000
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/ZpRnRccMAhFIr7pW1YBJvdQoop4>
Subject: [Uri-review] [IANA #1271079] Re: Registration of dhttp Schema name (uri-schemes)
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 24 May 2023 21:27:36 -0000

Hi Graham,

We've added the note below to the "dhttp" entry's "Notes" field:

https://www.iana.org/assignments/uri-schemes

Best regards,

Amanda Baber
IANA Operations Manager

On Wed May 24 12:45:08 2023, GK@ninebynine.org wrote:
> Hi Sabrina,
> 
> The public discussion on this appears to have run its, course, so I'd
> like to
> now request that the note below be added the the URI scheme registry
> entry for
> 'dhttp'.
> 
> Thank you,
> 
> Graham.
> 
> 
> ## IANA reviewer note
> 
> This scheme has been provisionally registered under the “first come
> first
> served” policy set out in RFC 7595.  This means that the scheme has
> not been
> formally reviewed in the IETF, and is not recommended by the IETF for
> general
> use on the open Internet.
> 
> Further, the `dhttp` scheme is considered harmful by some in the IETF
> [R1] for
> at least the following reasons:
> 
> 1. it creates confusion by associating with the existing "http" and
> "https"
> schemes of HTTP, even though the described protocol does not use HTTP.
> This
> could be an issue for applications that use the prefix "http://" and
> "https://"
> to identify links within text without parsing the surrounding context.
> 
> 2. ‘dhttp’ is defined to be an alias of the provisionally registered
> ‘web3’
> scheme, and URI aliases are, in general, considered harmful to the
> World Wide
> Web [R2].
> 
> 3. Using the name ‘dhttp’ appears to be an attempt to legitimise web3
> [R3] by
> association with HTTP (the current World Wide Web’s primary
> interaction protocol).
> 
> This note is intended to draw attention to potential problems that
> might arise
> if this scheme were to be used widely on the open Internet, and does
> not itself
> constitute a position by the IETF or IANA on the considerations
> raised.
> 
> [R1] https://mailarchive.ietf.org/arch/msg/uri-
> review/4Sj8k6rLZzqZsGgMEe6fLM-wE4U/
> 
> [R2] https://www.w3.org/TR/webarch/#uri-aliases
> 
> [R3] https://en.wikipedia.org/wiki/Web3
> 
> 
> 
> On 28/04/2023 17:45, Sabrina Tanamal via RT wrote:
> > Hi Graham,
> >
> > Just following up on this thread. Are there any actions required from
> > IANA?
> >
> > Thanks,
> >
> > Sabrina Tanamal
> > Lead IANA Services Specialist
> >
> > On Thu Apr 20 10:34:36 2023, GK@ninebynine.org wrote:
> >> I see two possible ways forward:
> >>
> >> 1. There is an "escape hatch" clause in the registration procedure
> >> that allows
> >> the IESG to be final arbiter of any contentious registration.
> >>
> >> 2. As scheme reviewer, I can request a note be added to the registry
> >> entry
> >> pointing out that the scheme is contentious, the reasons why, and as
> >> such is NOT
> >> RECOMMENDED for use on the open Internet.  I would be reluctant to
> >> do
> >> so on my
> >> opinion alone, but I'm seeing sufficient concern expressed here for
> >> that to be a
> >> reasonable request.
> >>
> >> Personally, I think the latter is preferable, for reasons that Ted
> >> mentions in a
> >> later email.  There are a number of provisionally registered schemes
> >> that got
> >> snuck in un-noticed before we set up the process of sending
> >> notifications of
> >> provisional registrations to this list (following the last London
> >> IETF
> >> meeting),
> >> and I'd be inclined to request a similar note be added to the 'web3'
> >> scheme.
> >>
> >> #g
> >>
> >>
> >> On 19/04/2023 10:18, Ted Hardie wrote:
> >>> Hi Roy,
> >>>
> >>> The current list of requirements for provisionals is in RFC 7595,
> >>> Section 4:
> >>>
> >>> The scheme name must meet the syntactic requirements ofSection 3.8.
> >>>
> >>>    o  There must not already be an entry with the same scheme name.
> >>> In
> >>>       the unfortunate case that there are multiple, different uses
> >>> of
> >>>       the same scheme name, the Designated Expert can approve a
> >>> request
> >>>       to modify an existing entry to note the separate use.
> >>>
> >>>    o  Contact information identifying the person supplying the
> >>>       registration must be included.  Previously unregistered
> >>> schemes
> >>>       discovered in use can be registered by third parties (even if
> >>> not
> >>>       on behalf of those who created the scheme).  In this case,
> >>> both
> >>>       the registering party and the scheme creator SHOULD be
> >>> identified.
> >>>
> >>>    o  If no permanent, citable specification for the scheme
> >>> definition
> >>>       is included, credible reasons for not providing it SHOULD be
> >>>       given.
> >>>
> >>>    o  The scheme definition SHOULD include clear security
> >>> considerations
> >>>       (Section 3.7) or explain why a full security analysis is not
> >>>       available (e.g., in a third-party scheme registration).
> >>>
> >>>    o  If the scheme definition does not meet the guidelines laid
> >>> out
> >>> in
> >>>       Section 3, the differences and reasons SHOULD be noted.
> >>>
> >>> While it may be the case that using 'dhttp' implies something to
> >>> humans about
> >>> the relationship toother schemes, it meets the current test that
> >>> "there must
> >>> not already be an entry with the same scheme name".  As you will no
> >>> doubt
> >>> recall, we loosened the registration of provisionals in this way
> >>> because folks
> >>> were minting URI schemes without registration and the risk of
> >>> collision was
> >>> getting worse as a result.
> >>>
> >>> I am not as clear, though, about whether this registration is
> >>> intended to
> >>> deprecate web3 (which is also a provisionally registered URI
> >>> scheme)
> >>> so that
> >>> web3 could be marked historic.  If that is the case, we could at
> >>> least
> >>> eliminate the alias scheme issue which you note below.
> >>>
> >>> Just my personal opinion, of course,
> >>>
> >>> Ted
> >>>
> >>> On Tue, Apr 18, 2023 at 4:45 PM Roy T. Fielding <fielding@gbiv.com>
> >>> wrote:
> >>>> Is there a way that we can block provisional registrations that
> >>>> are
> >>>> actively
> >>> harmful?
> >>>>   1) this is abusing the existing http and https schemes;
> >>>>   2) alias schemes are harmful, in general; and,
> >>>>   3) web3 is a scam that we shouldn't make respectable by
> >>>> association with HTTP.
> >>>>
> >>>> .....Roy
> >>>>
> >>>>
> >>>>> On Apr 17, 2023, at 4:14 PM, Sabrina Tanamal via RT
> >>> <iana-prot-param@iana.org> wrote:
> >>>>> Hi Qi,
> >>>>>
> >>>>> We've added provisional URI scheme dhttp to the registry:
> >>>>>
> >>>>> https://www.iana.org/assignments/uri-schemes/prov/dhttp
> >>>>>
> >>>>> Registry: https://www.iana.org/assignments/uri-schemes
> >>>>>
> >>>>> Per the designated expert for URI Schemes registry, we're also
> >>>>> notifying
> >>> the uri-review@ietf.org mailing list upon completing a provisional
> >>> registration.
> >>>>> Best regards,
> >>>>>
> >>>>> Sabrina Tanamal
> >>>>> Lead IANA Services Specialist
> >>>>>
> >>>>> On Mon Apr 17 03:05:35 2023, qizhou@web3q.io wrote:
> >>>>>> Hi Amanda,
> >>>>>>
> >>>>>> We would like to register dhttp:// schema with the following
> >>>>>> information
> >>>>>>
> >>>>>> Schema name: dhttp
> >>>>>>
> >>>>>> Status: Provisional
> >>>>>>
> >>>>>> Applications/protocols that use this scheme:
> >>>>>>
> >>>>>> This schema dhttp:// is the alias of schema web3://
> >>>>>>
> >>>>>> Contact:
> >>>>>>
> >>>>>> Qi Zhou
> >>>>>> 55 E 3rd Ave, San Mateo, CA 94401
> >>>>>> mailto: qizhou@web3q.io
> >>>>>>
> >>>>>> Change controller:
> >>>>>>
> >>>>>> Qi Zhou
> >>>>>> 55 E 3rd Ave, San Mateo, CA 94401
> >>>>>> mailto: qizhou@web3q.io
> >>>>>>
> >>>>>> References:
> >>>>>>
> >>>>>> A draft specification can be found at
> >>>>>> https://eips.ethereum.org/EIPS/eip-4804 (replacing web3:// with
> >>>>>> dhttp://)
> >>>>>>
> >>>>>> Scheme syntax:
> >>>>>>
> >>>>>> "dhttp://" [userinfo "@"] contractName [":" chainid] path ["?"
> >>>>>> query]
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> - Qi
> >>>>> _______________________________________________
> >>>>> Uri-review mailing list
> >>>>> Uri-review@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/uri-review
> >>>>>
> >>>> _______________________________________________
> >>>> Uri-review mailing list
> >>>> Uri-review@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/uri-review
> >>> _______________________________________________
> >>> Uri-review mailing list
> >>> Uri-review@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/uri-review