Talk:Internet Relay Chat

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Internet Relay Chat article.
Article policies
Archives: 1
Archive
Archives
Archive 1


Contents


[edit] Packetnews

This appears to be a malicious website. It tried to send several dozen spy cookies to my computer and launched several popups that bypassed the IE blocker. One of them played an audio advertisement, and something caused my computer to run out of memory and almost shut down--the first time I have ever had such a thing happen. Thus, I have removed it. It appears not to be very useful, anyway.--HQCentral 23:54, 10 June 2006 (UTC)

Full of copyvios too. -Barry- 00:06, 11 June 2006 (UTC)

[edit] Caps

Should this article be "Internet relay chat"? Isopropyl 11:47, 13 June 2006 (UTC)

Nope. --Ifrit 12:09, 28 June 2006 (UTC)

[edit] Double forward slash...

This is perhaps client specific. In mIRC, arguably the most popular client, this simply executes any identifiers inside the line following the command. Example //say $calc(1+2) will execute /say 3. //quit will just /quit. - BalthCat 01:24, 8 July 2006 (UTC)

mIRC is not arguably the most popular client, it simply is. The actual slash is client specific, the double slash is specific to mIRC and a couple of other small ones. It's completely feasable to set up mIRC with a different command prefix, ie '*'. If you connect to IRC directly (like through TELNET) there is obviously no command prefix at all.

--HoCkster 12:40, 21 August 2007 (UTC)

[edit] XDCC search engines

Should links to XDCC search engines such as IRCspy and Packetnews be in this article? I saw another objection to Packetnews but that was due to invasive advertising/spyware. Is it valid to exclude XDCC search engines because they could be used to locate copyright infringing materials, or not? I mean, one *could* use Google or an ftp search engine to locate such materials, as well. Such uses of XDCC search engines are probably more common than noninfringing uses, but xdcc offer scripts can share any kind of files, whether legal or illegal, I guess. Thoughts?

