Re: [urn] Secure naming of Information Objects

["Kemp, David P." <[e-mail]>]

Comments on http://datatracker.ietf.org/doc/draft-farrell-ni/:

1) I don't see the benefit of defining syntax without specifying any requirements:

   We expect it will be beneficial for applications to be able to map
   between human-readable URIs and URIs that allow for validation of
   integrity the URI/resource mapping.  However, in order to keep our
   scheme simple and more broadly applicable, all considerations for how
   to map between URIs and for how to access resources using these URIs
   are to be specified elsewhere.  In this memo, we simply define a form
   of URI that can be used hopefully in many different contexts.

The ABNF does not specify any syntax for "other-string", there are no other requirements for "other-string", and there is no defined way to map between an "other-string" and a hash-string.  If all these things are to be specified elsewhere, the value-add of this document saying that an NI can be "ni://" followed by anything including maybe some more slashes, is precisely zero.

This document should define hash URIs only.  If some other document defines a mapping between hashes and something else, then the merits of that mapping can be discussed in the context of that other document.

2) This (at the top of page 4) is bizarrely circular:

    Note that the "/" character from the MIME type MUST be percent
    encoded in order to conform to the ABNF below.  That is "application/
    jpeg" will be presented as "application%2fjpeg".

    mime-type = type %2f subtype

The ABNF could just as easily have been written using a slash, as RFC 2045 defines content-type:

    content := "Content-Type" ":" type "/" subtype

and then the "/" character wouldn't have to be percent encoded.  Is there some reason the ABNF was written using a percent encoding for slash?

3) Why would there be a need to register truncated hash algorithms?  An algorithm is an algorithm, and truncation is truncation - there is no reason to register the cross-product of the two.  The example:

    ni:///sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ5MjkyZDM0ZTg
    2ZDI5YzllMmU5OTFlNmE2Mjc3ZTFhN2JhNmE4ZjVmMwo

could just as easily be written:

    ni:///sha256:NDVmZTMz

to specify the first 48 bits of the SHA256 hash value.  I don't see the value of a URI that does not uniquely identify a resource.  But if there is some scenario for which collisions are acceptable, there is no useful extra information to be derived from a truncated hash identifier, e.g., ni:///sha256-t48:NDVmZTMz.

4) In general, this draft seems light on specifics and heavy on generalities.  I would prefer to use the more mature http://tools.ietf.org/id/draft-thiemann-hash-urn-01.txt as the starting point for defining hash-based names.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Börje Ohlman
Sent: Thursday, March 31, 2011 1:01 PM
To: [e-mail]
Subject: [urn] Secure naming of Information Objects

As I mentioned at the WG meeting today we (people working on Information Centric Networking) have done some work on how to name information objects. We have noted that there are a number of working groups within the IETF that , we think, could have use of such a common naming scheme, e.g. PPSP, DECADE and CDNI. We think a common naming scheme within the IETF would be useful.

 

Below you find links to two drafts that we have submitted on this subject. It would be very valuable to have your comments on the ideas presented in those drafts. Also suggestions on which would be the best place within the IETF to work on such a common naming scheme would be useful.

 

http://datatracker.ietf.org/doc/draft-dannewitz-ppsp-secure-naming/

http://datatracker.ietf.org/doc/draft-farrell-ni/

 

                             Börje Ohlman