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

["Martin J. Dürst" <[e-mail]>]

Hello everybody,

On substance, I agree with Roy.

On procedure, what about the following:

We register this scheme as provisional, but only after telling the 
proposer to reconsider because of the confusion and 
misuse/misunderstanding potential of the scheme name significantly 
reduce the chance for a permanent registration. Maybe we should even 
attach a comment to that effect to the template, or to the description 
column in https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 
(I note there's already a footnote at 
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#note1).

Regards,   Martin.


On 2023-04-20 17:56, Ted Hardie wrote:
> 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
>>
>>
>>
> 
> 
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan