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

[Melvin Carvalho <[e-mail]>]

so 29. 4. 2023 v 18:36 odesílatel Graham Klyne <[e-mail]> napsal:

> Hi Sabrina,
>
> Thanks for the reminder.  No immediate action for IANA yet, but please
> send a reminder in a couple of weeks or so if you haven’t heard further.
>
> I was initially waiting to see if there was any response to my vague
> suggestions.  Hearing no objections, I think the next step is for me to
> draft a comment to be added to the provisional registrations noted,
> circulate it to this uri-review list for comment, and, if no objection,
> send a request to you under this ticket to add notes to those registry
> entries.
>
> I’m travelling at the moment, so  probably won’t be in a position to
> action this for a week or so.  But if nothing heard from me (or anyone else
> who may offer a proposal) in a couple of weeks, please nudge me again.
>

I recently encountered a situation where I was attempting to publish a new
JavaScript library to the NPM registry. The library I created deals with
two similar encodings: bech32 and bech32m. As there was no existing
implementation of bech32m in JavaScript, I decided to write one.

Upon attempting to upload the package, I received the following error
message:

403 Forbidden - PUT https://registry.npmjs.org/bech32m - Package name too
similar to existing package bech32; try renaming your package to
'@melvincarvalho/bech32m'

I dont know the npm algorithm but I suspect it is something simple and
practical.

In the case of similar names or "affinity registrations", they could be
reviewed manually, with common sense, until a good algorithm comes along.


>
> Thanks,
>
> #g
>
>
> Sent from my iPhone
>
> > On 28 Apr 2023, at 17:45, Sabrina Tanamal via RT <[e-mail]>
> 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, [e-mail] 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 <[e-mail]>
> >>> 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
> >>> <[e-mail]> 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 [e-mail] mailing list upon completing a provisional
> >>> registration.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Sabrina Tanamal
> >>>>> Lead IANA Services Specialist
> >>>>>
> >>>>> On Mon Apr 17 03:05:35 2023, [e-mail] 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: [e-mail]
> >>>>>>
> >>>>>> Change controller:
> >>>>>>
> >>>>>> Qi Zhou
> >>>>>> 55 E 3rd Ave, San Mateo, CA 94401
> >>>>>> mailto: [e-mail]
> >>>>>>
> >>>>>> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/uri-review
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Uri-review mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/uri-review
> >>>
> >>> _______________________________________________
> >>> Uri-review mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/uri-review
> >
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>