Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet

IETF Draft Sets up Public Namespaces 184

Posted by michael from the true-names dept.
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!!"
This discussion has been archived. No new comments can be posted.

IETF Draft Sets up Public Namespaces More

IETF Draft Sets up Public Namespaces

Comments Filter:

  • Dibs (Score:5, Funny)

    by dze ( 89612 ) on Tuesday September 30, 2003 @11:38AM (#7095083) Homepage
    I call dibs on the pr0n:// namespace!

    • Re:Dibs (Score:1)

      by malx ( 7723 )
      > I call dibs on the pr0n:// namespace!

      Quite.

      One big flat namespace for domains for namespaces is good...how?
    • new tld: .xxx
    • I want: /.://
    • No, not pr0n://pr0nID, but info://pr0n/pr0nID. All of these new URIs will begin with "info://".

      And since your request was poorly formatted, it is I who call dibs on the info://pr0n/ namespace. MWAHAHA!

      • Re:Dibs (Score:3, Informative)

        by FireBreathingDog ( 559649 )
        Not to be pedantic, but it seems that the new URIs begin with:

        info:namespace/namespace-path

        The "//" construct is usually used to signal the start of a machine name, whereas the following slash is used to signal the start of the path on that machine.

        In this case, the notion of a machine is not used; it is more abstract than that. Hence, no "//"...

        We now return you to your regularly scheduled program of Microsoft-bashing and templatized joke-recycling...

  • Verisign (Score:2, Interesting)

    by pfifltrigg ( 689684 )
    Just wait until someone like Verisign gets a hold of this. Utter chaos!

    • Re:Verisign (Score:1, Funny)

      by Anonymous Coward
      Just wait until someone like Verisign gets a hold of this. Utter chaos!

      Wait until Microsoft geta a hold of this. An "all" namespace!
    • Something tells me we won't have to wait long.

      Next new thing: Namespace Squatting!

  • Slashdotted (Score:2, Informative)

    by Sir Haxalot ( 693401 )
    Google Cache [google.com]

  • Proposal for the IETF... (Score:4, Funny)

    by grub ( 11606 ) <slashdot@grub.net> on Tuesday September 30, 2003 @11:40AM (#7095103) Homepage Journal
    URI <info:slashdot/flames/windows/nt/bluescreen>
    URI <info:goatsecx/hello>

  • I'm really confused (Score:5, Insightful)

    by Gizzmonic ( 412910 ) on Tuesday September 30, 2003 @11:42AM (#7095143) Homepage Journal
    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".

    • Re:I'm really confused (Score:5, Informative)

      by axlrosen ( 88070 ) * on Tuesday September 30, 2003 @12:08PM (#7095393) Homepage
      Arbitrary key names are now URIs?

      Uh no.

      There will be ONE new top-level scheme, "info". It will have (presumably a small-ish number of) second-level "namespaces". Each namespace will be a well-defined system run by some organization. So you could imagine an ISBN namespace, so a URI might look like "info:isbn:0465026567".

      The "info" scheme, and therefore the list of namespaces, will be controlled by an existing standards body called NISO [niso.org]. It's their job to impose the discipline on these URIs. End-users won't get to create their own - only NISO-approved bodies with a well-run namespace can add to this system. Sounds like a good idea to me. I can rely on the fact that any legitimate "info" URI will be well-organized and sensible, I hope.
      • 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.
      • Hmm.... info:ebay/xxxx (whatever)
        or info:weather/06186 (hartford,ct)
        or info:ustel/800-867-5309 (jenny)
        or info:upc/3951080030 (sobe oolong)
        or info:mac/00:30:48:21:97:62
        or info:whois/slashdot.org

        Interesting.
      • The thing is you don't need much organisation here. Everyone is capable of creating and running a namespace. If it is useful, people will use it. If someone abuses it, they won't. There are already some non-server-based namespaces: ed2k and magnet for P2P, as well as others. Everyone can have a program that uses "URIs" in these namespaces, and even without control from NISO everything works fine.
      • How long until info:isbn:0465026567 points to Amazon.com due to copyright infringement?

  • Domain squatters (Score:1, Insightful)

    by jmerelo ( 216716 )
    That mean there'll be domain squatters in many different levels. And for free!

  • So who do I pay (Score:5, Interesting)

    by antirename ( 556799 ) on Tuesday September 30, 2003 @11:44AM (#7095158)
    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?

    • Re:So who do I pay (Score:5, Informative)

      by MerlynEmrys67 ( 583469 ) on Tuesday September 30, 2003 @11:53AM (#7095250)
      Don't bother yet. Realize that this is an initial draft (you use all .0 software right? - Same goes for standards documents) AND an individual submission.

      I haven't looked in on the politics of this one but there are two kinds of individual submissions

      1 - Any idiot can mail something properly formatted to internet-drafts@ietf.org and get it published as an internet draft... don't believe me look here Individual Submissions [ietf.org] - you will find this draft somewhere on this page

      2 - A working group is looking for a new working group item - so they ask the author to post an individual submission so they can consider his work before making a decision - These actually become RFCs

      Want a clue on WG items in the ietf - they come in the form draft-ietf-WGName-topic-rev.txt - The key is to not be fooled by people that post draft-ietf-lastname-topic-rev.txt

    • > So who do I pay to get a namespace registered? ICANN? Verisign?

      National Information Standards Organization (NISO) :

      http://info-uri.niso.org/info-uri-policy

      (Section 4 of the document)
    • WRT identification/resolution, I think it's similar to the nntp: URI. When you omit the server your software defaults to your preferences, which may include a payed for nntp server for alt.binaries.* etc.

  • Yay! (Score:1)

    by MasTRE ( 588396 )
    Just what we needed! Quick, someone publish 10000 pages on the XML schema to implement it!

  • important info (Score:5, Informative)

    by ih8apple ( 607271 ) on Tuesday September 30, 2003 @11:45AM (#7095168)
    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.)
    • Great :-( Now spammers will have a whole new way of getting to us without our being able to trace them(since info:// is not guaranteed to resolve to anything). Then there's squatters, faked A records, etc. This is another "solution" looking for a problem. Why not fix smtp first.

      If this ever comes about, I want the info://yhbt resource :-)

    • Re:important info (Score:4, Insightful)

      by sreilly ( 5153 ) on Tuesday September 30, 2003 @12:57PM (#7095898) Homepage
      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

      There is a big difference between not requiring a resolution mechanism and not assuming a resolution mechanism. It may very well be that a client knows how to resolve info:dcc/* but not info:ssn/* URIs. The point is that info: URIs will identify objects, rather than specify one location where a digital instance of the object may be accessible.

      URIs have become the de-facto standard for referencing documents on the Internet. Don't you think it is more useful to reference documents/objects by their unique ID rather than a URL where one instance of that document may reside?

      As for not being useful without a resolution mechanism... are you saying that ISBN's, SSN's (if in the USA), and UPC barcodes aren't useful? This URI scheme simply provides a way to identify objects (digital or not) using a common identification scheme. The resolution mechanism can be added after the fact (or not, depending on the type of object, or how it is used).
      • As for not being useful without a resolution mechanism... are you saying that ISBN's, SSN's (if in the USA), and UPC barcodes aren't useful? This URI scheme simply provides a way to identify objects (digital or not) using a common identification scheme. The resolution mechanism can be added after the fact (or not, depending on the type of object, or how it is used).

        GUIDs have no built in resolution scheme yet look at how universally useful they are...

    • Re:important info (Score:4, Informative)

      by iabervon ( 1971 ) on Tuesday September 30, 2003 @01:19PM (#7096097) Homepage Journal
      These URIs (not URLs) are used to talk about data, not to access it. For example, the info:isbn:12345 namespace can be used to refer to books; then you can give such a URI to Amazon and they'll charge your credit card and ship you a physical book. The idea is just to have a single unit that contains both the ISBN and the fact that the number is an ISBN, so that computers can reliably recognize ISBNs (etc) rather than determining it from context (easy to lose) or guessing from format (easy to mess up).

  • Oh, great... (Score:5, Funny)

    by MouseR ( 3264 ) on Tuesday September 30, 2003 @11:45AM (#7095170) Homepage
    With addresses like URI:, I'll spend more time on the phone trying to help my mother get where she needs to.

  • Um.. (Score:5, Informative)

    by Phroggy ( 441 ) * <slashdot3@NOsPaM.phroggy.com> on Tuesday September 30, 2003 @11:47AM (#7095190) Homepage
    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?

    • Re:Um.. (Score:3, Informative)

      by vlad_petric ( 94134 )
      How exactly will browsers implement this new protocol?

      With the mighty Konqueror you only need a new kio slave :). The others will require a plugin (a very simple one actually)

    • Re:Um.. (Score:3, Informative)

      by Qzukk ( 229616 )
      RTFA: its not a URL, it explicitly says that it "should not" be assumed to point at anything.

      It is simply a standardized (by NISO) format for identifying something. Like the example given in the /. post:

      "info:lccn/2002022641" becomes the only way to refer to the given LCCN as a URI. No worries about "should it be 'LCCN', or 'LibraryCongressControlNumber', or should the number come first, or is 'lc' enough to let people know that its a library of congress number"... it explicitly sets the proper formatti
      • NISO assumes the responsibility of making sure that if the Library of Congress is using "lccn", then the Literary Clubs of Congo Nationalists cannot. And thats it. Thats all this does.

        And the Congolese should be quite happy to accept such a ruling from a National standards organisation because ......

    • Web browsers probably won't implement this protocol. There might conceivably be an "Info browser" that would browse various classes of namespaces, but they would hardly be useful.

      The only point here is to standardize object transaction namespaces for various fields. It is altogether fitting and proper that we do so, but it's not really an end-user protocol.

      Take the Library of Congress book classification system (this or Dewey Decimal make good examples of "how" because the implementation would be trivial,

  • Some further possibilities (Score:5, Interesting)

    by jezor ( 51922 ) on Tuesday September 30, 2003 @11:48AM (#7095200) Homepage
    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

    • Re:Some further possibilities (Score:5, Insightful)

      by Fnkmaster ( 89084 ) on Tuesday September 30, 2003 @12:09PM (#7095398)
      Yes, and unfortunately, like other semantic web-style proposals, it will take about 5 minutes to be abused so much by people trying to harvest clicks and user attention that it will rapidly become useless. If we can't rely on users to accurately list meta-keywords in HTML documents, why would any other such identifiers work better, without some sort of meaningful web-of-trust system built in?


      Just a thought. I would hate to go looking for info:palm/model/P80900US and find 8 million links to people trying to get me to surf over to their porn site.

      • Re:Some further possibilities (Score:5, Funny)

        by Greedo ( 304385 ) on Tuesday September 30, 2003 @12:12PM (#7095430) Homepage Journal
        Just a thought. I would hate to go looking for info:palm/model/P80900US and find 8 million links to people trying to get me to surf over to their porn site.

        No, that would be "info:palm/hairy"
      • The poster you replied to had it right, and you took a left turn.

        info:palm/model/P80900US isn't a *LINK* to anything. It's a way of encoding "this is a Palm model P809.."

        If you think about it as a way to standardize the syntax of meta-keywords to make them more searchable, you'll be closer to the intent...
        • I never said that a URI was a link to anything. I realize that this new info URI is just a standardization of metadata, which is why I referred to the semantic web, another attempt to standardize metadata. I've been trying to explain for years to various people that XML URIs are not necessarily actual HTTP accessible resource addresses, and I always end up in futile discussions on the topic. Too confusing for many people, when people invent descriptive URIs that look exactly like resource locations in a

        • Re:Some further possibilities (Score:2, Interesting)

          by Anonymous Coward
          Actually is gets worst: since people abuse the meta-tags, if the metas get more precise they'll just abuse the system with more precision (hence some keywords will become absolutely useless because of such abuse).

          One example: you can't search for "anime" anymore without getting thousands of pr0n sites (if I search for "anime" I don't want "hentai" - anime is a currently abused keyword used by pr0n sites).
      • Actually, this kind of identifier would probably be easier to protect under trademark law than domain names, since there would be little way for the "URI-squatter" to argue that he wasn't referring to Palm's products when he incorporated "info:palm/model/P80900US" into his site. {Jonathan}
        • Arguably true, but we're back to square one, relying on a centralized arbiter of authority to issue and manage use of the info namespace. Who gets to use info:palm? What if another legitimate trademark holder on "palm" in a different field wants info:palm? Don't richer metadata schemes that are not strictly hierarchical, for example something based on RDF or the "semantic web" achieve the same results with fewer issues and opportunities for confusion, more opportunities for distributed trust, and a lesse
      • There is one thing you do not see here. There doesn't have to be a standard way to resolve such links. Your application can select the appropriate one (and so you can select what results you get). In case of "info:palm/..." link, your browser can be set to go to pricewatch.com or to amazon.com or just open your e-shopping application that would use XML to get results from different sites and present them to you. Alternatively you can install a helpful InfoBuddy that would redirect all such links to the most
    • info:palm/reader/lines


      Now you bring up a great possibility. Would the above belong to Palm or to Hand Readers Anonymous?

  • This is bad (Score:2, Insightful)

    by Cranx ( 456394 )
    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

    • Re:This is bad (Score:3, Insightful)

      by valdis ( 160799 )
      It's only dumb if you are thinking of using it for resolving actual Internet resources. In fact, if you actually *read* (gasp, shock) the draft, it's *really* about providing a *SYNTAX* so you can represent things like a Dewey Decimal number or a product number or the VIN of your car or....

  • It's Already patented. (Score:4, Funny)

    by jpvlsmv ( 583001 ) on Tuesday September 30, 2003 @11:49AM (#7095207) Homepage Journal
    Check out URI:<info:USPTO/patents/12345666789>

    --Joe

  • There are only a bit over 17000 TLA's and there already are 3 candidates for DDC (according to www.acronymfinder.com)...

    • Dewey Decimal Classification
    • Defense Documentation Center for Scientific & Technical Information
    • Department of Design and Construction (New York City)

  • info:ddc/22/eng//004.678
    is better than
    http://www.ddc.com/22/eng/004.678
    • Because the URL is a single Web page; the URI is an identifier that can be incorporated to every single Web page that fits the description. URLs and URIs do two different things; the former is a pointer to a file; the latter adds descriptive depth in an ideally universal way. {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:
    • DDC is a acronym for the Dewey Decimal System.

      www.ddc.com is apparently a hostname.

      info:ddc/22/eng//004.678 is talking about a *DEWEY DECIMAL SYSTEM* number, *NOT* a URL on a host.

      Consider this:

      info:temp/C/23

      Thats talking about a *temperature*, not a website called temp.

  • Way cool?! (Score:2, Funny)

    by antic ( 29198 )
    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!!

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

    • So what would be the new way of saying "way cool" oh grand master of current pop culture?

      The term "Cool", like a T-Shirt and Jeans, is timeless(ok at least in the past 50 years or so). No matter what the passing fad may currently be, it never seems to go out of date.

      Nifty, Groovy, Neato-Torpedo, Phat, Fly, Funky-Fresh, etc on the other hand...
  • ...and you can address (almost) everything! Look forward to a URI <info:RDID/433935473983> coming your way any time now..

    --
    What karma?

  • The URI namespace is already quite broad and has many ways to define "public" namespaces, usually based upon the URN [ietf.org] 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 [ietf.org]). You also have RFC 3151 [ietf.org] 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

  • 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

    The "info" Registry will be publicly accessible and will support discovery (by both humans and machine

    • 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 identificat
  • With the data uri scheme [rfc-editor.org], I can include the whole internet in my URIs!
    • Wow! I didn't know that!

      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/// y wA AAAAMAAw
      AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUU lvONmOZtfzgFz
      ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5 yLWGsEbtLiOSp
      a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfny cQZXZeYGejmJl
      ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwv KOzrcd3iq9uis
      F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo9
  • 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?

    • Yes, they do identify resources, or things. No, they don't tell you how or where to find them. This is the difference between a URI and a URL. A URI is just a name that identifies something, and that something doesn't even have to exist in the electronic world nor be reachable over the Internet.

      It is always up to applications to determine what to do, if anything, with a URI which is not also a URL. It is foreseeable that Mozilla could develop a "info" uri plugin model, whereby a plugin could be writte

  • Here we go again. (Score:3, Insightful)

    by inertia187 ( 156602 ) * on Tuesday September 30, 2003 @11:56AM (#7095276) Homepage Journal
    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?
  • Perhaps the Dewey Decimal classification isn't the best example. After all, it's not in the public domain [slashdot.org].
  • A while back, as my company was/is migrating from Netscape 4 (which supports telnet:// and rlogin://) to Netscape 6/7/Moz 1.X, I investigated what was up with the fact that Mozilla and all its derivatives no longer support telnet:// or rlogin:// on Unix machines. What I found was pretty disturbing. There is a section of the code, that is OS specific, that is supposed to handle "extensions" to the URI tags. Windows implements this by digging into the OS registry, pulling out the right executable, and call
  • I bet the RDF advocates (here's a primer [w3.org]) 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.

  • Potential for abuse by stupid people (Score:4, Informative)

    by jezor ( 51922 ) on Tuesday September 30, 2003 @12:03PM (#7095356) Homepage
    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 [tourolaw.edu]
    • Government agencies are restricted regarding whether or not they can ask for your SSN to use it as an identifier. Shortly, they must include a Prvacy Act Disclosure Notice [cpsr.org], which will describe which law allows them to ask, whether or not you have to comply, and what will happen if you don't.

      Private companies, individuals, etc. are not subject to these restrictions at all, so you could potentially see some abuse there. However, just as there is no law that says companies can't ask for your SSN, there's no

    • That's a really good point and probably a very likely scenario considering some people who probably don't consider themselves "stupid people" damn-near post the SOC in their ./ sig.

      *sigh*

  • David Brin... (Score:3, Interesting)

    by el_DemeNTe ( 712132 ) on Tuesday September 30, 2003 @12:04PM (#7095358)
    uses something similar to this form of information addressing in a book called "Earth", which he wrote in 1990. Essentially, he used what seem to be either ISBN plus some other alphanumeric identifier when the main character pulls up the "screenshots" that appear in the book's text. It is almost scary to see the parallels between this and what he was "predicting" for the internet.

    When I first read this article, it was the first thing that came to mind. (Maybe because I'm reading it now! :-)

    -el_D

  • Hah! (Score:2, Funny)

    by el_flynn ( 1279 )
    URI info is belong to us.


    ahem.

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

  • 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!

  • UR* Jungle... (Score:5, Insightful)

    by oren ( 78897 ) on Tuesday September 30, 2003 @12:32PM (#7095657)
    Quick, without peeking at the answer [w3.org], 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 [ietf.org] 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...
  • 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 [doi.org] 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.
    • doi comes with a resolution system, based on cnri's handle system. You pay to get a prefix.

      The info scheme will probably include doi as a namespace info:doi/ although the doi people want to get "doi:" in as a top-level uri scheme.

      every item assigned a doi has to go into the doi registry; with info, only the namespaces will get registered
  • I'm registering <info:*/*>

    Call me Verisign-boy
  • The Dewey Decimal System is a highly protected trademark of Online Computer Library Center [oclc.org] -- use it without paying a license fee, and they'll sue you [oclc.org] (another story) [newsday.com]

    From their FAQ: May I use the DDC to organize information on my Web site? [oclc.org]

    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 us

  • Why not URN? (Score:5, Insightful)

    by Fastolfe ( 1470 ) on Tuesday September 30, 2003 @01:51PM (#7096387)
    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?

  • This is ridiculous! (Score:2, Insightful)

    by getnuked ( 595037 )
    Everyone will become totally confused, not only because this is a new obfuscated URI scheme, yet because there is a .info TLD [afilias.info]!
  • This is a great idea. Google is great for random information especially third-party info on something, but getting to an exact document can be very difficult.

    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 sp

  • 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.
  • What is the difference between, say, http://loc.gov/lccn/2002022641 and info:lccn/2002022641?

    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 organizati

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close