Slashdot Mirror

Agreed ... from RFC977, Brian Kantor (U.C. San Diego), Phil Lapsley (U.C. Berkeley) February 1986

"NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community."

Note: Usenet was not limited to TCP/IP. Before the internet was deployed we used modems, 800 numbers and uucp to transfer the article streams. The protocol allowed the receiving system to specify which newsgroups to fetch articles and updates from. Each server only fetched what it didn't have. And one shouldn't forget about the NNRP protocol used between server and clients which uses many of the same principles.

B.T.W. In unix land we used CRON to automatically schedule NNTP/UUCP updates.

Also from the RFC.."Such news provides for the rapid dissemination of items of interest such as software bug fixes,"

As for menu based stuff.. Virtually all of the old text clients RN, Tin, NN news readers had curses driven menus (text of course). Xn and large number of other news readers cover the GUI arena. Heck, I've been using the Agent since 1995.

The patent appears to have been filed in Apr 20, 2000.
Microsoft had their windows 98 update feature deployed long before that date.
I think that just about covers most of the Method and Apparatus claims.

As usual, the USPTO has once again demonstrated it's gross incompetence.

That's Apple's implementation of RFC 2324.

A method for distributing information to a plurality of uncoordinated user stations each of which is configured for communications with a multiplicity of independently-operated servers via a non-proprietary network...

yeah, it's called ftp (rfc959, 1985). Talk about ridiculous - hey, we invented automating ftp with scripting! g1v3 us m3g/\ m0n13z!

"Enhanced SMTP"? You mean, like ESMTP? Oh wait...

The recommendation, for all users of IPv6, including home users, is a /48. Fortunately, they've given you enough address space to get around their stingyness. You'd be stuck if they'd given you a /128.

RFC 3177 - IAB/IESG Recommendations on IPv6 Address Allocations to Sites

Not too many people remember v5. The IP version is a reference to the IP header "version" field, and 5 was reserved for ST2: See RFC 1819 Sesion 1.2, 2nd paragraph.

So what do you call the next IP version? Version 6, of course!

The only syntactic units which requires preservation of case information are: ... - local-part, except "Postmaster"

addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted case-preserved

Note: The reserved local-part address unit, "Postmaster", is an exception. When the value "Postmaster" is being interpreted, it must be accepted in any mixture of case, including "POSTMASTER", and "postmaster".

Note: This reserved local-part must be matched without sensitivity to alphabetic case, so that "POSTMASTER", "postmaster", and even "poStmASteR" is to be accepted.

If you run your own SMTP server, you can use mailbox aliases as described in the mail addressing FAQ.

Hmm. It seems I lose. I shall turn in my Powerbook forthwith, and begin using Windows ME as penance.

Damn those marshmellow-like marshmallows!

Cheers,
Ian

If the data format is clearly documentented, then it doesn't matter whether the application that generated it is open or closed.

So, you also need to define a format and design requirements for Universal Format Documentation, which is itself clearly documented in that format and meets its design specs, and is universally distributed. Hmmm... well, we seem to have gotten started... no wonder the Internet has done so well.

If the data format is clearly documentented, then it doesn't matter whether the application that generated it is open or closed.

So, you also need to define a format and design requirements for Universal Format Documentation, which is itself clearly documented in that format and meets its design specs, and is universally distributed. Hmmm... well, we seem to have gotten started... no wonder the Internet has done so well.

This post has largely turned into an attempt to pull up the most unlikely archaic technologies and make jokes about them coming back to the mainstream, but in actuality it's a very valid point.

PHP *isn't* the first language to come up with a lot of principles, that much is true. It isn't like it's even the first incarnation of the language in itself, it is simply the next version. But it adapts and improves a lot of the fundamental principles that were set down in languages such as Perl. That's not to say that it has totally superceded Perl, I know people will continue to use it for years to come, but it's taking the best lessons from languages like it, and moving from strength to strength. It's like many of the principles in books like "The Art of Unix Programming", which explains the importance of learning the lessons of good program design, and building on the very strong framework that Unix originally set down, all those years ago.

With the addition of the (admittedly proprietary) compiler, I think it has nowhere to go but up, and really can begin to match those dynamic languages which can run standalone as well as in a web context. It's certainly within business interests and finance to buy licensing, and if there is that much call for it, I'm sure someone could create a free software alternative.

Also, does anyone really expect their STUPID!@!!@ .log TLD proposal to be accepted?!??!!

Totally. We've been waiting since 1990 - 1990! for this, which seemed so great for so long, but sadly never was adopted.

:)

