IETF Logo Mail Archive

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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 12 June 2012 10:44 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 5F96721F861A for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 03:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.38
X-Spam-Level:
X-Spam-Status: No, score=-99.38 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 oEyR3oMG8mIc for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 03:44:06 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 905DF21F8619 for <ietf@ietf.org>; Tue, 12 Jun 2012 03:44:05 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5CAhwZK011380 for <ietf@ietf.org>; Tue, 12 Jun 2012 19:43:58 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7682_047d_83a05c44_b47b_11e1_96d0_001d096c5782; Tue, 12 Jun 2012 19:43:57 +0900
Received: from [IPv6:::1] ([133.2.210.1]:37047) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15D1705> for <ietf@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 12 Jun 2012 19:44:01 +0900
Message-ID: <4FD71D6A.9070101@it.aoyama.ac.jp>
Date: Tue, 12 Jun 2012 19:43:54 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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>
In-Reply-To: <4FD2AAB3.4010305@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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 10:44:07 -0000

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