RE: the "ni:" URI scheme soon to "last call" in IETF

From: Larry Masinter <masinter@adobe.com> · Date: Thu, 3 May 2012 08:19:00 -0700

The message I forwarded was to "uri-review" mailing list: 

Uri-review@ietf.org 
Info https://www.ietf.org/mailman/listinfo/uri-review 
including archives & subscription info.

The email says:

> Barry Leiba is planning to AD sponsor this and Alexey
> Melnikov will be shepherding so if you can cc them as
> well as the authors on any questions or comments that'd
> be good.

You can reach authors via
Draft-farrell-decade-ni@tools.ietf.org

-----Original Message-----
From: jonathan.rees@gmail.com [mailto:jonathan.rees@gmail.com] On Behalf Of Jonathan A Rees
Sent: Thursday, May 03, 2012 7:53 AM
To: Larry Masinter
Cc: www-tag@w3.org
Subject: Re: the "ni:" URI scheme soon to "last call" in IETF

On Tue, May 1, 2012 at 6:40 PM, Larry Masinter <masinter@adobe.com> wrote:
> I think we talked about this under "naming things with hashes" (in this case, not "#" hash-mark fragment identifier, but rather hash-of-content).
>
> http://tools.ietf.org/html/draft-farrell-decade-ni-05
>
> I suggest looking at how this spec uses the word "resource". " information-centric networking" might also be an interesting topic as we talk about "local storage" also (see references).
>
> Larry

The phrase "specific resource" is used which in my mind sufficiently
distinguishes these resources from the more generic kind you often
access via HTTP.

As I said before I think this topic is pretty important and this
document should be monitored. It seems like ni: is trying to provide
content addressing, which would be a wonderful thing to have, but I'm
not sure how well it does.

I'm bothered that this draft has no provision for reliably determining
a media type and in fact does not discuss media type at all. It will
create yet another case where sniffing is required. The server could
provide one but there would be no reason to believe what it says (the
whole point is to remove the need to trust the server, right?). The
scheme could do what data: does and put the media type in the URI. Or
the hashed content could have the syntax of headers + blank line +
content similar to an HTTP message.

At the very least the possibility of the server providing an attacking
media type should be called out in the security considerations
section.

I don't understand the MUST in section 4. AFAICT this scheme is
similar to ark: in that, in principle, one could ask any server at all
for the content, since the resource's identity is determined by the
path (except for media type). There should be no appeal to authority
and the MUST should be superfluous.

I guess I should join the fray. Does anyone happen to know where
discussion is taking place?

Jonathan