Guns can be used to kill people, and we still include information about them. So no, I don't see how it's valid to exclude them based on the legality or illegality of their use. Much like VCRs, XDCC searches are not, by definition, piracy, anyway. - BalthCat 13:36, 27 August 2006 (UTC)
Meanwhile, the article is about IRC—not XDCC, or even DCC. XDCC is a very indirectly related technology (a sub-protocol to a sub protocol), extensive coverage of which belongs, at closest, in the DCC article. In fact, it has its very own article. [Now that i've typed this, i notice that the original post is old. Oh well. It's a good point, so i'll post it anyway. :)]
—überRegenbogen (talk) 22:06, 15 December 2007 (UTC)

[edit] IM?

Isn't IM differentiated from chatrooms by the one-to-one focus of instant messengers (with, generally, their multi-party chats added second) versus the primarily channel based format for IRC? - BalthCat 00:42, 8 September 2006 (UTC)

I'd say that's accurate. madewokherd 21:47, 10 September 2006 (UTC)
I'm considering changing the opening paragraphy to read this way:

Internet Relay Chat (IRC) is a form of realtime internet chat. It is mainly designed for group (many-to-many) communication in discussion forums called channels, but also allows one-to-one communication via instant message.

- BalthCat 23:10, 10 September 2006 (UTC)
Good. It is important to understand that IM is technically a subset problem of group communication. IRC specifically addresses the problem of distributing group communication efficiently using multicast, which none of the IM technologies do. On the other hand it also delivers one-to-one messages along the network tree, instead of unicasting directly (which then DCC provides). This can be a disadvantage as it creates bottlenecks, but it can also allow you to communicate around network failures. Then again IM technologies do not unicast directly (P2P) either, they always go through a server. Thus using IRC with DCC is in the lead here, too. Too bad IRC has a whole different set of problems where the advantages of better routing are often not enough to compensate. -- SymlynX 11:46, 24 September 2006 (UTC)
While "IM is technically a subset problem of group communication" may be true in some strict sense, IM as the term is used today primerally implies messaging based arround a contact list. IRC is terriblly bad at this providing weak (or even nonexistant) enforcement of a users identity and forcing a client to poll for state changes in thier contacts (and worse poll each user individually if more than very basic information is desired). Plugwash 20:56, 25 September 2006 (UTC)
You're passing a value judgement on the requirement that I have an IM style contact list, and easy access to a person's profile information. I don't want or need it on IRC. And a /notify list is available in the IRC clients I've tried, on three platforms. IRC's lack of identity enforcement is notable, but I'm not sure it belongs in the header, and definitely not using "proper" and "poor". It's just different. NickServ and Notify are alternate methods of achieving similar things as contact lists and identity confirmation. - BalthCat 04:05, 26 September 2006 (UTC)
These days it's also a question on how much you enhance your IRC network with extra technologies: In many networks NickServ really enforces identity and some extended *Serv tools even provide for serverside buddy lists etc. Now the question is, will the client developers follow up on this and integrate these new interfaces? How many clients already present IRC contacts in a buddy list style? I know at least two. And of course there is also the question of how many IRCers reject the buddy list user interface and still de facto do instant messaging every day? By the way, you may be interested that the IRC network brasnet has recently started providing a PSYC/XMPP federation extension where every IRCer has a Jabber ID that goes nick@brasnet.org and is even looking into providing IM transports for their IRC users. --SymlynX 00:11, 17 November 2006 (UTC)
i haven't seen any networks where nickserv properly enforces identity, the norm is either not to enforce at all or to kick users off after a delay (allowing a short period in which impersonation or accidental reception of information intended for someone else are possible). Feel free to point out any major ones that do.
Its also not possible for a client to implement a decent buddylist (showing only people who are actually logged in, showing away status etc) with a decent update rate without either using network specific extentions (which client vendors are reluctant to do especially as the network with such features tend to be quite small) or exceeding the standard irc rate limiting (one message to the server every 2 seconds with blocks of up to 5 messages together). Plugwash 12:05, 17 November 2006 (UTC)
Alright, the auth time hole remains a classic IRC problem - however with the umode +r (registered user) you can for instance inhibit unauthed nicks to send/receive PRIVMSG at all. Don't know if any network is sufficiently consequent. Concerning PRESENCE etc of course new standards are necessary. Everyone doing it his own way is no solution. CTCP PRESENCE is a possible approach, as it doesn't have to be done in the server. But the general problem of getting all parties back to the table persists, those days seem to be long gone. I'm working on new stuff myself, actually.. --SymlynX 21:42, 18 November 2006 (UTC)
Some Services support an instant enforcement option.
—überRegenbogen (talk) 22:25, 15 December 2007 (UTC)

To my surprise, a new initiative exists at http://www.irc-plus.org which addresses these problems. --lynX 08:57, 19 August 2007 (UTC)

[edit] File sharing association?

That might be the case in certain places, but certainly not in Bulgaria. I don't think even most who use it here are aware it can be used for file sharing.88.80.99.27 15:10, 15 October 2006 (UTC)

       Crap guys, it's not the case in Bulgaria, I guess we need to remove it to appease the great Bulgaria.Titan124 (talk) 15:58, 6 February 2008 (UTC)

[edit] Networks and URLs

I'd recommend removing the list of "Some other IRC networks" from that section. Every single network with twelve users is adding themselves in there as a self-promotion -- and this is getting silly. The purpose of this article is not to list networks. We could keep just the big four and other networks can be added to Category:IRC networks. Or we could do a list of IRC networks if anyone feels like it is needed. DLX 19:25, 22 November 2006 (UTC)

As there are no complaints, I am going to remove that portion. Please discuss this here if you want to restore it. DLX 07:25, 24 November 2006 (UTC)


Yeah, too late. Just think, the networks listed are all english. I'v made a list based on country/language, with major ones. But ok, forget it. I agree this would soon or later lead to self promotion network, etc. --R2cyberpunk 21:15, 22 July 2007 (UTC)

If an extensive list of IRC networks is to exist, it should be a separate article. And there should be rules regarding inclusion (e.g. minimum population).
—überRegenbogen (talk) 22:33, 15 December 2007 (UTC)

[edit] Bouncers!?

Why did 24.200.103.9 remove the paragraph on Bouncer (IRC)? They are a relevant phenomenon of IRC since IRC doesn't provide identity protection. They are considered uncool because they raise the overall load on the network, but that too is an IRC specific problem caused by its distributed real-time database, which is generally a bad design thing. So being against bouncers (and bots) is beside the point. --lynX 14:20, 4 December 2006 (UTC)

Considering it was deleted by an anon with no edit summary i'm assuming it was vandalism (or a newbie not understanding our interface) and reverting it as such. Plugwash 01:37, 5 December 2006 (UTC)

Cuz for some reason vandalism always happens!!

[edit] Piracy

Itsnot a con of IRC, its a pro, thats why they made P2P, its harder for FBI etc. to interfere. SOftware prices are too high, so why blame people for file sharing!! Realg187 17:25, 6 December 2006 (UTC)

WP:NPOV Rstandefer 17:49, 6 July 2007 (UTC)
lol, I find this man to be honest at his upmost 65.70.239.216 21:54, 20 July 2007 (UTC)

[edit] plaintext!?

User EuroCave added this passage

IRC was originally a plain text, although later extended[1] protocol ...

I wouldn't say the extensions take it away from being a plain text protocol. Even though the inofficial CTCP extension uses some 0x01 bytes, it is not necessary to support them to have a conversation over IRC. I'd even argue IRC is more plain text than most other protocols as it still doesn't support internationalization in form of character sets. —The preceding unsigned comment was added by SymlynX (talk • contribs) 09:36, 24 December 2006 (UTC).

While there is no standard mechanism for declaring what content encoding you are using (and a client-side method that does not piss people off would be a trick), UTF-8 (which still counts as plain-text) passes without trouble over the IRC transport (in messages and channel names), and is fairly readily identifiable by a receiving client. (Nicks, however, remain strictly 7-bit on most—if not all—networks.)
Meanwhile, markup beyond VT-100 or ^B,^_,^V,^C type-styling is generally frowned upon, and completely forbidden in some channels.
—überRegenbogen (talk) 22:47, 15 December 2007 (UTC)

[edit] Missing or misdocumented Information? / Lack of IRC related wiki info?

For instance, I noticed several instances of the wiki IRC channels explicitly prohibiting this 'public logging' term which doesn't appear to exist (in wiki word searches). I think it matters, maybe this matter is more complex than is required for a wikipedia? PS I'm staying away from editing until my edits stop being undone for whatever reason. -Kristan Wifler —The preceding unsigned comment was added by 71.112.51.232 (talk) 10:13, 27 December 2006 (UTC).

[edit] Discussion of less savory IRC characters.

I think a section needs to be added about the servers fight, expecially mainsteam ones like DAlNET and Undernet, against less savory types, such as Child Pornographers and Pedophiles. It seems like DalNET had a problem with these types back in the late 90s, and is worth a mention.

- Tiger. —The preceding unsigned comment was added by 68.114.139.37 (talk) 05:35, 18 February 2007 (UTC).

[edit] history?

The history/evolution section of this article is terrible. A list of protocol versions with unexplained numerical referencing doesn't make a history. Could someone who knows about the early days of IRC please add something useful? How did the use of it evolve after its creation? Thanks.--Ibis3 14:46, 1 March 2007 (UTC)

I have collected a few documents at http://about.psyc.eu/IRC#Historic_Documents (oops I mentioned that link before.. nevermind) but it would take some time to sit down and make something truly encyclopedic out of it. Technical evolution did indeed have quite an impact on life on IRC - like the introduction of channel operatorships, it made the until then easy-going socially almost flat chat a hierarchical one, and attitudes became rougher and channel operatorships became reason enough to attack servers. And before that I remember when we didn't have alphanumeric channels yet, but does anybody really want to know? --lynX 22:47, 2 March 2007 (UTC)

[edit] Trimmed See also list

I attempted to trim the "See also" list to something more relevant. The change was reverted. I believe as a style choice the see also list should be contain directly relevant links and should be small as to be more useful. The external links policy has some application here.

For example there is a list to IRC services then a list to individual services. A list to the services categories is sufficient. Same thing with games. What do you think? Daniel.Cardenas 19:09, 2 April 2007 (UTC)

If you look at the differences, then there are no external links among those that you removed (diff). There are some, that definitely do not belong there - such as "Alternatives" section (for some reason XDCC was there...), some of the services needed to go (LoveServ??!), but overall, the links that you removed were to good wikiarticles that had highly relevant and useful information about IRC. You even removed link to mIRC, which is by far most common IRC client! I do not understand what was the basis for your classification to relevant/irrelevant, as you removed mostly IRC-related links and kept not related links.
I recommend that we'll revert the list to what it was before and discuss what needs to be removed and what kept here before doing drastic changes. DLX 19:24, 3 April 2007 (UTC)
This is a page about IRC not IRC clients. There is a link or two to IRC clients if someone wants to know more about clients. That is why mIRC or anyones else's favorite IRC client was removed. Do you have objections about anything else that was removed? Daniel.Cardenas 19:49, 3 April 2007 (UTC)

DLX: I wasn't able to edit below your edits. You may want to try/investigate. I suggest you go ahead and make your recommended changes. On second thought maybe it was just a preview problem. Daniel.Cardenas 02:23, 5 April 2007 (UTC)

I would recommend this:

(moved list to the article)

(unordered - ordering and perhaps additional structure might be needed) DLX 06:58, 4 April 2007 (UTC)
  • There's still a number of unnecessary links there IMO:
- Comparison of instant messaging clients - Not necessary? The ones which support IRC are listed in the "comparison of IRC clients" anyway
- Comparison of IRC services - Is a direct link to this relevant? Surely it's enough to link "IRC Services"?
- mIRC - One specific IRC client shouldn't be linked. Already indirectly linked twice via comparison/list of irc clients plus a direct link in the article itself
- OmenServe - One specific script of one specific client definitely shouldn't be here
- Serving channel - Relevant/notable enough to be linked here? Doesn't seem so to me...
- XDCC - 50/50 on this since it's derivative of DCC which is also listed. Why list this one but not SDCC?
I'd rather see those links removed and the alternatives brought back with a proper "Alternative protocols" sub-header.
ExNihilo 21:02, 5 April 2007 (UTC)
I must disagree rather strongly with you. While "Comparison of instant messaging clients" may be not needed, all others are (edit: maybe XDCC and OmenServe, too). This is a "portal" or a "start" page, ie. people come here, read about IRC and want/need to have links to pages that are relevant to IRC. Instead of trimming this list further, I would recommend that we'd try to find more information about history of IRC (for some reason, it is now called Evolution??!) and technical data. In the future, a separate articles may be needed for them. DLX 13:19, 6 April 2007 (UTC)
  • I've removed the "Comparison of instant messaging clients" and "OmenServe" links. Perhaps the "comparison of IRC services" and "serving channel" links have some merit. Hopefully others can give their thoughts on the "mIRC" and "XDCC" links before anything is done about them. Also, in thinking about it the "alternative protocols" list I suggested probably isn't necessary since it's better covered by the "comparison of IM protocols" link anyway. - ExNihilo 15:45, 8 April 2007 (UTC)

I don't see any reason for specific clients to be listed. Daniel.Cardenas 16:22, 8 April 2007 (UTC)


[edit] Quit Message Errors

Should we include a list of them and describe them or should they go on a new article? (07:53, 23 April 2007 (UTC)) —The preceding unsigned comment was added by Robotboy2008 (talk • contribs) 09:53, 23 April 2007.

I'm not sure they are needed. They are IRCd-specific and there are simply too many of them. Although... tbh, list of them with detailed explanations would be very useful - definitely in a separate article, though.
On a separate topic - I wonder, if WikiProject IRC would be needed/useful. The topic is definitely complex and notrworthy to merit a project of its own. DLX 08:00, 23 April 2007 (UTC)
Okay good idea. Started 1. Wikipedia:WikiProject_IRC. Neal (talk) 13:51, 6 April 2008 (UTC).

[edit] List of IRC channels

I miss some coverage of major IRC channels. Ten years ago I was active on #Norge on EFNet wihch during peak hours had more than 600 concurrent users. I also remember a channel called #Daytraders which had over 1,000 users. I have always been frustrated by the near impossibility of going out to look for busy IRC channels that cover some particular scene or subject. It would be nice if this article could provide some information on this, the content aspect of IRC. __meco 19:57, 6 May 2007 (UTC)

Feel free to create a list of channels, if you want to, but as a separate article, please. Also, let me point out that owners of those channels may not be happy about listing their channels en masse in easily accessible and "semi-official" place. Many older IRCers remember crackdowns on channels who had publicity in mass media. DLX 05:33, 7 May 2007 (UTC)
I'm not currently an IRC user, and besides, I was only thinking of such channels that might not object to being listed in such a way. It's merely a suggestion for someone who would know of any such reliable lists or surveys in existence. __meco 06:05, 7 May 2007 (UTC)
I'm not sure I see the point to be honest. Channels simply having lots of people in them is hardly something noteworthy, and in many cases not considered a good thing (ie. how can 1000 people chat on a single channel unless most of them are idle anyway), so it's not really something that has a particular reason to be included in an encylopedia. For people that want to know there are sites like http://searchirc.com/ that deal explicitly with these kinds of queries. I don't know of any specific channels that have such a history or noteability that they warrant encyclopedic entries of their own, so it seems unnecessary to list channels based solely on arbitrary metrics like largest, busiest, or oldest. - ExNihilo 18:08, 7 May 2007 (UTC)
I think http://searchirc.com/ might partly answer my query. I cannot see this site mentioned in any Wikipedia articles yet. Perhaps it ought to be? __meco 20:29, 7 May 2007 (UTC)
What about netsplit.de? - Jigsy 03:35, 11 May 2007 (UTC)
That also seems to be a useful resource. __meco 07:26, 11 May 2007 (UTC)

[edit] Image:Screenshot-XChat- Moniker42 @ FreeNode - -ubuntuforums (+tn)-1.png

Sorry, for not writing this in the right form, I only want to let you ppl know, that the screenshot is kinda funny, if you read the text there: wikipedia s****, maybe someone can edit this, thanks, and greets from lotp.de —The preceding unsigned comment was added by 85.182.119.230 (talk • contribs).

It's funny. And why did you put asterixes over the word "sucks"? 66.24.104.37 21:07, 29 August 2007 (UTC)

[edit] Culture

I'm often asked "what is IRC", I explain... it's then responded with "Yeah, but what is IRC all about?"... My only answer is that it's more of a culture, not just a "chat room". I think something needs to be noted in this article with regards to IRC culture. --Hm2k 11:23, 17 June 2007 (UTC)

The one thing that IRC is still very special in, is the culture of idling in large channels. The way you stay connected in real-time with everyone on a particular topic has hardly been addressed by other technologies, either because it simply doesn't work (scalability issues as in the case of XMPP), because a suitable user interface is not provided (most IM systems and webchats), because the problem of SPAM is not sufficiently dealt with (public Skype rooms could actually be used like IRC channels, if it weren't for SPAM and other issues) or simply because it isn't known (we do plenty of productive idling on PSYC, but nobody knows but us). So, yes, I think it is a good idea to elaborate on the useful culture of idling in a separate document from idling.. Idling (Internet)? Then link to it from those technologies who enable that. --lynX (talk) 12:00, 2 April 2008 (UTC)

