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

Graham Klyne <GK@ninebynine.org> Wed, 16 October 2013 09:11 UTC

Return-Path: <GK@ninebynine.org>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721B511E82A5; Wed, 16 Oct 2013 02:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.16
X-Spam-Level:
X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCEsYEhZxrW6; Wed, 16 Oct 2013 02:11:02 -0700 (PDT)
Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6DD21F9D17; Wed, 16 Oct 2013 02:10:57 -0700 (PDT)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1VWN80-0008DM-dw; Wed, 16 Oct 2013 10:10:52 +0100
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1VWN7z-0007G8-6P; Wed, 16 Oct 2013 10:10:52 +0100
Message-ID: <525E5749.4010504@ninebynine.org>
Date: Wed, 16 Oct 2013 10:07:21 +0100
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Fredrik Ullner <ullner@gmail.com>
References: <CAOd=0fOPCgEwPWxOm3QDn=QKe8Rb8RmShn5sEL3iBS_z6aOUXg@mail.gmail.com> <512663B2.20809@tibco.com> <CAOd=0fPuFsoTCh0mcYt_vVi-=Y5Or4oNQT+BYpKZv1zop0vdHA@mail.gmail.com> <51278B10.10200@ninebynine.org> <CAOd=0fMyEVHgQnzZpoH3wXws+T30V5O82u13nFwA+A=4FwQbnQ@mail.gmail.com> <513CAD82.409@ninebynine.org> <513E26F5.9080207@tibco.com> <CAOd=0fNA3OFG0_AH1ga8auUUrs7PbxGq1srGxZiox1NWGwO8eg@mail.gmail.com> <CAOd=0fPV3d=xBt_BH4vsG5aN5rNqjbAAzrdvxFnzFPXv_xbQag@mail.gmail.com> <CAOd=0fP4tEBaLsBX3AUgpxr8oKq+msUntYu-dBs=atESRkbyMQ@mail.gmail.com>
In-Reply-To: <CAOd=0fP4tEBaLsBX3AUgpxr8oKq+msUntYu-dBs=atESRkbyMQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: uri-review@ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [Uri-review] URI scheme registration request - dchub
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 09:11:08 -0000

I think I've made a similar comment previously (some time ago, my memory fades), 
but for someone (me) who does not know about "dchub" the template isn't very 
informative.  There is mention of Neo-Modus Direct Connect (NMDC) client clients 
and NMDC protocol, but it's not clear where these are described.

I would also find it helpful if it were clear what a dchub: URI actually 
identifies - is it dereferencable?  What kind of resource is returned when it is 
dereferenced?  (One of the reference names suggests file sharing, so the 
resource accessed would be a file?)

It feels to me as if there is both too much and too little protocol information 
in the URI template.  (e.g. "A Neo-Modus Direct Connect (NMDC) client, given an 
URL, ought to connect to the specified address with the appropriate protocol 
commands and sequence.")  Far better, in my option, would be to provide a clear 
reference to the protocol specification and then describe the URI scheme through 
reference to that.  Example: "A dchub: URI identifies a file resource that may 
be accessed using the NMDC protocol [@@ref]".

Then add some indication of the operations that are possible using a dchub: URI.


Under "encoding considerations, there are some considerations that I think are 
really interoperability considerations (e.g. "but MAY be case-insensitive in 
hubs that mandate as such.").  I think that should be: "Some hubs may treat 
dchub: URIs that differ only in case of the user component as identifying the 
same resource" (as an interop consideration).

A key point here is that the string comparison should make it clear when two 
URIs may be regarded as the same URI, which I think is when they compare (case 
sensitive) as equal strings after RFC3986 syntax normalization.

(Note: comparing equal is not necessarily the same as identifying the same 
resource.)

Based on my brief reading of the wikipedia page, I'd like to see something like 
the following included:

[[
The Direct Connect is a peer-to-peer file sharing protocol used by Neo-Modus 
Direct Connect (NMDC) clients, and reversed engineered for use in a number of 
other systems.  There is no definitive publicly available specification, but the 
[Wikipedia page] contains a general description.
]]

#g
--



On 13/10/2013 21:18, Fredrik Ullner wrote:
> Hi,
>
> Sorry, but I'm not sure if the previous link was correctly pointing to the
> 0.4 version, but here it is: <
> http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt> (I blame
> Gmail)
>
>
> On Sun, Oct 13, 2013 at 9:18 PM, Fredrik Ullner <ullner@gmail.com>; wrote:
>
>> Hi,
>>
>> There is now a new version of the dchub URI scheme proposal at <
>> http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt<http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.3.txt>>;.
>> The following changes have been made:
>>
>> * The "Applications/protocols" section revamped to be more generic, so it
>> doesn't have to specify each implementation.
>> * Changed from Permanent to Provisional; this is to make sure that the
>> scheme will be accepted as a first step (possibly later filing a permanent
>> one, if people find that the scheme provides ample information to deem it
>> worthy of permanent status).
>>
>> For other (minor changes), please see the SVN.
>>
>> If people are satisfied with the current scheme specification, I will
>> proceed to submit it to the appropriate IETF list.
>>
>>
>> --
>> Fredrik Ullner
>>
>
>
>