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

Graham Klyne <GK@ninebynine.org> Sun, 10 March 2013 16:03 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 9B81321F8615; Sun, 10 Mar 2013 09:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 9Io-+4AHNU5r; Sun, 10 Mar 2013 09:03:05 -0700 (PDT)
Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id EAD4C21F85F5; Sun, 10 Mar 2013 09:03:04 -0700 (PDT)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1UEiiF-0005vG-bc; Sun, 10 Mar 2013 16:03:03 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1UEiiF-0008J1-0z; Sun, 10 Mar 2013 16:03:03 +0000
Message-ID: <513CAD82.409@ninebynine.org>
Date: Sun, 10 Mar 2013 15:57:54 +0000
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>
In-Reply-To: <CAOd=0fMyEVHgQnzZpoH3wXws+T30V5O82u13nFwA+A=4FwQbnQ@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: Sun, 10 Mar 2013 16:03:05 -0000

I took a quick scan through the URI registration, and two points occurred to me.


On 09/03/2013 18:20, Fredrik Ullner wrote:
> A new version of the NMDC document is now available at <
> http://nmdc.sourceforge.net/Versions/NMDC-1.3.html>;. Note that the
> versioning is the document's version, not the protocol, of which hasn't
> changed in quite some time. There is also a new version of the URI scheme
> available at<http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>;.

1. (nit):  nmdcs is not immediately recognizable as something like "secure 
dchub".  Is there any reason to use this name rather than, say, 'dchubs'. 
(Deployed systems would be a good reason.)

2. "Userinfo, queries, fragments (and more), as specified by RFC 3986, is 
discouraged and SHOULD NOT be used."

With regard to fragment identifiers, I think it's not for the URI spec to 
require non-use.  When a URI used by a client (e.g. dereferenced), the fragment 
is stripped off and not sent to the server.  The client may then interpret the 
fragment in light of what media type is returned from the server.  SO, if the 
dchub protocol is used to retrieve an HTML document, the fragment identifier may 
be used to control the disposition opf thgat document in the same way that it 
would be used for a HTML document retrieved using HTTP.

Here, I think non-use of userinfo and queries is covered by the syntax given, so 
this statement could be dropped.  If you choose to keep this sentence, I think 
the bit that says that fragments SHOULD NOT be used should be removed.

...

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.

I'm not saying here that it necessarily needs to be changed, but trying to give 
you a sense of how many specifications approach URI registrations.

#g
--