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

[Ted Hardie <[e-mail]>]

Hi Roy,

Some additional thoughts in-line.

On Wed, Apr 19, 2023 at 7:25 PM Roy T. Fielding <[e-mail]> wrote:

> Hi Ted,
>
> I've always believed that such processes are describing the technical
> review of
> registered names rather than matter-of-fact social review. I would expect
> things
> like libel, profanity, racism, or cooption of existing names to be blocked
> somewhere
> regardless of the RFC.  By blocked somewhere, I mean we should have a
> general
> mechanism for quickly approving/denying questionable entries even if
> "provisional"
> is  supposed to be an easy path for technical questions.
>
>
>From one perspective, the provisional registry exists to document schemes
that are in use or are expected to be encountered in the wild; that's why
there is a 3rd party registration option.  So the shift to FCFS was really
to help ensure that the registry was complete, no matter how the URI scheme
came to be minted.  That said, there is a mechanism to object, in Section
7.1:

   The IANA policy (using terms defined in [RFC5226
<https://www.rfc-editor.org/rfc/rfc5226>]) for 'provisional'
   registration was formerly Expert Review; this document changes the
   policy to First Come First Served.  The policy for 'permanent' and
   'historical' registration continues to be Expert Review.

   The registration procedure is intended to be very lightweight for
   noncontentious registrations.  For the most part, we expect the good
   sense of submitters and reviewers, guided by these procedures, to
   achieve an acceptable and useful consensus for the community.

   In exceptional cases, where the negotiating parties cannot form a
   consensus, the final arbiter of any contested registration shall be
   the IESG.

Given that web3 was already registered, I don't personally see that dhttp
is over the line that has already been set, but you can go to the IESG with
your concerns and ask for a review.  My question to you and the IESG would
then be: is this going to be encountered in the wild?  If so, I would
suggest that it be included, even if it might be distasteful to do so.
Hiding it in the registry won't stop anyone from minting or using it, as we
have seen multiple times in the past.

Again, just my opinion.

regards,

Ted



> I don't believe {short-prefix}{ietf-standard} should ever be allowed as a
> provisional registration unless the owner is IETF.  That should be assumed
> of
> any IANA registry.  I don't think we need an RFC to state that
> "https-sucks"
> does not belong in the provisional registry, for the same reason.
>
> ....Roy
>
>
> On Apr 19, 2023, at 2:18 AM, Ted Hardie <[e-mail]> wrote:
>
> Hi Roy,
>
> The current list of requirements for provisionals is in RFC 7595, Section
> 4:
>
> The scheme name must meet the syntactic requirements of  Section 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 to other 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
>
>
>