>>>>> Stephane Bortzmeyer <[email protected]> writes:
>>>>> On Fri, Oct 19, 2012 at 11:38:40AM +0700, Ivan Shmakov wrote:
>> My point is, that according to the specification [1], the part
>> immediately after whatever:// is used (roughly) to name the
>> particular server the content is stored
> Clearly no. The part after the :// is named the authority and does
> not have to be a server. To quote the specification (section 3.2):
>> Many URI schemes include a hierarchical element for a naming
>> authority so that governance of the name space defined by the
>> remainder of the URI is delegated to that authority (which may, in
>> turn, delegate it further).
Arguably, there's neither such delegation, nor such governance,
in the case of GNUnet. Instead, each and every GNUnet
implementation simply /knows/ what the gnunet://fs/ URI's are,
and what to do with them.
It simply doesn't seem quite right to me to use an “authority”
for a content-derived identifier. That may be a matter of taste
(as, indeed, the specification doesn't require that a DNS name
is used for “authority”), but still, it doesn't fit the by now
well-established pattern URN's at large adhere to.
I still suggest replacing //authority/ with namespace: before
GNUnet URI's are submitted for IANA registration. (Should such
a registration become imminent, or prior to that.)
[…]
> Also, several URI schemes have no "authority" field (isbn: of RFC
> 3187,
urn:isbn:, actually.
> tag: of RFC 4151, etc)
As per [1], at least the following URI's don't use //authority:
urn:ietf: urn:ietf:rfc:2648
urn:pin: urn:ietf:rfc:3043
urn:issn: urn:ietf:rfc:3044
urn:oid: urn:ietf:rfc:3061
urn:newsml: urn:ietf:rfc:3085
urn:oasis: urn:ietf:rfc:3121
urn:xmlorg: urn:ietf:rfc:3120
urn:publicid: urn:ietf:rfc:3151
urn:isbn: urn:ietf:rfc:3187
urn:nbn: urn:ietf:rfc:3188
urn:web3d: urn:ietf:rfc:3541
urn:mpeg: urn:ietf:rfc:3614
urn:mace: urn:ietf:rfc:3613
urn:fipa: urn:ietf:rfc:3616
urn:swift: urn:ietf:rfc:3615
urn:liberty: urn:ietf:rfc:3622
urn:iptc: urn:ietf:rfc:3937
urn:uuid: urn:ietf:rfc:4122
urn:uci: urn:ietf:rfc:4179
urn:clei: urn:ietf:rfc:4152
urn:tva: urn:ietf:rfc:4195
urn:fdc: urn:ietf:rfc:4198
urn:isan: urn:ietf:rfc:4246
urn:nzl: urn:ietf:rfc:4350
urn:oma: urn:ietf:rfc:4358
urn:ivis: urn:ietf:rfc:4617
urn:s1000d: urn:ietf:rfc:4688
urn:nfc: urn:ietf:rfc:4729
urn:iso: urn:ietf:rfc:5141
urn:xmpp: urn:ietf:rfc:4854
urn:geant: urn:ietf:rfc:4926
urn:service: urn:ietf:rfc:5031
urn:smpte: urn:ietf:rfc:5119
urn:epc: urn:ietf:rfc:5134
urn:epcglobal: urn:ietf:rfc:5134
urn:cgi: urn:ietf:rfc:5138
urn:ogc: urn:ietf:rfc:5165
urn:ebu: urn:ietf:rfc:5174
urn:3gpp: urn:ietf:rfc:5279
urn:dvb: urn:ietf:rfc:5328
urn:nena: urn:ietf:rfc:6061
urn:cablelabs: urn:ietf:rfc:6289
urn:dgiwg: urn:ietf:rfc:6288
urn:schac: urn:ietf:rfc:6338
urn:ogf: urn:ietf:rfc:6453
urn:ucode: urn:ietf:rfc:6588
[1] http://iana.org/assignments/urn-namespaces/
--
FSF associate member #7257
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
