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

From: Ivan Shmakov <[email-masked]>
Date: Sat, 20 Oct 2012 14:27:32 +0700

Well, we've discussed [1] this a bit in p2p-hackers@, and it
	seems that I've ran out of arguments by now.

	The current GNUnet implementation [2] employs URI's like the
	following one for identifying content:

gnunet://fs/chk/17GU5A2CIAQMP0K0UIGI0F3SVVB1M5HCVQC74U6KQQV9LUVJHG78ID6DLNS3EKFKT6EH24QINVVFP5CEB9455I57KAE9AT1CSM98HA0.7MPI2R9LPGVIVPADTVKJBIRKQRQVVVQ5Q0N8HU8DDRHTK56P73SUPB82V356SFJQSL0H2RNHL2MLI8AM7BA3TAOS2D97K0RQ86VDVG0.14

	where 17G…HA0 is (AIUI) the Base32-encoded hash of the content.

	My point was that // in gnunet:// implies some sort of naming
	authority, which ‘fs’ (which names the “filesharing” component
	of GNUnet) is not.  So, presuming that the GNUnet URI scheme
	will (eventually) be submitted for registration with IANA, I've
	suggested to switch to the gnunet:fs: prefix instead.
	Unfortunately, as it now appears, I cannot clearly explain why
	exactly such a change should be made.

	Could this issue be clarified, please?

	TIA.

[1] http://comments.gmane.org/gmane.network.peer-to-peer.p2p-hackers/3569
[2] http://gnunet.org/

-- 
FSF associate member #7257

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 21 Oct 2012 20:34:29 +0200 (MESZ)

Ivan,
[speaking as a WG co-chair]:

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.

If, OTOH, you consider solving the objectives of the envisioned 'grunet'
URI scheme using URNs, read our drafts (and their RFC predecessors) and
submit an internet-draft for the registration of an 'grunet' URN
Namespace (using identifiers starting with "urn:grunet:") and eventually
have it being discussed on the urn-nid (AT) ietf.org mailing list.

But, at first glance (please ignore this statement if you are sure
of the contrary), it looks like the identifiers sought are neither
persistent nor protocol-independent, so likely they won't fit into
the URN framework.

On Oct 20, 2012 02:27:32, Ivan Shmakov <[email-masked]> wrote:

>       where ...
[...]
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

Note:
  All information on the URNbis WG of the IETF is available on the
  WG home page at  http://tools.ietf.org/wg/urnbis/ .

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ivan Shmakov <[email-masked]>
Date: Mon, 22 Oct 2012 12:29:23 +0700

>>>>> Alfred Hönes <[email-masked]> writes:

 > 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.

 > scheme registrations.  More general URI-centric lists are hosted by

	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

[…]

---

From: Larry Masinter <[email-masked]>
Date: Wed, 24 Oct 2012 14:20:57 -0700

(don't think this is a 'urn' issue, but):

http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg

3.2.  Syntactic Compatibility
   Avoid improper use of "//".  The use of double slashes in the first
   part of a URI/IRI is not an artistic indicator that what follows is a
   URI/IRI: Double slashes are used ONLY when the syntax of the <scheme-
   specific-part> contains a hierarchical structure.  In URIs and IRIs
   from such schemes, the use of double slashes indicates that what
   follows is the top hierarchical element for a naming authority.
   (Section 3.2 of RFC 3986 has more details.)  Schemes that do not
   contain a conformant hierarchical structure in their <scheme-
   specific-part> SHOULD NOT use double slashes following the
   "<scheme>:" string.

That is, the only effect of //  / delimited authority is on the resolution of relative references in contexts that do not otherwise have a "base".

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivan
> Shmakov
> Sent: Saturday, October 20, 2012 12:28 AM
> To: [email-masked]
> Subject: [urn] // in gnunet://, and other P2P URN's
> 
> gnunet://fs/chk/17GU5A2CIAQMP0K0UIGI0F3SVVB1M5HCVQC74U6KQQV9LUV
> JHG78ID6DLNS3EKFKT6EH24QINVVFP5CEB9455I57KAE9AT1CSM98HA0.7MPI2R9L
> PGVIVPADTVKJBIRKQRQVVVQ5Q0N8HU8DDRHTK56P73SUPB82V356SFJQSL0H2
> RNHL2MLI8AM7BA3TAOS2D97K0RQ86VDVG0.14
>