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:08 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 3637121F864C for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 04:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.866
X-Spam-Level:
X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 i+y9EbAq5yqm for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 04:08: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 2066421F84DF for <ietf@ietf.org>; Tue, 12 Jun 2012 04:08:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 864A9171805; Tue, 12 Jun 2012 12:08:17 +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=1339499297; bh=tyCCdiptUrmUaj hwG1NzOHu9K9Sx2nVTVUAaDNwxfrI=; b=pftNW977sRo1l0PsCTcVxFcrAn3uo0 mfAy0WCD9sifGwJB9oVYZUPESio6m133rkgUZWgP2A/okxdzi56x/VLg75CLDGQj HFfb5oNRdcXyq+y33FzB4+FkVLaUAq2pjTfGwiwTcfgOkB9+xakatOk9M8QKb9/e 3zAE2KMAq0yEvXnmNcBtr1VcbvHTVDpHJ3An7fkdjvoiYMTpYgB/BJdyNToaO0sd OYcGDHyJ/WUgWQD9qFJWfoe2fi2vJ37g5DXnKMSJXh7/MZU9WSgYeWbfekhJLhFH LJwJLavzrKEwoAo0osMnFQYV2zI0ZNYtRaxVNVU6Ei5Tu5J09+5JQdsg==
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 c+xBy2vCeafQ; Tue, 12 Jun 2012 12:08:17 +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 4C60C171803; Tue, 12 Jun 2012 12:08:15 +0100 (IST)
Message-ID: <4FD7231F.1050903@cs.tcd.ie>
Date: Tue, 12 Jun 2012 12:08:15 +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:08:26 -0000

So would it work to add this:

"
   Note that relative ni URIs can occur, for example as shown in
   Figure 5.  In such cases, user agents MUST construct the absolute URI
   as they would in the case of an HTTP URL, that is, in the example
   shown the absolute URI for "this third document" would be
   "ni://example.com/sha-256-128;...".


     <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>

                Figure 5: Example HTML with relative ni URI

"

Better suggestions welcome.
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.
> 
>