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

Eric Johnson <eric@tibco.com> Thu, 21 February 2013 18:13 UTC

Return-Path: <eric@tibco.com>
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 028B721F8F2B for <uri-review@ietfa.amsl.com>; Thu, 21 Feb 2013 10:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix65hau06nUT for <uri-review@ietfa.amsl.com>; Thu, 21 Feb 2013 10:13:24 -0800 (PST)
Received: from mx2-app.tibco.com (mx2-app.tibco.com [63.100.100.143]) by ietfa.amsl.com (Postfix) with ESMTP id C580321F8E79 for <uri-review@ietf.org>; Thu, 21 Feb 2013 10:13:23 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,710,1355126400"; d="scan'208";a="55678580"
Received: from tibco-5.tibco.com (HELO PA-CASHUB01.na.tibco.com) ([63.100.100.5]) by mx2-app.tibco.com with ESMTP; 21 Feb 2013 10:13:08 -0800
Received: from Eric-Johnsons-MacBook-Pro.local (10.105.164.22) by PA-CASHUB01.na.tibco.com (10.106.137.46) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 21 Feb 2013 10:13:06 -0800
Message-ID: <512663B2.20809@tibco.com>
Date: Thu, 21 Feb 2013 10:13:06 -0800
From: Eric Johnson <eric@tibco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Fredrik Ullner <ullner@gmail.com>
References: <CAOd=0fOPCgEwPWxOm3QDn=QKe8Rb8RmShn5sEL3iBS_z6aOUXg@mail.gmail.com>
In-Reply-To: <CAOd=0fOPCgEwPWxOm3QDn=QKe8Rb8RmShn5sEL3iBS_z6aOUXg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.105.164.22]
Cc: uri-review@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: Thu, 21 Feb 2013 18:13:25 -0000

Am I missing something here? I'm not one to typically comment on these, 
but I was unaware of the NMDC protocol. So I'm glad to see this attempt 
to register, which will raise awareness of the protocol. However, the 
proposed URI scheme registration document utterly confuses me.

The syntax section:

  * discusses semantics. For example: "The client should download the
    user's file list if path is omitted".
  * doesn't actually reference the syntax components of RFC 3986. It
    doesn't explicitly exclude possible portions of the syntax, such as
    fragment identifiers and queries. Am I to assume that those are
    allowed, but not specified in their use, or disallowed?
  * seems to allow "dchub://" as a valid URI, however, if I follow RFC
    3986 properly, that is not a valid URI, and at least a "host" is
    required.
  * Is RFC 3986 "userinfo" allowed in the URI? If so, how does that
    interact with the protocol?


The semantics section:

  * should steal the portions from the syntax section that address the
    meaning of a particular form, and further ought to tie that to
    specific portions of the spec. As in "download the user's file list"
    - which NMDC messages does this correspond to?
  * doesn't discuss at all how one might compare two of these URIs. Is
    the user name case-sensitive? If characters occur that require
    encoding via %xx, should those be normalized first before comparison?
  * Since the URI contains a path, does the path need to be normalized
    before comparison?

Under the "use" section:

  * An interoperability point is raised here that should be in the
    "interoperability" section.

The "interoperability" section:

  * What about case-sensitivity of the individual parts?
  * The use section flags interoperability considerations that aren't
    flagged here.
  *

The security section:

  * Future implementations may care about using TLS to secure
    communications. Will that need the use of "dchubs://", or is the
    intent that the "dchub:" scheme can serve both purposes?
  * Might one want to actually include some sort of indicator (such as a
    hash) in the URI (as part of a query) so that a client can request a
    file, and if the user or path has changed, and now points to a
    completely different file, that the provider and consumer of said
    URI will be able to detect the discrepancy?
  * What of using weird constructs like "../../../foo/bar", as in
    "dc-hub://host/myname/../../../foo" - does this need to make sure
    that cannot be used to retrieve a file that wasn't shared, or wasn't
    intended to be shared with the specific user.
  * DOS attacks, or DDOS attacks?
  * Homographs?
  * ...

The references section

  * doesn't actually include a formal reference to the specification of
    the protocol, which appears to be
    http://nmdc.sourceforge.net/Versions/NMDC-1.1.html


The protocol itself ought to be filed as an RFC. That would pretty much 
guarantee permanence of the reference.

Just my 2 cents.

Eric.

On 2/20/13 12:26 PM, Fredrik Ullner wrote:
> Hi,
>
> This is a request for registration of an URI scheme, dchub. The scheme 
> can be viewed at <http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>;.
>
> The URI scheme should meet the necessary requirements for a Permanent 
> URI scheme, as indicating in RFC 4395. The scheme specifies encoding, 
> interoperability and security aspects (and more). If the scheme should 
> not provide enough information for a Permanent scheme, please specify 
> what is lacking or at least consider a Provisional request instead.
>
> -- 
> Fredrik Ullner
>
>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review