Re: [urn] // in gnunet://, and other P2P URN's

[Ivan Shmakov <[e-mail]>]

>>>>> Alfred Hönes <[e-mail]> writes:

 > since you (at least in your message) don't speak about URNs in the
 > sense we are talking about here (cf. the charter of the URNbis
 > working group and our drafts to revise RFCs 2141 and 3406), I think
 > the discussion you seek is out of topic for the urn list.

 > Please redirect your concerns and questions to some URI related
 > list(s) according to their specific dedication.

 > The particular, the uri-review (AT) ietf.org list has focus on URI
 > scheme registrations.  More general URI-centric lists are hosted by
 > the W3C.

	ACK, thanks for the pointers!

	There were two sources of confusion for me.  First, there's the
	urn:uuid: namespace (as per RFC 4122), which allows for
	content-based (MD5, SHA-1) identifiers, similar to those
	employed in P2P filesharing networks (including BitTorrent,
	Freenet, and GNUnet.)

	Second, there're (non-standard, though, as it seems, widely
	used) urn:btih: (and, similarly, urn:sha1:, etc.) URI's that, I
	believe, were intended for registration as URN namespaces.

	However, I was since pointed to the proposed ni: URI scheme [1],
	which appears to be better suited to the task of P2P content
	identification.

	(To clarify: while the present gnunet: URI's are indeed
	application-specific, the primary payload of such URI's are
	base32hex-encoded SHA-512 digests over arbitrary content.  While
	the ni: scheme as proposed doesn't allow for such, it provides
	the relevant extension mechanism, which may allow for gnunet:
	URI's, as well as urn:btih: and freenet:, to be superseded with
	ni: ones in the future.)

[1] http://tools.ietf.org/html/draft-farrell-decade-ni-10

[…]

-- 
FSF associate member #7257