Re: Request for well-known URI: ecips

Wei Tang <> Mon, 08 April 2019 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9E84120640 for <>; Sun, 7 Apr 2019 18:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nt18n3PzlHMM for <>; Sun, 7 Apr 2019 18:36:38 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:171:270b::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12B941203A2 for <>; Sun, 7 Apr 2019 18:36:36 -0700 (PDT)
Received: from nicethoughts ( []) (Authenticated sender: sorpaas) by (Postfix) with ESMTPSA id E04CD15F223E; Mon, 8 Apr 2019 01:36:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1554687394; bh=7c1uRA/QKdV7vaPDDUXeQ069JlDFCdrY4y7CI5u5hI4=; h=References:From:To:Cc:Subject:In-reply-to:Date; b=UhoytBU2dKEwZxa9YsxwkB4uiUlRW2LUPHSZ+ES3uKEU4DgsxcDrRaevew14OihjR gzrtIinji9vQa+/W+vcxZxIi4iPtkZGAjUXimaNxyOZR+sejwmOL9VGoOCortgvXWu q9oZwICf1NhC6wym66M3ltksSPtE1VLWrIB+SNqA=
References: <> <>
User-agent: mu4e 1.0; emacs 26.1
From: Wei Tang <>
To: Mark Nottingham <>
Subject: Re: Request for well-known URI: ecips
In-reply-to: <>
Date: Mon, 08 Apr 2019 03:36:29 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Well-Known URI review list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Apr 2019 01:36:48 -0000

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
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 “”, 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 <> 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 <>
>> * Specification document(s):
>> -- Wei