Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
Jonathan A Rees <rees@mumble.net> Wed, 06 June 2012 20:33 UTC
Return-Path: <jonathan.rees@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF4021F8673 for <ietf@ietfa.amsl.com>; Wed, 6 Jun 2012 13:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 vct0Dy2GRPdX for <ietf@ietfa.amsl.com>; Wed, 6 Jun 2012 13:33:40 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E40CB21F8589 for <ietf@ietf.org>; Wed, 6 Jun 2012 13:33:37 -0700 (PDT)
Received: by dacx6 with SMTP id x6so9164308dac.31 for <ietf@ietf.org>; Wed, 06 Jun 2012 13:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cmawBQPPg2p2HLTCFl0N7BdsXX6V12ONx8I1a/fiJWk=; b=bupL4+YWADyNwCedhB2pZNRn7j4QF0INL72rIWEBf/nSRCoaGHWZ/lXvL42lOaisT/ I6/VFfMZ7YTX1U0BHeMY36b/QemUUkh/Bh9n1y/vEwIY0HikJwCQPwWZcw8/yGiKQTzM YHJBvja7sphIQoqlQzQiah/1NhcAHa/jStiuq7LizIvCH7rO0A9yEwfo4krfiuMY2jQ1 6Jle7qxxiCQ40zOY1iuznO/OhqeOLE9YwugAdv10TAc10tSZcS+wxhe6wFyz6NPiGYw/ QPrSPboRpY1Ty4xcdAGD9+ja6fTlb4ZbWd8WyopRGSjtjEARceJDOB7GCOXS3tr2+sd3 Pdyw==
MIME-Version: 1.0
Received: by 10.68.216.2 with SMTP id om2mr776781pbc.26.1339014816795; Wed, 06 Jun 2012 13:33:36 -0700 (PDT)
Sender: jonathan.rees@gmail.com
Received: by 10.143.5.7 with HTTP; Wed, 6 Jun 2012 13:33:36 -0700 (PDT)
In-Reply-To: <E33E01DFD5BEA24B9F3F18671078951F23A88B0C@szxeml534-mbx.china.huawei.com>
References: <E33E01DFD5BEA24B9F3F18671078951F23A88B0C@szxeml534-mbx.china.huawei.com>
Date: Wed, 06 Jun 2012 16:33:36 -0400
X-Google-Sender-Auth: kKalcCONY0IoUFYr8ZxfQActrvw
Message-ID: <CAGnGFMKjv2QR+ebynnC2GktpYf2QEx73n+0_ZZeyJrAmTYDnjg@mail.gmail.com>
Subject: Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
From: Jonathan A Rees <rees@mumble.net>
To: ietf@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 07 Jun 2012 08:39:27 -0700
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2012 20:33:42 -0000
As requested I am sending comments on this last call draft to ietf@ietf.org. I sent them to the authors on 6 May but received no reply. Jonathan Rees ---------- Forwarded message ---------- From: Jonathan A Rees <rees@mumble.net> Date: Sun, May 6, 2012 at 7:57 PM Subject: comments on http://tools.ietf.org/html/draft-farrell-decade-ni-06 To: Alexey Melnikov <alexey.melnikov@isode.com>, Barry Leiba <barryleiba@computer.org>, "S. Farrell" <stephen.farrell@cs.tcd.ie>, "P. Hallam-Baker" <pbaker@verisign.com> Here are some opinions on http://tools.ietf.org/html/draft-farrell-decade-ni-06 : I think this URI scheme would be a welcome addition to web architecture. Wide review should be sought, because this might become quite important and if there are problems they will be very difficult to fix later. I think using .well-known is a good idea. I think integration into the ecosystem, such as browser support, should be anticipated; for this reason I think content type should be elevated from an 'optional feature' to a 'required feature'. [i.e. conformant implementations must support it, even if providing the content type in the URI is itself optional.] If you don't do this, you are just encouraging sniffing and privilege escalation attacks. Sniffing would be a big step backwards. Better to do what the data: scheme does and say that there is a default content type of, say, text/plain, and that otherwise the content type ought to be specified in the URI. Content-type privilege escalation risk (and incorrect sniffing risk) should be mentioned in the security considerations section in any case. Maybe the risk that the host used for retrieval might be spoofing the content-type (by providing a bogus content-type in an HTTP response) should also be mentioned. (A possible design would be to put the content-type (and maybe other headers like Expires:?) in the hashed content, to be pulled out into the HTTP response when the content is served by an http server and then checked by the client, but I understand that this would be a tooling headache.) (I don't understand why you want to separate the 'optional' features into a separate spec. This made me miss the ct= feature entirely at first.) I think the documentation should say that the hash and content type together identify the resource, and that because the content can be verified, the resource can be sought (using the .well-known path, or any other path for that matter) from any source that the client thinks might have it. The primary and alternate domain name(s), and 'wrapped' URLs, are only provided as hints. I agree with other commenters on the peculiarity of using // to provide the location hint since the named host is not being trusted as an authority. I don't understand why the 'primary' location isn't just encoded in the query, just like the alternate domain(s) and "wrapped URL(s)". This would have the nice property that you can put the identifying parts (i.e. hash and content type) first, and the less important location hints parts all together after the identification. The various location hints (whether primary or secondary) would go together and their similarity would be clearer. (Unless I'm misunderstanding something and the part after the // actually has status other than a hint? That would seem to defeat the purpose.) Jonathan
- Re: [decade] FW: Last Call: <draft-farrell-decade… Jonathan A Rees
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Martin Thomson
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Sam Hartman
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… hartmans
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… SM
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Jonathan A Rees
- Re: [decade] FW: Last Call: <draft-farrell-decade… Martin J. Dürst
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Martin J. Dürst
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Worley, Dale R (Dale)
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Stephen Farrell
- RE: Last Call: <draft-farrell-decade-ni-07.txt> (… Worley, Dale R (Dale)
- Re: [decade] FW: Last Call: <draft-farrell-decade… Martin J. Dürst
- Re: [decade] FW: Last Call: <draft-farrell-decade… Stephen Farrell
- Re: [decade] FW: Last Call: <draft-farrell-decade… Jonathan A Rees
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Stephen Farrell
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Martin J. Dürst
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Stephen Farrell
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Martin J. Dürst
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Stephen Farrell
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… SM
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Martin J. Dürst
- Re: Last Call: <draft-farrell-decade-ni-07.txt> (… Stephen Farrell
- RE: Last Call: <draft-farrell-decade-ni-07.txt> (… Dirk Kutscher