CamelMan wrote to us with an interesting
story over at CNN. The Internet Engineering Task Force is apparently on a fast track to get the Common Name Resolution Protocol into place as early as next year. It will be, however, mostly aimed at intranets, and not at the Internet writ large.
Slashdot Mirror
Anyone want to take a bet that this doesn't make it out in the time frame above?
Ok -- I promise to fire up the search engine and learn more on my own right after this. Is this some sort of LDAP extension or is it more like a standardized crawler/search engine combo? Sorry for my cluelessness.
Save the whales. Feed the hungry. Free the mallocs.
This just might lower my administration tasks, not havning to worry about wins and DNS
IMHO, this new "common name format" is just another unnecessary layer. The main bragging point was that you don't to remember a long, complex URL; instead you can just type in a document name. The only problem with this is that if an intranet site is any good, you should never have to type in a URL at all. It's just a matter of a navigation interface that should be on the site anyway. For example, they said you could just type in "1996 budget report" instead of the URL. But if a site is designed correctly, you should be able to navigate to reports, then budget, then 1996. Or budget department, then 1996 budget report. This common name system just fixes something that isn't broken anyway -- the URL system. All it provides is an excuse for web site designers to be lazy about designing an intranet site (who needs nav bars? Just type in "memo from Robert T. Frog in Budget Department to Bob Q. Flair in the Widgets subcommitee of the Projects department on August 8, 1996!").
Friends don't let friends misuse the subjunctive.
I agree 100%
don't forget, if they try to port this to the web then they can designate another internic to control the sales of keywords. just like domain names.
completely unnecessary.
With this proposed standard set to eliminate the typing of "dots, dashes, and backslashes" to get to a page, it's unnecessary--I don't know about you, but I've never had to type a dash or backslash to get to a page.
Either that, or the clueless reporter is getting computer-related stories wrong again, which wouldn't surprise me in today's media. Are there *any* reporters that get it right?
I can picture Mindspring or (shudder) AOL setting up a CNR server for their users, so their users can access common sites and information sans URL. A mercenary ISP could even sell entries in their CNR database.
----
----
Open mind, insert foot.
Am I missing something? The whole reason URLs get hard to remember is because some sites are designed improperly and HTML documents are given cryptic names. But just as web maintainers fail to maintain an easy to remember document hierarchy, they will also be resposible (presumably) for setting up the common name servers. Inevitably, they will just make the same mistake once given this Common Name Format. (Ie, every large company I've ever worked with has had so much documentation that they had a numbering system for documents. I'd imagine this is what they'd use if given a Common Name layer. Is it that much easier to remember "RSV 1345 HM Control Interface Design Document" than "spudge/current/dds/" and grab the document from that directory?)
.. it's because technologies designed to make stuff "user friendly" only inhibit users from learning how to solve problems themselves. Techies on a mission to make everything easy for end users are (knowingly or not) contributing to the dumbing down of "end users" - I often charge M$ does the same thing. Hiding functionality behind a nice curtain only makes matters worse ... and just when the general public was starting to get the hang of things .... sigh.
At any rate, abstraction by way of layers like these only obfuscate matters more - and the keep the end users from having any clue whats really going on. The reason help desks get so many calls isn't cause people are stupid
"Old man yells at systemd"
It looks like the idea came forward from someone at realnames. I'm not particularly impressed with their idea. Just replace a URL with a simple text string... and whoever paid us most for that string will get the hit...
I don't think that people have much trouble in using search engines... Why not just put a search engine on your intranet server and have the home page set to that server?
It solves the problem of finding the 1996 budget report without knowing the URL... and it doesn't involve replacing browsers, adding in new servers or anything particularly complicated...
-- Under/Overrated is meta-moderation, and therefore is Redundant.
The article implies that a local/intranet registry will have to be maintained describing the mappings between human friendly names and URLs. So instead of remembering URLs, users will have to remember how the thing's registered in the local registry, quite possibly in a way that's not intuitive to them. A user might want the 1998 budget report and look for "1998 Budget Report," but the finance people might've registered the document in the local registry with a title that's only intuitive to them (e.g., "1998 Expenditures"?) and others in their field. A title that's intuitive to person A in discipline A might not be all that intuitive to person B in another discipline. Sounds like we'd be back at square one rather quickly.
There's a point at which we have to stop dumbing down computers and standards and start insisting on smarter users and smarter website maintainers (i.e., put a little thought into how documents and pages are organized). Perhaps we're reaching that point...
This is aimed at Intranets. Why? Because this is, in short, a way to connect web requests with a bunch of resources listed in a directory server such as an LDAP server, Novell Directory Server or Micro~1 Active Directory (coming soon to foolish corporations everywhere). "Common Name" or CN, is a standard part of X.400(?)/X.500(?) naming schema which are used in such directories. If you look at the contents of an X.509 certificate, you'll see it as part of a "Distinguished Name" or DN. Something's DN should uniquely identify it. For example, here are some DN's:
- CN="George Bush" OU="Texas Governor" CO="Republic of Texas"
So, allowing someone to type in a CN or partial DN into their browser is of interest to corporations in the near term, because many of them are already deploying Directory Services to centralize their information management.CN="George Bush" OU="Ex-President" CO="United States of America"
The "Common Name" proposal also contains RDF schemas to describe and search for documents based on CN's and partial DN's. This might have some applicability to widely distributed, nonarchic systems such as the web. Of course, RDF is a cutting-edge application of XML which isn't even fully ratified, so don't hold your breath.
Since you can register 1998 Expenditures, 1998 Budget, and any others that people are likely to look for, it won't be that difficult. Simply index _every_ way people try to find it, and if you find out they can't find it, register what they're searching for.
It looks like this could really be a good thing, in terms of standardizing access for search engines.
The Macintosh has its "sherlock" system right now, which lets you use the same UI to access a bunch of different search engines. Similarly, there's a way to provide an interface to Netscape so that typing in "? searchterm1 searchterm2" instead of a URL will work (the Google site describes how to configure Netscape to use Google for this). I'm sure there's something similar for Internet Explorer
A standardized interface for this sort of thing that all search engines and client software could agree upon would be a *very* good thing.
You could even end up with a hierarchical search engine -- if a site has a "robots" file that prevents it from being externally indexed, but *also* provides this unified interface, then some searches could transparently be forwarded to the site's own engine (eg. I could do a search on slashdot and get included up-to-date hits on freshmeat and linxutoday). This should do wonders for outdated links.
Seems more useful to build a quick site search. If you are looking for a 1996 Budget Report, there are bound to be a bunch of them on any decent sized company's intranet (i.e., one for each department, etc) so a CN solution could be painful ("Budget Report for 1996 for the Marketing Department" --oops, no, it's "Marketing Department 1996 Budget Report"...) but a site search would give you a whole set of choices right off. And it's a damn sight easier, too, than having to name all of your documents in every way that you think someone might try to access them...
- [A directory] does make storing vast amounts of hierachial data very fast, but so does
.. well, a file system.
I think you're thinking on the wrong scale.Let's say you're PricewaterhouseCoopers. You are the the recent merger of two huge companies that are over a century old. You have 150,000 people worldwide who need documents on everything from tax incentives in Botswana to OS/400 vulnerabilities. Even if you could organize all the data available in the firm, you'd never know when somebody who specializes in electronic banking might suddenly need to know about the Japanese fishing industry. File system? "Properly organized web site?" As if!
I've pointed it out before, but little of the slashdot readership has experience with enterprises on this scale, so I'm just offering some perspective from someone who does.
I think that this protocol would lead to sloppier web site design. Yes, I've looked for information before and wound up on a page with alpha(-numeric-)bet soup for a URL, but if the site (inter- or intra- net) was organized better it wouldn't have to be like that. If you needed an annual report, it would be great if you could just go to the company's website and find it in two clicks, or just go right to www.somecompany.com/reports/year.html It seems that whenever I'm trying to look for something that I think is fairly straightforward on a website, I have to jump through multiple hoops to find it.
great, mail to John Smith would go to how many people?BLOCK STRUCTURE breathing apparatus required for special maneuvers!!
To speculate and elaborate a little on Red Pen's "Reality Check" ....
.. yay. :P
... depends how this is implemented on the browser with regards to how results are handled/displayed.
... only under 1998 documents, for instance.) Each document will, I assume, have a full DN (distinguished name) that describes their location in the hierarchy (for example: ou="netscape.com", c="1998", c="Budgets", cn="Version 0.6") but if you search from say ou="netscape.com, c="1998", c="Budgets" as a search root, a search on Version 0.6 will return only the one record, since it must be a unique identifier (thus the name distinguished name).
:) Suggestions are welcome.
Presumably, as a sys admin, you have a web server running. Along comes your boss to tell you to implement the common name protocal. Here we go:
1. You set up some sort of Directory Server. This will store the mapping and define the category schema's of your intranet's store of documents. Depnding on how logical your file systems schema's is, your directory schema might be very similar.
2. You add entries to your directory server - one for every document you wish to be accessible by common names. Good thing about this: your entry names can contain spaces
3. Browsers, once they support it, will allow you to configure a directory server to point at (Netscape already does, for use with your address book).
4. Browsers will have functionality such that when you type in a document name, it searches said directory server, beginning at a particular root, for said entry. Results are returned, I suppose
5. You have do cocurrently maintain your filesystem in synch with your directory server, or alternatively, develop a tool which allows some sort of method to 'check in' a document to your intranet that handles the moving of the file to the proepr location on the file system and additionaly adds an entry to the directory structure reflecting its location in your document hierarchy.
6. Your end users only have to remember document names, not full paths, but they will get different results based on search roots. (Ie
Keep in mind this is a speculation of how it will be implemented. I have lots of directory server experience, but as of yet I have yet to see it implemented as a layer beween a brower and a file structure.
Hope this helps - it's not exactly a search engine, and it does end up in more work for the sys admin, as far as I'm concerned. And as always, I never suggest that I'm always right.
"Old man yells at systemd"
So I say - go Common Name Resolution Protocol!
I have two very large concerns with this. What sort of security measures will be built into this? XWZ Inc. might not appreciate an employee from ABC Inc. being able to type in "budget reports for XWZ Inc." and getting it. It also seems to me that this type of system would make internet censorship a hell of a lot easier to implement...
"What is now proved was once only imagin'd"
"What is now proved was once only imagin'd"
William Blake, The Marriage of Heaven and Hell
I think it's a ridiculous idea, b/c it appears to be now making a search engine of itself, because now, instead of finding your page (whether or not you (1) know it actually exists (2) know where it is (3) care that much to find it) you're going to get every bloomin' page out there with the remotest semblance to yours.. as implied in the article:
"For example, typing in the word "Apple" might bring up Apple Computer's Web site or information about growing apples, depending on the context of the request. "
Of course, I also note that the quote says "depending on the context of the request," but isn't that delving, still, into the realm of some sort of pseudo-AI, high-tech search engine? Is this necessary? Are we having soo many problems finding web pages? Or is it some attempt to make us think we're being "more efficient" (re: lazy) while really making us work more? Hmmmm.......
I think it's a waste of time, money, effort, and the lives of the members of the task/action team...and I personally don't like it one bit (could ya tell?)
Insert mind here.
Since WINS is essentially Microsoft's name for their version of NBNS (see RFC1001 and RFC1002), it's probably covered under DHCP's NBNS option (code 44) [see section 8.5]. If that doesn't work, send bug reports to Microsoft :-)
----
----
Open mind, insert foot.
the problem with your database approach is that it doesn't take into account that the data is (a) distributed (b) diverse /emailaddresses/world and type John Smith, well ... But if I'm in /emailaddresses/world/Europe/Sweden/Ronneby/SoftCe nter/IPD and type John Smith you will probably get an error because there's no such person at the department I work :)
It would probably work for something as boeings manual system (they probably have something like that) but you would basically have to do maintenance on both your server and client systems if youn would want to store something else.
I'm not sure yet what the common name resolution protocol exactly (the article was a bit vague on that and I don't feel like doing a search on the matter) is but I suspect it has something to do with organizing URL's into directories. Thus keywords have a context/directory specific meaning. If I'm in the directory
Jilles
Why not just have a common boomark file for all those interesed in calling things in a paticular context. I don't see a need to create a standard around this. To some degree what is being described already exists. i.e. If I want a link to a how-to faq doc for emacs I go to an emacs web site and click on the how-to or faq link. By going to the emacs webpage I've placed my self in the context of emacs and when I click on the faq link I should get an emacs faq.
I fear that this standard could eliminate a degree of freedom on the client side. If I use the pharase "emacs how-to" in the new system proposed, I have to rely on the fact that the person that created the database has selected the best emacs how-to source. I don't know that I would trust a stranger's expertise over mine in this area. Lord only knows the commercial abuse that could arise from this. I think sombody mentioned this in a previous post about a rouge ISP.
IMHO It seems at best this new idea eliminates at most one mouse click for those to lazy to do their own research.
BOFH, My model for being a sysadmin :)
Many people have argued that "marketing budget report 1996" is easier to remember than widgets.com/divisions/marketing/1996_budget.html, but two other points arise from this:
1. As many people have pointed out, the CN has to be typed exactly. So if someone said "marketing budget 96" or something then they wouldn't find it. Perhaps URLs, by making people remember the string exactly, actually make things easier to find.
2. In a well-designed heirarchy, nobody should have to remember a web address/CN anyway.
Friends don't let friends misuse the subjunctive.
Somebody moderate that comment up. And everybody heed this fellow's advice.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
The only way this is going to work is to have a large common database on the backend. How long is it going to take the banner ad/porn people to start seeding it with keywords?
How about this:
- ./
For end users, the standard means no longer having to remember or type in a series of dots, dashes and backslashes in order to find the information they need.
Umm, is it just me, or is a "series of dots and dashes" completely meaningless?
It sounds like the author has confused morse code and HTTP... I've never seen any url that looked like http://www.foo.com/..--.-\.-..-\..-\\-....--.-...
There seem to be people posting here who missed the context thingy mentionted in the article. It's basically a directory service they are proposing.
/world/US/companies/Boeing/products/747/manual/scr ew10990814097254.3 instead of www.boeing.com/lots/of/cryptic/stuf/that/changes/a ll/the/time/manual.html).
/world/europe/holland/citizens/hometown/me). Of course it should be possible to have multiple paths to the same directory so that the same directory can also be linked under the company I work.
I think directories are better than url's for one reason: URL are tied to physical locations and directories are not. For instance my email address jgurp@yahoo.com (don't flame please) is tied to Yahoo. If for whatever reason I would want to change provider, I would have to notify everybody I know not to use that address anymore. The same applies to documents. I don't give a flying fuck on which server company X has stored document Y, I just want to access it quickly.
The way I see it company X would store it's document Y somewhere and link one or more keywords in one or more directories to its location (i.e.
By using a local server access can be controlled. By linking the local server into another server (again under a directory), a global directory system can be created.
This also makes searching a lot easier. Unlike with domain names, it would be no problem for each individual to have a unique branch in this global directory tree (for instance
Jilles
...another internic to control the sales of keywords. just like domain names.
Exactly my fear. Imagine I have a site that deals with apples and pears. Do I have to register with someone so that people can find me? Will I have to outbid Apple Computers? Will I get sued for being referenced as "apple"? Who the hell is going to find MY site by looking up "apples and pears". I'm sure someone else has the same sick fascinations as I.
As far as intranets go, you should have enough control over internal documents that navigation to them shouldn't be that difficult. On big sites, an internal search engine works fine as well.
Sometimes I thinks these standards bodies just want to give O'Reilly another book to sell.
_damnit_
_damnit_
It's my job to freeze you. -- Logan's Run
Yes, URLs are not perfect, but when used
*properly* they are pretty good.
See http://www.w3.org/Provider/Style/URI.html
for examples of good URIs.
Although I haven't looked at the standard in question at all, I suspect that every site each has
different organization/categorization, so
any common naming system is going to suffer some of the
same disadvantages as URLs. Better to put
real usable navigation on the site instead...
This common-name-to-URL-mapping technology already exists. It's called `Altavista'.
Seriously, who ever types in URLs these days? I don't. They are all generated by Altavista searchs, following links, saved bookmarks. I don't think I am unusual in this either.
This common-name proposal seems to be Yet Another One of those marketing schemes designed to raise money without providing value in return.
If you go to Yahoo, and type in a keyword wherever, you would get their categories and entries. If you go to Netscape, you'll get theirs. If you go to your local intranet, you'll get documents on the intranet.
In other words: It's nothing that doesn't currently exist. The difference is that the standard will make it easy for a browser to give a uniform interface to a feature that is typically accessed by forms today.
But the problem here is that a global namespace would have an immense economic value. Want to bet why Centraal is so interested in this?
Everyone who is something will try to get a stranglehold on this market, to sidetrack DNS... Basically, if this catches on, peoples investments in good domain names will be worthless. Lots of large companies would like that, since it would give them a second chance at getting a good name. But needless to say, this is also a bad thing for lots of people with lots of money invested in their name.
Does anyone know how this relates to the long-in-the-works Uniform Resource Name standard? I thought URNs were supposed to replace URLs years ago.
[sarcasm ON] Where's the RFC? It cannot become an internet standard without being an RFC.
Several misconceptions here:
m l
1) This isn't LDAP and isn't related to X.500 (regarldess of the two using the term 'common-name').
2) CNRP based names are unstructured, flat (probably Unicode) strings. I.e. no-hierarchy. You can put slashes in the names but they won't mean anything to the protocol.
3) A given name can be accompanied by one or more 'contexts'. A context qualifies the name by giving the query some kind of scope. Two examples of
common contexts are locale (give me names that are valid only for this geographic region) and topic (give me names that are related to computing as opposed to agriculture).
4) CNRP names are not unique. This means that two entities can both use the same name (assuming you aren't using trademarks and then that just an issue for courts to decide). I.e. remember the 'pokey.org' thing? Well in that case both the kid and the cartoon character can have the same common-name of 'pokey'. Both would appear as a result if the provided contexts also matched.
5) You can get involved! The intent is that this should be an IETF working group (that's still pending). If you want to get involved then join the mailing list and do so. You can find the list archive and subscription details at:
http://lists.internic.net/archives/cnrp-ietf.ht
(Yes I work for NSI. No I don't pretend to speak for them since they don't pretend to speak for me.)
If you _like_ entering URLs and your brain is geared for remembering thing, then you're more
than likely not the intended user base. In much the same was that backbone router people tend to think about and use IP addresses more than they do domain-names, URLs will probably be used by us geeks more often than not.
When you think of who might get the most use out of CNRP think about your grandmother, your parents or your boss.
(Yes I work for NSI. No I don't pretend to speak for them since they don't pretend to speak for me.)
Well, I'd try Infoseek or something first, since AV gives such poor results, usually... But I agree with your point.
So with this groovy technology (term used loosely) would that mean that you would never have hyperlinks anymore, you just would click on any word and something would come up in your browser?
People are dumb. You and I can remember IP numbers, but people can't even remember URL names. We already have made it simple enough. Everyone that NEEDS this should be shot (ok, maybe that is my opinion, but it should be a fact). Now we are going to get a "better" system that will return more porno pages when I look up "C programming" or even more porn pages when those people who can't remember URL's try to look up how to make cereal. I have no problem admitting that the search engines now are not the best, but when that is the de facto, that will suck. I think that ultimately this will cause more harm than good. Computers are a useful tool, but they can't (and shouldn't) think for people. Cashiers can't even make change correctly without the cash register (... the cashier owed me 4 cents. She only had 2 pennies, but plenty of nickels. I gave her a penny and she looked at me like "What is this for?" For the next 5 minutes I explained that 4 + 1 = 5. The manager finally brought another role of pennies over. She gave me 4 pennies, I turned around and gave her 5 pennies, and she gave me a nickel! This happens to me all the time, so I assume that it also happens to you). If this system sounded reasonable (yeah it sounds good on paper, but so does communism) I would fully accept the idea, but after extended use of the computer, I have found that common sense/knowledge can not be replaced by a machine thinking for someone (yes I did use spell check, call me a hypocrite if you will, but if I had never used it, I would be a better speller). Computers can make things easier, but it seems as though this idea is just going to be another hassle for everyone involved.
Did anyone else catch the last line of the article?
"The Common Name standard could eventually be integrated with e-mail standards to allow end users to send messages without knowing the recipient's e-mail address."
Are you kidding? So, if I write an email message for my friend, then just type "Jason Smith" in the Common Name address field, it'll automatically figure out which Jason Smith will receive it? This sounds like just one more namespace that will quickly fill up and become even more confusing than http's for the regular public.
Why don't they fast-track IPv6 so I can get my own friggin IP addresses??
--Mid