IETF Logo Mail Archive

Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 12 June 2012 11:00 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8F7DA21F8628 for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 04:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.921
X-Spam-Level:
X-Spam-Status: No, score=-101.921 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 ykrmpYdxog52 for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 04:00:24 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id AB91B21F8627 for <ietf@ietf.org>; Tue, 12 Jun 2012 04:00:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BE34F171803; Tue, 12 Jun 2012 12:00:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339498822; bh=Nvi6yzA5ZhHeW0 dzNHc1KVG5T7PK4z1cioOAce9YiVY=; b=2EndkiqzdJsTUzBe6KqhK0mkMsGnIF 8iQl50mjlY+EZs0Jx6d3GWWyHT8CDGzujVelGqpQIqTKlOALfVTRcXjS1SmBtbiQ pUJHpm+3MJdPgfEkygf3RRLypaGDtHBrYdSggRS7lMCSioQeH/EzHhkPHcEPvcU3 3vi/678ZtjlYZmmQzQ3drMNPMO+8dIdmc7MEn7FhhfYpVdKK3lHcVfsQdiSxVxA4 rbXqsVh9egwU6SiHKp/80QwJ1DU71l11IUBsmlVKF/EF+PTX7KTRB1LLf5lo5T7n bUrCav6LeycG9tQQiVd3Vq01gpYTv1Ut1TdCVa4DDZS5CZayTMGNsOvg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ijoAdaldU+Ko; Tue, 12 Jun 2012 12:00:22 +0100 (IST)
Received: from [IPv6:2001:770:10:203:f0bb:fb89:d865:2639] (unknown [IPv6:2001:770:10:203:f0bb:fb89:d865:2639]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A81DB171800; Tue, 12 Jun 2012 12:00:17 +0100 (IST)
Message-ID: <4FD72141.9010201@cs.tcd.ie>
Date: Tue, 12 Jun 2012 12:00:17 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Subject: Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <E33E01DFD5BEA24B9F3F18671078951F23A88B0C@szxeml534-mbx.china.huawei.com> <CAGnGFMKjv2QR+ebynnC2GktpYf2QEx73n+0_ZZeyJrAmTYDnjg@mail.gmail.com> <CABkgnnVga6Dn5cVQA+AFzd=4LN9Y65YcJEwUiiwVJeSqg=mS0Q@mail.gmail.com> <4FD29389.5060900@cs.tcd.ie> <tslboktwbzv.fsf@mit.edu> <4FD2AAB3.4010305@cs.tcd.ie> <4FD71D6A.9070101@it.aoyama.ac.jp>
In-Reply-To: <4FD71D6A.9070101@it.aoyama.ac.jp>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: Jonathan A Rees <rees@mumble.net>, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org
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: Tue, 12 Jun 2012 11:00:24 -0000

Hiya,

Ah, ok I get it now. I'll look back at that again,

Ta,
S

On 06/12/2012 11:43 AM, "Martin J. Dürst" wrote:
> Hello Stephen,
> 
> On 2012/06/09 10:45, Stephen Farrell wrote:
> 
>> On 06/09/2012 01:43 AM, Sam Hartman wrote:
> 
>>> It's a naming
>>> hierarchy.  My main concern is whether the relative reference algorithm
>>> described in section 5/4.2 of RFC 3986. In particular take a look at the
>>> last part of section 1.2 of RFC 3986 regarding the disallowing of
>>> /. Consider how you want relative references in an HTML document
>>> resolved through a ni: URI to work.  I don't think your use of authority
>>> provides good results. However I'm not sure that better results would be
>>> achieved without hierarchy.  I hope though that these comments will help
>>> inject some ways of reasoning about authority that are less mystical and
>>> that lead to more practical discussion.
>>
>> Thanks.
>>
>> I think your comment about relative URIs is fair and we maybe ought
>> say there are no such things for ni URIs. (Or however that kind of
>> thing is stated best).
> 
> You can't say that. It's perfectly okay to have an HTML document like this:
> 
> <html>
>  <head>
>    <title>ni: relative URI test</title>
>    <base href="ni://example.com">
>  </head>
> 
>  <body>
>    <p>Please check <a href="sha-256;f4OxZX...">this document</a>.
>      And <a href="sha-256;UyaQV...">this other document</a>.
>      And <a href="sha-256-128;...">this third document</a>.
>    </p>
>  </body>
> </html>
> 
> ("..." used for brevity). What the browser will try to interpret when
> the links are activated is:
> ni://example.com/sha-256;f4OxZX...
> ni://example.com/sha-256;UyaQV...
> ni://example.com/sha-256-128;...
> 
> If you don't think that makes sense, then you might just leave it to
> users to not use it that way. On the other hand, if you think that's
> actively harmful (I couldn't come up with a reason for that), then you
> have to change to the form without //.
> 
> [Well, actual browser behavior is a bit more mixed:
> 
> IE does what's explained above, and tries to go to the address, but says
> that this page can't be displayed.
> 
> Safari uses the above resolved URIs when asked to copy the link, and
> also tries to follow the link saying that the page can't be opened.
> 
> Mozilla doesn't even show the link texts as links, nor allows to
> activate them, probably because it decides that it doesn't want to
> disappoint the user when she clicks.
> 
> Chrome shows the underlined links, but doesn't want to show any
> destination when hoovering. When activating, it goes to about:blank.
> 
> Opera shows and tries to go to ni://sha-256;f4OxZX... and similar, i.e.
> it seems to drop the authority, possibly because it doesn't have ni:
> registered as a hierarchical scheme. But that would be fixed when the
> scheme is getting implemented.]
> 
>> I guess a sentence or two about relative URIs would be worthwhile
>> and I'll ponder that.
> 
> Yes, please do. I'm willing to check it.
> 
> Regards,    Martin.
> 
>

v2.23.0 | Report a Bug | By Email