I'm amazed your post got past 2. What they call it has no bearing on the issue.
As others have pointed out, Internet Explorer does not meet a basic requirement of a browser. (Thank you, epsalon, for the summary.) For the link-impaired, RFC 2616 section 7.2.1 specifies that a browser isn't allowed to override a specified content-type, but IE does so regularly, and it's not exactly a secret. I was taught on day one of my first CGI programming class (which wasn't _that_ long ago, which is why I can remember) that IE does not handle text/plain correctly, so don't expect text resources to appear as intended to the end user.

[Tim Berners-Lee] works from several criteria: the system must be flexible and designed with minimal constraint so that it is compatible with numerous languages and operating systems; the system must be capable of recording random links between objects; and the system must be constructed so that entering and correcting information is easily performed.

To those of you on Slashdot who know what I'm talking about: are your circuits truly redundant? What have your experiences in network redundancy been?

I have two homing pigeons.

If Cupid smiles on them, soon I'll have even more redundancy.

In RFC 2606, example.com, example.net and example.org are reserved for testing. Therefore, I always use [somename]@example.com for my fake e-mail needs.

There's some good info here:

http://www.oreillynet.com/pub/wlg/4051

and here:

http://www.faqs.org/rfcs/rfc2606.html

According to RFC2606, the following TLDs are reserved for testing and specifying invalid addresses. The will never be used for routable sites on the internet: .test .example .invalid .localhost

I tend to use the .invalid suffix when posting to usenet, as do a lot of other people it seems...

On sites that have a legit need for my email address like Amazon, ebay, Newegg and others I buy stuff from I use Sendmail's plus notation (also known as the user+detail format) OR an alias on one of my personal domains. I use aliases quite a bit. That way I can remove the alias and shut off the potential (or actual) flow of spam to that address. It's easier to remove an alias than it is to have Procmail filter out mail to a given plus notation address. It always amazes me who gets my alias or plus notation email address over time. For example I may notice that I'm getting penis enlargment or mortgage spam from "networkcomputing@mydomain.com." Hmm... I wonder who sold the spammer that address... Hmm....

When filling in First name Last name fields I always use Marion Morrison. Before you Google for that name try to guess who's it is (ok, a hint, was).

I also understand that it's very common to use pres@whitehouse.gov, or so I hear. Another favorite is darl@sco.com

That's a really good idea, however I would change the username to webmaster or one of the other required usernames. root will resolve on any unix box, but what about all those IIS servers harvesting email addresses? You don't want to leave them out, do you?

It has the codes to create a new ng, but it doesn't seem all too clear on where you need to send them. Presumably, this is on purpose...

There's some more information here and all the information should be in RFC 1036, especially part 3.3 of the document.

Hey, man -- are you making fun of my network?

First, the root servers have different dns server software and OSes, not because Vixie thought of it, but because it is policy codified in the BCP RFC for root servers best practices. In fact, I think he was unhappy about other root servers using non-BIND software in the beginning.

Second, he is being disingenuous about his comments about patents, his company owns at least one patent related to the Verisign "Site Finder" service methodology. Nominum Patent I didn't see any statements by him disparaging his company when they applied for that patent. So it isn't that he doesn't like patents, it is that he doesn't like that Akamai is making money doing third party DNS without paying him money or homage. Note: His commercial, for profit dns server software company has a white paper enumerating the scalability and other problems with BIND, and they use an architecture more similar to DJBDNS than to BIND 9 - separate auth and resolving dns server packages, most modern dns server software uses this architecture to reduce code complexity and improve security and performance.

Third, if he wanted to be the pillar of dns server software that he supposedly is, he could have sent a few goons from Nominum over to Akamai and set up some boxes with his commercial, for profit, "scalable" dns server software and Akamai would have been able to see if his software was able to stand up to the ddos attack better than what they have. If it did, he probably could have gotten a sweet, lucrative contract out of it and been a hero for helping thwart the attack, rather than a hypocritical, self serving competitor hiding behind Open Source to appear credible.

Fourth, Akamai is a single point of failure because that is what they do - offload dns and content load from the biggest companies on the net life MS, google and ebay. No, I don't work there, but I would venture a guess that they carry more traffic than (maybe) any other company. So I am sure it is easy to armchair quarterback and say they should do this and that, but when the attacks are probably at 10's or 100's of GiB/s I am not sure what I would do.

Nominum is also involved in RFID stuff, so I will be interested to see what happens with him and his companies as that ramps up. And who knows what deals have already been made - "the future of DNS is right."

Some DNS software links:
nsd - high performance, uses BIND style files and authoritative only
They have an interesting testing procedure where they run nsd and BIND, have them build responses to the same queries and then analyze any differences: diff analysis
maradns
Powerdns, mysql and a pretty website
djbdns he's grouchy and the no license license thing freaks people out and pisses them off, but people become attached to the quirky but rock solid software.
nstx, ip over dns, yeah...

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

You forgot RFC 1149 - Standard for the transmission of IP datagrams on avian carriers. Then there's 748 and 1097 for amusing TELNET options, 1605 for SONNET to Sonnet translation, 2324 and 2325 for managing coffee pots, etc. RFC 1924 is one that's a bit more subtle in its humor. A google search for "amusing RFCs" will get a more complete list, since it's difficult to remember them all. :)

Not to worry! Someone decided that some of the most useful (and dry) knowledge on the 'net needed some (also dry) humor. Thus I give you: RFC2795, The Infinite Monkey Protocol Suite (IMPS)!!!

Thanks. No really. I'll be here all week.

When 2 ethernet NIC's transmit at the same time in normal operation we don't call it jamming.

I know what you're saying, but you may want to use a different example. From the comp.dcom.lans.ethernet FAQ:

[5.3] What is jam?

When a collision is recognized by a transmitting station, a bit sequence called jam is transmitted. This jam is 32 bits long, which is long enough to traverse the entire collision domain so that all transmitting stations can detect the collision.

Not only that, but it's also thought that the impacts of comets of asteroids may create pockets of heated water for extended periods of time, where life might emerge.

Try this one: RFC 1347. IPv9 is another name for the TUBA protocol (see here), which was apparently a competing proposal of IPv6 for big-number addressing with TCP and UDP that has never been put into broad use. Some people seem to think it's superior to IPv6 in some ways, but I was under the impression that it's largely deprecated at this point. Obviously some people are still using it - perhaps they are using it as an interim solution until they can transition to IPv6 (when everyone else does - which will be a cold day in hell).

The original RFC is here.

Actually IPv9 is TUBA. Which is described in RFC1347.

Why has it taken the world so long to take IPv9 seriously ?
It's the only protocol that has in-built, native support for RFC2549 and, more importantly RFC527.

Linus Torvalds has already announced that 2.7 will have kernel-level support for RFC2549, but maybe now the kernel developers will go the whole hog and adopt IPv9 ?

Why has it taken the world so long to take IPv9 seriously ?
It's the only protocol that has in-built, native support for RFC2549 and, more importantly RFC527.

Linus Torvalds has already announced that 2.7 will have kernel-level support for RFC2549, but maybe now the kernel developers will go the whole hog and adopt IPv9 ?

http://www.tianyigroup.com/zz-e/zz-e.htm
"IPv9 Datagram Head Protocol" standard of electronic industrybe carrying through "IPv9 Address Protocol"standard of electronic industrybe carrying through
ALSO (though it has been mentioned before), a humor article from 1994 regarding IPv9:
http://www.faqs.org/rfcs/rfc1606.html

Googling for IP V9 reveals an april fool's joke from 1994:

RFC 1606
RFC 1607

Googling for IP V9 reveals an april fool's joke from 1994:

RFC 1606
RFC 1607

Java becomes more like a usable programming language every day!

The functionality of mailcap, later cloned in win32, GNOME and KDE, is now available to Java as JDIC!

And JDNC provides powerful GUI functionality, including an XML format for describing GUIs, a la Glade, wxWidgets XML resource files, XUL , XAML. Of course, they are all completely incompatible. Also worth mentioning here is GNU Enterprise, which has seemingly similar aims to JDNC.

I don't know what all this has to do with ActiveX. For all I know, ActiveX was MicroSoft's intended replacement (or umrella) for Java and JavaScript. It has met with mixed success, having met with popelarity mostly as a malware target. JDIC and JDNC look like decent proposals to me. It's good to see Java maturing both in speed and functionality. The more choices, the merrier, after all.

One possibility for a lossy compression algorithm could be something similar to Progressive JPEG.

Rule of Modularity: Write simple parts connected by clean interfaces.

Rule of Clarity: Clarity is better than cleverness.

Rule of Composition: Design programs to be connected to other programs.

Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

Rule of Robustness: Robustness is the child of transparency and simplicity.

Talking to an SMTP server is easy. Don't believe me? Telnet to your ISP's smtp server (port 25, obviously) and send the bytes for "HELP". Poof, 99% of the time you'll get every command that server accepts. It doesn't take long to figure out how to use it, even if you are too lazy to read RFC 821 (start at "APPENDIX F" and I bet you're telneting email via telnet in 30 seconds or less).

But wait, were you telnetting *from* 25? Of course not. Yet, somehow, it still worked (likely only if your "rcpt to" entry had a local domain).

Malware can use any port they want to relay from a zombie box to smtp.openSmtpRelay.com 25 as well.

Another thread on this /. discussion deals with issues "underground" relays present, but just remember this -- the SMTP servers you're relaying to don't really care if you're sending from port 25. That's convention. You're likely to find SMTP at smtp.myisp.com's port 25, but it really doesn't make any difference, and even in some email clients it's an option to change.

It's issues like those described in that thread that'll help ultimately bring down spams. Telling malware writers to use another port, which is all Comcast's doing, as others have pointed out, will just have ISPs blocking ports until there are no more ports to block.

Er, that's a bit misleading, multicast is a broadcast, and more. A UDP broadcast packet will only travel on your local network segment, eg through every switch you're connected to and they are connected to.

A multicast packet will also be broadcast over your local network segment, and then possibly be relayed by multicast routers to nearby network segments that have registered an interest in the same multicast conversation.

See RFC 988, RFC 1112

Er, that's a bit misleading, multicast is a broadcast, and more. A UDP broadcast packet will only travel on your local network segment, eg through every switch you're connected to and they are connected to.

A multicast packet will also be broadcast over your local network segment, and then possibly be relayed by multicast routers to nearby network segments that have registered an interest in the same multicast conversation.

See RFC 988, RFC 1112

Technically, underscore characters are not allowed in host names according to RFC 952:

A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.).

Still it seems like a stupid idea to strip them out.

They also depend on what gas you put in the car. Some cars do drive better on supreme.

Higher compression engines, or more highly-tuned engines, need higher octane gas. Mostly, it's to prevent knocking (early detonation caused by compression rather than spark). Any good car of relatively recent make (at least the past 10 years, if not older) will have a knock sensor to adjust for lower-octane gas, at the expense of fuel usage. However, if your car is designed to run on 87 octane, higher test gas shouldn't make much of a difference.

Possibly this also has to do with the mountainous terrain and the fact that the gas gave me more power - not sure

Actually, there is less energy potential per gallon in higher octane gas than lower. That's not really an issue, though. What most likely happened was that previously you were not using the proper octane-level gas for your engine's compression and the ECM was adjusting to a less optimal program to compensate. As a side note, race gas and airplane gas have much higher octane ratings due to the use of lead additives. Don't try this in your car. Lead will kill your cats in a matter of minutes, not days or months. Race cars and airplanes don't have catalytic converters.

I do know that I regularly stick injector-cleaner in, so I shouldn't be getting plugged there. Therefore, I'm willing to state that better gas can give you better milage (and not all gas stations give the same quality gas either)

First off, most additives are snake oil. Pretty much the only thing that works is Techron (and knock-off brands using a similar formulation). If you fill your car at a station with Techron or a similar cleaning additive, there's no reason why you should have to add injector cleaner on your own. If you must, an application once or twice a year is sufficient. Any more often and you're just throwing money away. As for better gas giving you better mileage, that's true up to a point. As I mentioned already, higher compression engines require higher octane fuels. If you're not using the right fuel, your engine will operate inefficiently. Using a higher octane gas than is required is useless if your car can't adjust its compression ratios to make use of it (ie, putting 92 octane gas in a low compression engine like many American-made engines isn't going to help anything, while putting 87 octane in a high compression Porsche engine is going to give you poor performance and mileage). If it's bad gas you're worried about, the most common problem is too much water in the gasoline. You can solve this problem with an alcohol additive to "dry" the gas. Other problems like too much sulfur (I believe that was the problem recently with some gas down in Florida, among other places) don't have an easy remedy, and all you can do is stop driving, have the car towed, and empty the tank. Run a few tanks of good gas through the engine and it'll be fine.

As others have already stated in this article, there are many other factors to consider. Low tire pressure, dirty air filter, oil, oil filter, bad alignment, too much weight (of the driver, passengers, and any cargo), etc will all have an effect on your mileage. Also, most cars will get their best mileage at low RPMs. If you can cruise at 2000RPM, you're going to get much better mileage than cruising at 5000RPM (just be careful -- you're going to be in a high gear to cruise at such a low RPM, and trying to accelerate in that gear could cause you to lug your engine. This is more important in high-revving, low-torque engines than it is in low-revving, high-torque engines).

Links:

• HowStuffWorks on gasoline
• Gasoline FAQ

Yeah, the RFC isn't as specific as XML, but gives the principles