[edit] Why some much client-specific?

At many places in the article, there are descriptions of commands. But why are they prefixed with forward slashes? That's not how IRC, the protocol, works. That is purely client-specific. I'm sure there are clients that does not use the forward slash this way. BESIDES from Netcat/Telnet ;-) Consider removing the forward slashes. 81.231.71.96 16:10, 12 September 2007 (UTC)

Well, aside from telnetting in directly a few times (irritating), I've never seen a client that used no symbol, or another symbol, to prefix commands. They are, if they exist (you yourself say you are sure in a sense that sounds like you are assuming) in the minority, and anyone reading the article in full would have read:

"In most clients users can enter commands by prefixing them with /; depending on the command, these may either be passed directly to the server (generally used for commands the client does not recognise), passed to the server with some modification or handled entirely by the client."

I think that covers it sufficiently. - BalthCat 05:39, 15 September 2007 (UTC)

The article, though, does seem to consistently conflate (oxymoron!) the protocol with client software. For example, "Channels in a server can be displayed using the command /list [#string] [-min #] [-max #] that lists all currently available channels" should probably be "Channels in a server can be displayed using the command LIST [#string] [-min #] [-max #] that lists all currently available channels". GracenotesT § 02:12, 18 September 2007 (UTC)

I think you're assuming IRC is merely a protocol on top of TCP. It's also the name of the whole system that the user interacts with, and most users will never have anything directly to do with the protocol. To document IRC's behaviour in terms of the commands sent to the server would be like explaining the concept of blind carbon copy in the article on email by explaining RCPT TO. Marnanel 17:37, 5 October 2007 (UTC)
Commands for IRC client software are based very much on the protocol. After being on IRC for a couple of months, the RFCs were very easy to understand. /whois = WHOIS, /list = LIST, /who = WHO, /mode = MODE, etc. Conversely, using Gmail for a couple of months did not make me an iota more familiar with SMTP. IRC clients may abstract the protocol somewhat, but not very much. The big picture is commands being sent to the client to the server, server to server, and server to client; not how clients parse commands the user enters and how it displays results. Internet Relay Chat client software might be appropriate for the latter function, if it existed. GracenotesT § 22:18, 5 October 2007 (UTC)

