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

Received on Thursday, 3 May 2012 14:53:13 UTC