Re: [Uri-review] URI scheme registration request - dchub

Eric Johnson <> Mon, 11 March 2013 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B5FD21F8EA0; Mon, 11 Mar 2013 11:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HxSuWSPfTSlz; Mon, 11 Mar 2013 11:48:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B19C221F8EAB; Mon, 11 Mar 2013 11:48:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.84,825,1355126400"; d="scan'208";a="57648801"
Received: from (HELO ([]) by with ESMTP; 11 Mar 2013 11:48:18 -0700
Received: from Eric-Johnsons-MacBook-Pro.local ( by ( with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 11 Mar 2013 11:48:17 -0700
Message-ID: <>
Date: Mon, 11 Mar 2013 11:48:21 -0700
From: Eric Johnson <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Graham Klyne <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Cc:, "" <>, Fredrik Ullner <>
Subject: Re: [Uri-review] URI scheme registration request - dchub
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2013 18:48:19 -0000

On 3/10/13 8:57 AM, Graham Klyne wrote:
> Also, an observation.  There's a lot of normative language in this 
> template, some of which is really about the protocol, which is not 
> common to see in URI scheme registrations (for example, under scheme 
> semantics and interoperability considerations).  While it's not 
> formally incorrect, I'd be inclined to put some of this discussion in 
> the protocol spec, or other specification document, and refer to it 
> from the registration template.  The usual role of a URI registration 
> template is to provide an overview and key information about a URI 
> scheme, supported by references to separate documentation.  Your 
> approach makes this an unusually long and complicated URI registration 
> form.
Realizing that a number of these items you probably added to respond to 
my comment, I think Graham makes a critical point.

My question was about defining how one maps the URI to the protocol, not 
about repeating the definition of the protocol.

For example, this line:

" The client SHOULD request a TCP connection to the specified user via 
the commands $CTM (ConnectToMe) or $RCM (ReverseConnectToMe) (or an 
equivalent command)."

... I would write differently. The normative statements in this document 
ought to be about the URI and its use, rather than being normative 
statements about the protocol. There are lots of ways to use URIs that 
have nothing to do with the actual protocol (path computations, display 
on web pages, entries in a caching table). So the above statement, if it 
appears anywhere, should be in the protocol document. For the URI 
document, you could write something like this instead:

"With this form of URI, the client wishing to retrieve a file ought to 
request a TCP connection to the specified user via the commands $CTM 
(ConnectToMe) or $RCM (ReverseConnectToMe)."

I appreciate that you added the text, because it clarifies the use. It 
is just the normative part that triggers concern, because URIs have many 

One other thought. For a permanent registration, I interpret the need 
for a permanent URL to the document implying more permanence than the 
URL for this draft shows. For example, rather than updating the document 
in place, each new revision should have a new URL.