Re: Request for well-known URI: ecips

[Mark Nottingham <[e-mail]>]

Hi Wei,

I agree that it's unlikely to be used as a generic term, and since you have some deployment let's stick with ecips (we'd probably be having a different discussion if you were requesting a three- or four-character string).

IANA,

Please register the request template below in the Well-Known URIs registry.

Cheers,



> On 8 Apr 2019, at 11:36 am, Wei Tang <[e-mail]> wrote:
> 
> Hi Mark,
> 
> I want to argue that the name "ecips" is precise enough. The new
> RFC5785bis really didn't say anything about requested names cannot be
> too short.
> 
>> Registered names for a specific application SHOULD be correspondingly
>> precise; “squatting” on generic terms is not encouraged.
> 
> I do hope we can use the name "ecips" as is because there're already
> aggregators (like this https://github.com/tzdybal/hunter-gatherer)
> written based on it. However, if you think this is really not okay, I'm
> open to consider changing it.
> 
> -- Wei
> 
> Mark Nottingham writes:
> 
>> Hello Wei,
>> 
>> Apologies for the delay; I was waiting for RFC5785 to be approved before moving forward on some registrations.
>> 
>> From RFC5785bis:
>> 
>>> Registered names for a specific application SHOULD be correspondingly precise; “squatting” on generic terms is not encouraged. For example, if the Example application wants a well-known location for metadata, an appropriate registered name might be “example-metadata” or even “example.com-metadata”, not “metadata”.
>> 
>> Your requested name is not a common word, but it is a bit short. Would you consider using a longer name (e.g., "ethereum-classic-ip") to assure that it's specific enough?
>> 
>> Regards,
>> 
>> 
>>> On 8 Mar 2019, at 6:34 am, Wei Tang <[e-mail]> wrote:
>>> 
>>> Signed PGP part
>>> 
>>> Hi all,
>>> 
>>> We're working on a solution to make a specification repository (called
>>> Ethereum Classic Improvement Proposals) more decentralized, as this is
>>> one of the thing that is often requested by our community. Our current
>>> draft is based on federation -- basically by allowing an aggregator to
>>> build up a list of repositories, and then fetch specification
>>> information from a well known URI. We didn't use solutions like
>>> ActivityPub because upgrading to it from the current structure is
>>> complicated, and we don't need the majority of its features.
>>> 
>>> We need the well known URI both because we need to attest the
>>> "authoritiveness" of the specification (it needs to have a single source
>>> of truth in one particular repository), and also because for an
>>> aggregator, fetching a repository with thousands of specifications by
>>> individual URI would be too inefficient.
>>> 
>>> * URI suffix: ecips
>>> * Change controller: Wei Tang <[e-mail]>
>>> * Specification document(s): https://ecips.that.world/24-ECIPURI
>>> 
>>> -- Wei

--
Mark Nottingham   https://www.mnot.net/