Slashdot Mirror
IETF Draft Sets up Public Namespaces
figlet writes "A new IETF draft is out (URI Scheme for Information Assets with Identifiers in Public
Namespaces). It is a very cool idea and basically introduces namespaces through a new URI scheme. These would be used to refer to resources within their own context. NISO will be the registry for public namespaces. Example (from Herbert Van de Sompel): 'For example, assuming that the namespace of Dewey Decimal Classifications (ddc:) and the namespace of Library of Congress Control Numbers (lccn:) would be registered by their respective authorities, then: the Dewey Decimal Classification 22/eng//004.678 (for the term "Internet") could be expressed as the "info" URI:<info:ddc/22/eng//004.678> and the Library of Congress Control Number 2002022641 could be expressed as the
"info" URI <info:lccn/2002022641>.' NISO is going to act as the 'info' registry. Very neat. This basically sets up a parallel web of info spaces, where http/DNS space is just one of many, and anyone can register their namespace 'domain'. Way cool!!"
I call dibs on the pr0n:// namespace!
"Luck is the residue of design" -- Branch Rickey
Just wait until someone like Verisign gets a hold of this. Utter chaos!
Google Cache
I have over 70 freaks, do you?
URI
URI <info:goatsecx/hello>
Trolling is a art,
This seems like XML, only even more confusing. Arbitrary key names are now URIs? Where is the uniformity in this system?
Without strict discipline, users will create their own, incompatible URIs in the same namespace. Their needs to be a guiding hand in all this-a document or company that oversees this project VERY carefully. We don't want this turning into some aimless metanarrative like the "Information Superhighway".
(-1, Raw and Uncut is the only way to read)
That mean there'll be domain squatters in many different levels. And for free!
It's just a BloJJ
I call dibs on the porn:// namespace!
To get a namespace registered? ICANN? Verisign? This part was interesting: The "info" URI scheme explicitly decouples identification from resolution. Applications SHOULD NOT assume that an "info" URI can be dereferenced to a representation of the resource identified by the URI, though some business processes MAY make "info" URIs resolvable either directly or conditionally. The purposes of the "info" URI scheme are the identification of information assets and the standardization of rules for declaring and comparing identity of information assets without regard to any resolution of the URI or even whether the information asset identified by the URI is accessible on the Internet. This makes it look like this was intended more for internal use than for routing to specific information on the net. Anyone have a clear idea how and why this would be used on the internet?
Just what we needed! Quick, someone publish 10000 pages on the XML schema to implement it!
Must-not-watch TV!
From the article:
"The "info" URI scheme explicitly decouples identification from resolution. Applications SHOULD NOT assume that an "info" URI can be dereferenced to a representation of the resource identified by the URI, though some business processes MAY make "info" URIs resolvable either directly or conditionally. The purposes of the "info" URI scheme are the identification of information assets and the standardization of rules for declaring and comparing identity of information assets without regard to any resolution of the URI or even whether the information asset identified by the URI is accessible on the Internet."
In other words, the info URI's will not be useful for anything other than providing context and identification. There is no resolution mechanism in place, nor do they intend to have any standard resolution mechanism, which makes the practical use of these URI's almost nonexistant (as current designed.)
Why do I h8 apple?
With addresses like URI:, I'll spend more time on the phone trying to help my mother get where she needs to.
ALL mistyped identifiers to go to "Hustler magazine" (or the highest monthly payer).
Similar to Verisigns new 'service' to direct you to web-bugged spam pages autogenerated when you mistype a domain in a browser.
With no checksum as part of the proposal this is an idiotic system full of mistyped symbols.
but they WANT mistyped dewey decimal numebrs because then they can redirect you to porn merchants.
A new revenue model!
Anyone else notice info-uri.niso.org doesn't exist?
How exactly will browsers implement this new protocol?
I'm confused about the concept of a "public namespace". If these new URIs are intended to point to information, where will that information be stored and how will it be retrieved?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
This has some interesting possibilities, especially in the context of representing real-world elements in virtual space, and assist in more accurate search engine results. For example:
info:map/40.47N/73.58W for NYC's Central Park
could be encoded into any Web page about Central Park; and
info:palm/model/P80900US for the Palm Tungsten C
could be included in every online retailer's site where the T|C is sold.
This would seriously enhance the now piece-meal effort to pick the best search term to find specific items that may have common names. {Jonathan}
-------------------
Prof. Jonathan I. Ezor
Associate Professor of Law and Technology
Director, Institute for Business, Law and Technology (IBLT)
Touro Law Center
300 Nassau Road, Huntington, NY 11743
Tel: 631-421-2244 x412 Fax: 516-977-3001
e. jezor@tourolaw.edu
BizLawTech Blog: http://iblt.tourolaw.edu/blog
We already have top-level domains for that sort of thing. The resource identifier system (http:, gopher:, etc.) are already in-use and they're NOT used as namespaces.
We don't need this sort of half-thought-out component to the domain name system. If you're going to do anything with resource identifiers, make a change to BIND to allow DN servers to map them to A records.
You know what's going to happen. People are going to register these namespaces and use them instead of domain names. Then we're going to have two parallel systems: the name.dom style and the space:name style.
Dumb dumb dumb.
Check out URI:
--Joe
There are only a bit over 17000 TLA's and there already are 3 candidates for DDC (according to www.acronymfinder.com)...
Antti S. Brax - Old school - http://www.iki.fi/asb/
so did the University of Rhode Island make this or are they just luck enough to get their school promo-ed in every webpages now? when i type URI into google what am i gonna get?
info:ddc/22/eng//004.678
is better than
http://www.ddc.com/22/eng/004.678
I'm schizophrenic; no I'm not.
Err, things haven't been way cool!! since the Eighties...
Isn't our industry trying to propel mankind into the future? Forwards is that way...
'Thats they exact same thing a banana wrench monkey.'
URI
...and you can address (almost) everything! Look forward to a URI coming your way any time now..
--
What karma?
Why stop at pr0n (or adult://)? Let's get specific.
fetish://
images://
shag://
oral://
3some://
orgy://
etc.
Actually, this brings up an interesting point - everyone with a competing interest could very well seek to distinguish their business model with a URI specific to their industry. Doesn't that mean we could have way, way too many of these stupid things?
The URI namespace is already quite broad and has many ways to define "public" namespaces, usually based upon the URN subset of the URI specification. Just a few open-ended namespaces so far include the OID-based URI namespace, such as "urn:oid:1.3.6.1.2.1.27", (RFC 3061). You also have RFC 3151 for public identifier URIs.
Really, there is nothing new technically here. The only useful thing it brings beyond the URN spec is the new registration authority. It can still prove useful, but it's not like it's actually solving any real technical limitation in our current set of URIs.
hehehe, reminds me of an old joke:
What would michael's namespace be?
<gay:anal/69/bj//24.7>
Writing a spec is the easy part (and this one seems particularly trivial). Implementing it is a lot harder.
The main missing information seems to be a DNS equivalent function. It is one thing to introduce yet another central registrar to insure "against hostile usurpation or inappropriate usage of registered service marks" (groan!) but how are we going to access the information? Section 4.2 says
and it is clear from section 6 (Normalization and Comparison of "info" URIs) that any sensible implementation would need access, but how?
The information they want to return is much more complex than what DNS returns and DNS is not a trivial infrastructure.
Suggestions? Volunteers? :-)
Hi!
With the data uri scheme, I can include the whole internet in my URIs!
Programming can be fun again. Film at 11.
All the examples given - Dewey, Library of Congress etc - are classification schemes. They don't identify *resources* in the usual sense of the word.
In other words, if I type a Dewey info: URI into Moz n+3, what do I get? The description for that code? A list of Gutenberg texts? A list of ISBNs? An Amazon search result?
Anybody have examples of how these URIs would be used in practice?
I remember radio ads way back in 1997, 98 where they'd read out the entire URL, which was excruciating:
"H T T P colon slash slash W W W dot (pause) whatever dot (pause) com"
Are we going to have to relive that if new namespaces are added?
A programmer is a machine for converting coffee into code.
Perhaps the Dewey Decimal classification isn't the best example. After all, it's not in the public domain.
The same source code in the Unix version appears to have been cut/pasted from the Windows version and then had everything but the first handful of comments (which still refer to the Windows Registry!) excised. Leaving no way directly in the code to extend your URI tags.
I have *recently* seen that someone hacked up an XPI to re-implement telnet:// and a few other choice things, but his code only works on Moz 1.3 and relatively new Firebird installations, so it doesn't suit my needs. I tried poking at it to make it default some values, to see if that was all that was wrong with the earlier stuff (i.e. no way to set up the "helper apps" from NS 6/7 etc) but that didn't work.
So how do we expect the Mozilla family of browsers to handle even more new tags? Is there going to be some standard way to extend this, without resorting to XPI hacks that are heavily version dependant? Will someone actually implement the OS-specific code necessary? (no, don't ask me to do it, I'm a support guy, not a coder, and anything I'd write would be horrible I'm sure). I can't see how this is likely to fly very far....
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
I bet the RDF advocates (here's a primer) are going to love this, because RDF already uses URIs to refer to objects, although the URIs are often used just as a namespace themselves. In other words, just because you see a URLI in a RDF fragments doesn't mean it actually exists, it's just a name for something. This is not unlike XML namespace use of URIs. If you could refer to more kinds of objects with URLs that could be resolved, that would make RDF more useful.
Something just occured to me:
How quickly do you think that some unthinking government agency or financial institution will start including Social Security numbers into URIs, and make them publicly searchable? It will probably happen accidentally, given that so many institutions use SS#s as identifiers even though they're not supposed to.
*sigh*
{Jonathan}
-------------------
Prof. Jonathan I. Ezor
Associate Professor of Law and Technology
Director, Institute for Business, Law and Technology (IBLT)
Touro Law Center
300 Nassau Road, Huntington, NY 11743
Tel: 631-421-2244 x412 Fax: 516-977-3001
e. jezor@tourolaw.edu
BizLawTech Blog
When I first read this article, it was the first thing that came to mind. (Maybe because I'm reading it now! :-)
-el_Dahem.
The Wknd Sessions - Malaysian and South East Asia independent music
Yup, when I get "stung" on the goatse.cx page I always laugh. The "oh that's disgusting" crowd don't see the humour I guess.
Sure It's a great idea and could help organize the web a little... It would be expensive to implement as new software woul dhave to be purchased EVERYWHRE -> How confusing would all this be for the average computer user? -> Would it still be possible to effectively search across namespaces?
Just food for thought
In the 80's it was underscores:
/why/do/i/want/to/store/information/this/way
some_textfile_whatever_blah_blah_blah
In the 90's it was periods:
System.out.println("Hello 90's World!!");
www . whatever . com
In the new millennium it's SLASHES?!
I am beginning to get the "point" of this.
It's definitely not going to be a 'host lookup' mechanism.. It's kinda like a search engine
Instead of typing keywords into your "search engine", you type the URI into there...
THEN, all the pages that contain that URI in their page body will be returned as a list.
It's a way to specify data more closely, hence hoping to make for better search engines.
(That's enoguh of me talking out of my ass now)
1) this is just the same idea as URN (provide identification rather than protocol:hostport). That's a basically good idea, IMHO. But we don't need a multitude of slightly different variants.
2) the DDDS (name resolution that can be based on DNS) is already an Internet (proposed) standard that can be used to resolve arbitrary URIs with DNS support - if the authors so desire.
References at an RFC library near you.
Well, this may be all well and good (dont'
.us
namespace:
know, haven't looked at it closely), but I'm
still waiting for a sensible addition to the
Always? You mean you get "stung," as you so quaintly put it, more than once? Dude, the domain name the link goes to is RIGHT THERE.
Are we going to see UPC namespaces, and other databases converted over? Personally, I'd like to see a standardized way to access a company's product page for a given product. For example, one of my art prints could be listed under info:devinmoore/prints/printx or something like that. IS that what this service will do, beyond the library classification? Furthermore, will the library of Congress publish all their books online to the system? That would be rad!
stuff |
But it won't be any good until major browsers (IE, Mozilla, Safari) support it out of the box.
CueCat was way ahead of it's time. Wow.. the possibilities!
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Quick, without peeking at the answer, what's the difference between a URI, a URL, and a URN? OK, now that we are all on the same page :-), what is "info:"? you'd expect it to be a URN. It isn't (from the RFC):
7.2 Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?
RFC 2396 [RFC2396] states that a "URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier". An "info" URI on the other hand does not assert persistence of resource names or of the resource itself, but rather declares namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.
Which I read to mean that an info: URI may, or may not, be a URL (i.e., useful for actually accessing the resource); may, or may not, be a URN (i.e., provides some semblence of a chance that it means the same thing today as it did yesterday). Oh, did I mention that it may, or may not, be case sensitive, and may or may not be subject to scheme-specific normalization rules?
It seems that someone (say "Perfection") got fed up holding the fort agains a hoard of requests for top-level URI schemes - or someone (say "Kludge") got fed up with the demand that these schemes actually have some well defined semantics. Or both. Either way, they had this brilliant notion... why don't we have a junk^H^H^H^Hinfo: URI scheme with as little control over semantics as we can get away with? If some top-level URI scheme sucks, we'll just put it there. We'll spin off a company to be the registrar so "Perfection" will be able to pretend not to see it, and "Kludge" will be able to register all the junk^H^H^H^Hinformation URIs he wants!
I guess it does make some sort of twisted sense... In the meanwhile, proposals like the taguri proposal languish. Here's a years-old proposal that attempts to define coherent semantics for time-persistant identifiers, without requiring a (new) registration agency. We can't have that, can we?
Sigh. Insert mandatory "I for one welcome the arrival of our new info:disposable:gjyr4784ghf89yf4h URI masters" post here...
You can rely on a rich new vein of controversial decisions on minor points of particular namespaces for Slashdot to cover. You can also rely on hundreds of us, batty-eyed from trying to find a bug, safely venting our anger on these design mistakes instead of throttling every co-worker listed before us in a module's revision history.
Looks to me this proposal is another way of uniquely tagging digital content.
Could someone explain if and how this proposal is somehow similar to (or different from) the Digital Object Identifier standard (DOI)? DOI, although proprietary (like EAN, UPC, etc) is gaining momentum; for example, here in Italy is going to be adopted as a general standard for the public administration documents.
It is still going to require another registry that has central control. All this does is "one up" the game. What would be better is a global decentralized directory where anyone can broadcast their own name, and it is verified and authenticated by users storing the proper authentication key. This is slightly similair to what Skype has done with their global decentralized user directory.
Any downfalls you can name for this system still doesn't rule out the benefits of it being run IN ADDITION to central controled DNS with problems like Verisign.
I'm registering
Call me Verisign-boy
there's no place like ~
Needs something more difficult than the present system? Prolly *nix weenies!!! Ya cunts.
The Dewey Decimal System is a highly protected trademark of Online Computer Library Center -- use it without paying a license fee, and they'll sue you (another story)
From their FAQ: May I use the DDC to organize information on my Web site?
The DDC is owned by OCLC Online Computer Library Center, Incorporated ("OCLC"). We do consider licensing arrangements for the DDC database. To request a licensing proposal, please send an e-mail message to DeweyLicensing@oclc.org, describing in detail your proposed use of the DDC.
HIV Crosses Species Barrier... into Muppets
Like it or not, the majority of Internet users today are what a typical slashdot reader would call "newbies". (Think about your mom using a web browser and ending up at whitehouse.com instead of whitehouse.gov)
Anything that increases the complexity of internet addressing without good cause would cause more harm than good. In other words, it violates the KISS principle to keep it simple.
Chip H.
boards... yes?
/.?
Why bother wasting your typing on
When you want something done in the OO society...
You need to bug the people that are doing the coding.
Because it's topical to the article in question?
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
URLs already offer this functionality. Even the HTTP protocol URL offers it, along with a minimal structure that reflects how current infosystems are structured:
//[/][?]
b le %20VALUES%20(%3F%2C%20%3F)?field1=100&field2=2 0
0 04 .678
http:
The "path" and "query string" components of the HTTP URL can be any arbitrary sequence of HTTP-URL-legal characters. The path typically maps directly to a subtree of a hierarchical filesystem accessable by an HTTP server, and the query string typically maps directly to a list of named argument values. However, that merely reflects how people have configured their servers. A different API can easily be coded in that URL format. For example, a SQL server can easily be wrapped in an HTTP server, with parameterized queries like
http://sql-server.domain.tld/INSERT%20INTO%20ta
which could execute the URL-decoded statement "INSERT INTO table VAUES (?, ?)" with arguments field1 and field2 set to 100 and 200, respectively. TinyURL.com completely genericizes the API by translating a unique ID into any URL, as defined. The Dewey Decimal System URL in the IETF draft example could be
http://info.DeweyDecimalSystem.com/ddc/22/eng//
Other URL schemes, like FTP, or even "file:" can map similarly. So all the draft does is establish a new registrar, a la VeriSign, to sell access to a new namespace. How long before the NISO registrar is spun off, and probably snapped up by VeriSign?
--
make install -not war
However, just as there is no law that says companies can't ask for your SSN, there's no law that says you have to give it to them.
"There's no law that says you have to" survive. If a geographic monopoly provider of one of the basic human necessities requires you to do something in order to obtain its product, you have to do it, move, or die.
Will I retire or break 10K?
I know the document discusses this, but I don't know that I buy the explanation. The spec says a URN should be persistent, and since we don't want to enforce persistency we go off and create something new?
So now when I want to come up with a new way to label information internally, I have two avenues that are now, for most intents and purposes, competitors. If I want a persistent label (for my own definition of persistency, since either way, these are still my labels), I can go with URN or info at my discretion. If I don't want persistency, and want to be anal about my interpretation of a URN, I'm sort of "encouraged" to go with "info".
It just seems counter-productive to create something brand new when a URN is probably going to be good enough. Maybe we just need to use urn:dyn or urd: or urt: instead of urn: if we want to make it very clear that the namespace underneath that will be dynamic.
It just bugs me when standards bodies go off and start considering two different implementations of something that overlap 99% in purpose.
Am I missing something? Is the persistency thing really that much of a blocker that a URN is so inappropriate that something else entirely needs to be invented?
Everyone will become totally confused, not only because this is a new obfuscated URI scheme, yet because there is a .info TLD!
There's a good idea! Take the most archaic, difficult to use/administer/maintain system on the net and add functionality.
90% of admins out there can't properly set their DNS servers up now, what would happen if you added this to BIND.
Why do we need this? What's wrong with our current namespace that this will fix?
Sometimes it seems like many new ideas generate excitement just because they are new. This is one of them. Want to look up a patent, go to http://www.uspto.gov/ and look it up! There's no need for a URI of <info:USPTO/patents/12345666789>. Strings like that only get geeks excited...
it's worth noting that the "info" work emerged from NISO's OpenURL development. OpenURL is a standard for packaging metadata into a URL. Hundreds of libraries around the world have implemented resolution systems ("link resolvers") based on this OpenURL standard.
The info URI will just be a way to reference things so that these link resolution facilities can understand.
Many people are well trained in looking things up in massive dead tree tomes of tenichal documents, Library drawers, etc. If you know how to use the Dewey Decimal system for example, you can find a book in a card catalog at a library even faster than using Google! It's all about the right tool for the job.
Also, unlike Google, these are very specific identifiers. Exactly one company has rights to a registered IBSN book, Or one company sets the standard of indexing [dewey decimal]. This could be good for government documents and forms, RFC/ANSI/ISO/SAE specs, and manufacturer part numbers.
My step-dad works in the QC department at a electronics assembler and constantly needs to look up component specs for verification. He's looking for an exact document from an exact company, times hundreds of components at a time...Google doesn't cut it here...too much clutter. Typically [back in the 80's] companies used to produce entire techinical libraries of technical documentation [and have to update it YEARLY] now we have the web, but we've lost the simple ability to just "grab a book" and be done with it...this scheme would help with that.
That said, They should have just gone to Google with it. It'd make a great "google hack" that google could even profit from! Who knows, maybe Google will still beat them to it!
Read the fine internet-draft. One of the authors is from OCLC. Wanna guess that he knows how the Dewey numbers can and can't be used?
URLs specify methods for accessing resources, not identifiers for them. The "info:" draft explicitly states that the things it's intended to name might not be "resources" - that they might not be accessable online and that you shouldn't even try. The idea is a way to *talk about* objects, not to *retrieve* them.
As much as I actually like the idea, it's too-heavily based on the unfortunate concept of a repository. I don't mind *having* a repository, but look at what it's going to contain! You can't even successfully compare two "info:" URIs without checking the repository to determine if they're case-sensitive. Important information that would be useful offline shouldn't live in the repository.
Strictly, the URL is a Locator, which specifies "where" in virtual space a resource is located. And a URI is an Identifier, which specifies a resource's identity. The "info:" URI draft duplicates the URL, as demonstrated by the DDS and LLCN examples, replacing eg. HTTP's network domains, hierarchical filesystems and argument strings with their own native structures, eg. DDS hierarchical notation and LLCN ID numbers. The existing URL format is so similar, because it does the same thing. An info: URI specifies how to retrieve an object from a namespace. One problem with the info: mechanism is that it privatizes the APIs to the different namespaces, which balkanizes the implementation; each namespace has its own private language. Another problem is that an object is not necessarily strictly "identified": identical books would have different DDS and LLCN URIs, so an identical object has non-identical identifiers. These problems with URIs, and the utility of URLs, have stood in the way of introducing a URI that deals with object identity, without the baggage of its location, or other artifacts of the infosystems in which they are represented.
--
make install -not war
I could see a cool use of this. We could use something like AlterNic or OpenNic using something like: info:alternic/somehost.tld That would make linking between the two namespaces mind numbingly easy and would basically make it usable to just about anyone.
Oops!
Thanks for the mention (I'm co-author of the tag: URI draft), but tag: URIs are languishing in large part because it's not that clear they are useful. They have some of the same problems
as info:, namely they don't give you any handy functionality. They just kind of sit there. They're not not nearly as cool as http, for most uses.
That said, I still kind of want them approved to help focus people who DO want this kind of thing. But since it's not very important to me, I have a hard time putting time into jumping IETF hoops.
What numbskull decided to call it "info"? I'm going to smack the next person I see who creates a directory on his computer called "data", thinking this will be an informative and useful name that differentiates it from other things.
If you're one of those people, I've got news for you: everything in all your directories is data! Yes, that's right, even the software is data. The chat logs, those are data too. And the swap file? Also data. Also, viruses aren't an exception. They're data as well.
Likewise with "info". If this URI begins with "info", then what does that mean the rest of everything is? It's not info? Like if I go to http://www.cnn.com/ and read some news there, then I'm not getting some info from there? Or what if I visit something like ftp://ftp.gnu.org/ ? Since I'm using FTP, the File Transfer Protocol, I'd be transferring some files, and let me think about what files are. Oh yeah, they're a way of storing info.
I've already seen this abuse of the English language on web pages. I am often given a chance to click on, say, "map", "contact us", "products", or "info". Well gosh, maybe I'm a bit confused, but I am sitting here looking at a web page, which must mean (if you ask Al Gore, etc.) that I'm on the Information Superhighway. And the stuff appearing on my screen doesn't seem to be a real, tangible object. It's not animal, vegetable, or mineral, so I guess it's information. But here is this link indicating to me that it is apparently the true source of "info", so I guess all this other stuff I'm seeing only seems like it's info.
Maybe if I click on it, it will give me some info that will help me understand this strange and confusing way of speaking.
I fail to see the practical utility of this proposal. Unlike existing schemes, this one is explicitly not designed to be resolvable. One must wonder, given that, what good it is.
this will ultimately lead to a sitation in which users end up paying for everything, and information being controlled more tightly. as it is people cannot even imagine that at one point of time domain names were free.... anyways, XML sucks big time for being so bloody complex.. XML is info for machines, not for people....good for automation and the big folks, not for people like me, u or anybody else.
The latter requires a new URI scheme (deployment of new URI schemes is expensive)
The latter requires a new registry
The other difference is that info: is not http:. But why exactly does a piece of software need to know that a URI identifies an "information asset"? HTTP URIs identify resources that may be (or may get or may have been) dereferencable using HTTP, no more semantics than that. Oh, and every organization (that would possibly want to register an info: namespace with NISO) already has its domain name.
Basically, IMHO it's cheaper (both for the organization and for the internet) if the org just creates a URI form (like the loc.gov above) and uses that.
Yesterday was the time to do it right. Are we having a REVOLUTION yet?
The "//" is not the beginning of a machine name.
Before I explain, let me get something else out of the way. Windows uses back slashes "\\" as the start of a machine name followed by "\" and a path. I'm not sure if that's what you were thinking.
That being said, the "//" is used to describe the network. What goes between these two forward slashes is the name of the network. If left empty, it defaults to the Internet. It's reserved for the next version of the Internet.
The info: tag is more closely related to the mailto: tag.
-=- Many seek good nights and lose good days.