[edit] opped?

Opped is used in the article, but I can't find a definition or link. — qwip 71.230.106.167 12:40, 5 October 2007 (UTC)

Rewritten. Marnanel 17:52, 5 October 2007 (UTC)

[edit] Accessing irc://irc.freenode.net/ with MS IE

Halló!

I would like to join IRC channels at irc://irc.freenode.net/ as #mediawiki-i18n when working on a PC without Firefox and / or Chatzilla where I have no admin rigths to install these programms.

What normal url's can I access to join the channels when I am allowed only to use Internet Explorer 6.0.x and Java?

Thanks for your help in advance! Best regards · please email me · Gangleri · Th · T 13:41, 23 October 2007 (UTC)

See the Java IRC toolserver app, this should probably let you get online. Nihiltres(t.l) 16:16, 23 October 2007 (UTC)
Thanks a lot for the help at #wikipedia-en-help!
IRC @ Work makes the job. Maybe also Visual IRC.
Best regards Gangleri · Th · T 21:42, 24 October 2007 (UTC)

[edit] Bash.org

How is there no mention of bash.org? I'm adding a link. 24.174.190.156 05:13, 8 November 2007 (UTC)

[edit] Opinion

"There is a small design fault in IRC regarding modes that apply to users on channels", To me this sounds like somebodies personal opinion. Could somebody with authority on the issue weight in? Also, the example provided isn't very clearly stated.--20:05, 25 January 2008 (UTC)Aliby22 (talk)

  • Well I'm not an authority but there is certainly a flaw in the protocol as it is defined in RFC 1459, RFC 2812, and as it is traditionally implemented. The issue is in the two RFC's definitions for RPL_NAMREPLY (numeric 353), which is:

    "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"

    Which, in the RFC's pseudo-BNF, represents: a channel name followed by 0 or more nicknames which may be prefixed with an @ sign or a + sign.

    The "or" is the source of the issue because RPL_NAMREPLY is sent to a user when they join a channel to tell them who is on it and what their status (op, voice, etc.) is. Because the RFC says it should respond with only one prefix this means that IRCds (including the original reference implementation) only provide the highest status level for a nick even if the nick has other statuses aswell. So if Bob joins after Alice has been voiced and opped, Bob will only be notified that Alice is opped. Which of course causes problems if Alice is later de-opped since she will be voiced without Bob knowing it. It's worth noting though that some IRCds now respond with all status prefixes in RPL_NAMREPLY and as far as I know all major clients support that capability. - ExNihilo (talk) 17:06, 26 January 2008 (UTC)

[edit] "A IRC network"

There were a number of places in the text that said things like "a IRC network". Does that mean that someone out there in the world pronounces IRC as "irk"? The Wednesday Island (talk) 18:25, 3 April 2008 (UTC)

(Actually, it doesn't work either way, does it?) The Wednesday Island (talk) 18:36, 3 April 2008 (UTC)

I certainly don't. I guess you can change them all to "an IRC network." Neal (talk) 14:04, 6 April 2008 (UTC).

[edit] Interserver IRC Protocols

The article says For a discussion of the evolution of server-side IRC protocols and the various IRCd incarnations, see the separate article on IRC daemons yet then it goes into deep techie details about timestamp vs. delay, not of interest for any IRC user, let alone someone who just wants to understand what IRC is and what can be done with it. Should everything related to interserver IRC protocol move out to that other document? --lynX (talk) 17:04, 9 April 2008 (UTC)


[edit] the 5 layers tcp-model

It's quite obvious that IRC is an *application* and therefore is in the application layer. The article does not cover anything about TCP or the layer model and I think it's quite pointless to have a table regarding this in the article. —Preceding unsigned comment added by 84.60.22.157 (talk) 10:51, 29 April 2008 (UTC)