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)
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?
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.
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
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.'
...and you can address (almost) everything! Look forward to a URI coming your way any time now..
--
What karma?
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.
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
The only things that need to be accessible is a list of the "namespaces" (i.e. the second-level bits). For example, it'll say that the "ddc" namespace is run by the Dewey Decimal Society (or whatever) and give their contact information. It won't resolve these URIs into resources, they way that a browser resolves a URL into a web page. (Though in some cases it may point to a resolver mechanism.)
Don't expect to type these into your browser and view the results. This system is more for tagging and identification, not resolution.
Wow! I didn't know that!
y wA AAAAMAAwU lvONmOZtfzgFz5 yLWGsEbtLiOSpy cQZXZeYGejmJlv KOzrcd3iq9uis1 cf5VWzXyym7PH
And it works with Mozilla !
Try selecting this text (taken from the RFC) and pasting it on a browser window!
data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///
AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvU
ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP
a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfn
ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtw
F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f
hhx4dbgYKAAA7
Does it work with IE too? (sorry, no Windows box at hand)
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.
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!