Slashdot Mirror

Can you find prior art? A published description of using a single DNS wildcard for user's subdomains prior to 8/99?

So the technology was patented or just the method? The technology is described here: RFC1034 or RFC1035

So then we need an implementation that can take advantage of multiple subdomains using a wildcard, prior to 1999. This will show it's possible to do what the patent describes without inventing new technololgy /writing new software:

Apache mod_rewrite
So in 1997 it was definitely possible.

So we need someone actually doing it, so the method wasn't invented by them either (I've only done a quick search on google here)
These two links: Google Group, and http://www.geocrawler.com/archives/3/417/1998/2/50 /2275350/. So there you go, prior art, or at least close enough to prior art. The can't patent this technology or idea. The best they could do would be to perhaps claim copyright on a particular implementation, but I doubt that would hold up either.

This is an urban myth which I would like to dispel.

WHAT HAPPENED TO THE SATURN V PLANS
Despite a widespread belief to the contrary, the Saturn V blueprints
have not been lost. They are kept at Marshall Space Flight Center on
microfilm. The Federal Archives in East Point, GA also has 2900 cubic
feet of Saturn documents. Rocketdyne has in its archives dozens of
volumes from its Knowledge Retention Program. This effort was initiated
in the late '60s to document every facet of F-1 and J-2 engine
production to assist in any future re-start.
The problem in re-creating the Saturn V is not finding the drawings, it
is finding vendors who can supply mid-1960's vintage hardware (like
guidance system components), and the fact that the launch pads and VAB
have been converted to Space Shuttle use, so you have no place to launch
from.
By the time you redesign to accommodate available hardware and re-modify
the launch pads, you may as well have started from scratch with a clean
sheet design.

This is, of course, a reference to RFC 3514, which in my humble opinion was the best April Fool's joke on Slashdot last year.

Ulrik

I'm renaming it to FireAvian, so it's compatible with RFC 1149

Are the MD5CRK folks trolling, smoking crack, or just not explaining themselves very well?

They "aim to disprove one of the fundamental requirements of a secure message digest: No two inputs can be found which produce the same digest - this is also known as a collision."

MD5 gives a 128-bit digest. There are more than 2^128 possible messages. Of course there are collisions. What MD5 claims is that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations.

No digest algorithm can claim to be free of collisions; they are many-to-one mappings.

1. Replication of programmer effort.
   
2. Increased startup time (precaching is non-free)
   
3. Most importantly, the assumption that the images contained in the SVG files are rarely changing is untrue. It (initially) holds true for the icons in your desktop theme, but not for much else (web pages, and streaming remote GUIs!!).
   
4. The closer the system comes to following the UNIX philosopy, the smaller individual "applications" will be. Therefore the cost of XML<->AST conversion (which is performed at each application boundary) grows larger the more componentized the system is.

RFC3251 - Electricity over IP

rfc 1149

The only man in the middle attack is going to be some guy in Alabama with a shotgun. I think I'd know if it were intercepted.

Samsung's patent
Further information from the JPEG FAQ

And who says that a program that experiences fundamental errors but limps along anyway is a good thing? Is it going to hose my data?

I cite the Rule of Repair (Repair what you can -- but when you must fail, fail noisily and as soon as possible.) from "Basics of the Unix Philosophy".

A Standard for the Transmission of IP Datagrams on Avian Carriers (Pigeon) .

Only Groove puts all of those functional possibilities in one package. It's really THE P2P package.

And that's one of my problems with it. The Unix Philosophy had some really good rules, like #1, #2, and especially #6. Or "Make each program do one thing well".

Groove users I've seen only want to do one thing: automatically replicate a directory amoung distributed users. That's ALL they want. Oh, wait... they don't even want that. The majority just want to read a file that somebody else has told them is available through Groove.

As far as OS lock-in is concerned, this is the gov't you're talking about. They don't really get locked in.

None of what you just said re OS-lockin is relevant, unless Groove has Linux and Mac versions hidden away that they don't advertise. (If it uses ActiveX, then it probably doesn't!). Any agency which standarizes on Groove, then, is standardizing on Microsoft Windows, which is a national security risk.

New math number candidates:

• Bin Laden Number
  
• Bush Number
  

You'll note that the parent mentioned that CRAM-MD5 is sufficient for protecting passwords.

How CRAM-MD5 works: server generates a random string and sends it to client along with a timestamp. Client takes random string and password and uses them as a key to a keyed hash function to compute the digest of the timestamp. Client then sends digest to server, which performs the same operation and compares the result.

The idea is similar to other digest authentication protocols except that it uses a keyed hash function to hash a known string rather than hashing a concatenation (or XOR or whatever) of the password and the random data with a traditional, non-keyed hash function. Apparently, the keyed MD5 hash provides better cryptographic security, but protocol-wise, the result is the same: only a digest is transmitted and the digest cannot be replayed. The security of the system depends on the non-reversibility of the hash function.

The parent poster makes an excellent point that SSL is rather overkill for POP/IMAP since CRAM-MD5 can protect your password and you gain little encrypting all the traffic as most smtp is clear-text. I've seen smtp servers that require START-TLS for receiving all mail, but these were accidentally misconfigured smtp servers that were not receiving the majority of mail for users. The CRAM-MD5 rfc points out that this still doesn't prevent tcp session hijacking (which ssl does prevent), and one can spoof a server without the PKI ssl implements, but I wouldn't worry about either of these points when reading email.

Details in rfc 2195.

In the sweepstakes for legislative stupidity, I always like to play this card. The bill House Bill No. 246, Indiana State Legislature, 1897, reportedly set the value of pi to an incorrect rational approximation (ie. "3").

The "creator" of this new value of pi listed as it advantages that it was much easier for school children to use. He even went so far as to offer the new value of pi at no charge to Indiana for use in their school books, however all others would be charged a royality!

Here is a link, but a better link is here,

Interjecting humilitating criticism in the midst of a debate is just the kind of thing Nazis did in Germany.

Well, I guess this thread is official over, now, wouldn't you say?

You are thinking of RFC1483 (Multiprotocol Encapsulation over ATM Adaptation Layer 5) which is obsoleted by RFC2684

1483 Bridged does have lower overhead than PPPoA or PPPoE, but it sends broadcasts down the wire, both IP and Ethernet type. Depending on your network this could waste more bandwidth than PPPoX. 1483 Routed solves this, but you need ot allocate more IP space to use it.

It's all a horse a piece.

ft

You are thinking of RFC1483 (Multiprotocol Encapsulation over ATM Adaptation Layer 5) which is obsoleted by RFC2684

1483 Bridged does have lower overhead than PPPoA or PPPoE, but it sends broadcasts down the wire, both IP and Ethernet type. Depending on your network this could waste more bandwidth than PPPoX. 1483 Routed solves this, but you need ot allocate more IP space to use it.

It's all a horse a piece.

ft

The current TCP/IP implementation is described in RFC 2001.

The problem addressed by both that document and this new paper is that an individual computer sending data onto the internet has no idea what the total bandwidth to its destination is, nor how many other users are trying to use that link. It has to guess. And if it guesses too high, then not only will that computer drop some packets (forcing them to be resent later), but other users of the network will experience needless drops too. (The computer's guess at the bandwidth number is sometimes called "congestion window")

According to RFC2001, the computer keeps on gradually (linearly) racheting up the bandwidth it assumes the link can sustain, until a packet is lost (indicating that bandwidth has been exceeded). Then the assumed size is cut in half, and transmission resumes. This means that if you graphed the computer's guess at the bandwidth along side the actual avail bandwidth, it'd look like a sawtooth below the actual level.

The problem there is if you've got say a 5 megabyte file, and a 500 megabit link, it might not send AFAP because by the time your computer learns there's 500 megabits available, the transmission is over. That's especially likely if the line has both high latency and bandwidth. Many people have tried to avoid that problem by increasing their guess faster than linearly, like exponentially. But that may be unfair to other users of the network, squeezing them out and hogging bps for yourself.

Rhee's proposal is hopefully a way to allow super-linear acceleration, without stealing away too many packets from everyone else. (Remember that everyone else will eventually all be using the same scheme)

My bad %-) For the benefit of those who don't RTFRFCs, RFC1149 - Standard for the transmission of IP datagrams on avian carriers. Laugh, if you must, but RFC1149 has been successfully implemented. Need QOS? No problem - RFC2549.

My bad %-) For the benefit of those who don't RTFRFCs, RFC1149 - Standard for the transmission of IP datagrams on avian carriers. Laugh, if you must, but RFC1149 has been successfully implemented. Need QOS? No problem - RFC2549.

3) Arrogant advocacy. This is the worst one. OS/2 died in part because most people in Team OS/2 were assholes. Linux advocates are no less impolite. Face it, no matter how much you argue the point, the average consumer will NEVER believe that Linux is the holy salvation of mankind. Yet you still continue to argue that. "Linux? Oh yeah, that's the OS with all the arrogant jerks..."

Amiga Persecution Complex: n.

The disorder suffered by a particularly egregious variety of bigot, those who believe that the marginality of their preferred machine is the result of some kind of industry-wide conspiracy (for without a conspiracy of some kind, the eminent superiority of their beloved shining jewel of a platform would obviously win over all, market pressures be damned!) Those afflicted are prone to engaging in flame wars and calling for boycotts and mailbombings. Amiga Persecution Complex is by no means limited to Amiga users; NeXT, NeWS, OS/2, Macintosh, LISP, and GNU users are also common victims. Linux users used to display symptoms very frequently before Linux started winning; some still do. See also newbie, troll, holy wars, weenie, Get a life!.

...you could even order your coffee from the computers while you listen. Further more, the protocol already exists - rfc2324

Another place to try contacting for a *potential* flat-panel C-Band satellite panel is here. The Alien Works, Ltd. website is at Alien Works, Ltd. but it only has a PDF file that's been there for several years. I don't know if they'll ever have a commercial product, but it's worth a try. Also, for C-Band/TVRO satellite newbies, try reading the TVRO FAQ.

From the website FAQ:

I don't want to learn another syntax. Now what?

There are other options: it is possible to create the music in another format. Supported formats include

* MIDI: LilyPond includes midi2ly, a program that translates a MIDI file to LilyPond.
* ETF: LilyPond includes etf2ly, a convertor for the Finale ETF format (about ETF)
* ABC: LilyPond includes abc2ly, a convertor for the popular ABC format (about ABC)
* MusicXML. Guido Amoruso's xml2ly will convert MusicXML to LilyPond. (About MusicXML.).

I want to have an Graphical User Interface!

We have no time to also make a graphical user interface. Luckily, other people have filled the gap. The following programs have competent LilyPond export functions and are actively being developed.

* NoteEdit
* RoseGarden

There are also different, non-graphical interfaces:

* RUMOR is an interface to generate LilyPond input with a MIDI keyboard.
* LyQI provides a piano-like keyboard interface using the normal keyboard in emacs. It can also use RUMOR.

Bottom line is, lilypond is a base layer to build up on, see the Unix Philosophy.

Three words: IMAP, FastMail, Thunderbird

You know, if ISPs made it easier to implement this particular solution, rather than requiring we run our own email servers to do it

Thanks for the lesson.

--Mike--

Will we now see Photorealistic Renderman come out for OSX and the G5? Hopefully?

Interesting... i thought to myself, what about BMRT as a renderman compliant renderer, if there is a Mac version, for those not wanting to wait for Pixar or Apple. But now www.bmrt.org doesn't seem to be resolving, and any results Google gives back seem to be a bit dated.

Then i read the renderman faq and found this tidbit:

Exluna, Inc.'s "Entropy" renderer was the commercial big brother of
BMRT. But that really doesn't do it justice -- it was very fast and
efficient scanline renderer that also supports ray tracing, global
illumination, area lights, and caustics. More Info from:
http://www.exluna.com. Entropy was used on Star Wars Episode 2,
Stuart Little 2, Reign of Fire, Blizzard, Hero, The Returner, and The
Core. Entropy and BMRT was discontinued after Pixar sued Exluna and
several of Exluna's founders.

That's sort of sad. Well, there's always POV-Ray Though it does aim towards RenderMan compliance.

Have you looked into this?

yup its pretty disgusting. I havent actually done that since some all nighters 10 years ago (reheating filter coffee rather than waste energy making a whole new pot). Apparently you can get decent coffee this way though, using a cold brew process.

Anyway I don't need a command line for making coffee - its already online.

Subject: Pig iron [Was: Article: Gates memo calls for security focus]

On Fri, 18 Jan 2002 15:16:08 GMT, Alun Jones <alun@texis.com> wrote:

>In article <u0O18.81315$Sj1.32399626@typhoon.ne.mediaone.net> , Simon Chang
><schang@quantumslipstream.net> wrote:
>>It remains to be seen whether Gates & Co. continues to treat inadequate
>>security policy and implementation as just public relations issues.
>

>In Microsoft's favour, look what happened when Gates wrote a memo suggesting
>that the company should get with the Internet. Complete U-turn on the part of
>the whole company, with a huge emphasis on Internet development. What Gates
>says, goes. Just maybe those doomsayers within Microsoft who have been saying
>yes, but what about the security angle? (I presume there are some) will now
>be listened to, and their recommendations acted on. I certainly hope so.
>

I fully admit, it is a Great Leap Forward, just like another one in history...

http://www.asiaweek.com/asiaweek/magazine/99/0924/ cn_economy.html
+Mao launched the Great Leap Forward program in 1958, arguably the greatest
+economic folly of the 20th century. To help China surpass the economies of
+Britain and the U.S. in 15 years, he decreed that every Chinese should
+produce smelt iron. Hundreds of millions of citizens neglected farms to make
+low-grade pig iron. Beijing did not know that grain was rotting in the fields

Why the above quote? Check out the language Mr Gates uses in his letter
( see the register
http://www.theregister.co.uk/content/4/23715.html
). Remind you of the announcements of the old five year plans from
the old Soviet and Maoist regimes? Even down to the use of catch phrases!

If Microsoft's Management is serous ( and given their past pronouncements
on the security of their products - thats a very big if ) , it is a
Herculean but not impossible task ahead. It will not happen overnight.


Microsoft Makes Software Safety a Top Goal - January 17, 2002
http://www.nytimes.com/2002/01/17/technology/17SEC U.html
+Every developer is going to be told not to write any new line of code, Mr.
+Allchin said, until they have thought out the security implications for the
+product.

YES !!! Finally, but a little too late since almost all of the core OS and
application code has already been written.

Microsoft should have started this process three years ago.
The attempt to turn their current inherently designed insecure products
into a trusted system is like that of turning a sows ear into a silk
purse. The result is more likely to be pots and pans into useless,
unsaleable pig iron. A lot of the core design for many of the products
is going to have to be rewritten.

As for Trustworthy computing See

Avoiding bogus encryption products: Snake Oil FAQ ...
http://www.faqs.org/faqs/cryptography-faq/snake-oi l/
... the warning principals apply as much to secure software
products as it does to cryptographic products.

For software to be Trustworthy it requires that both the source and
build processes be verifiable by public inspection by peers in the
industry. That *requires* an unrestrictive license such as open
source (

So, riddle me this, is this really that much different from RFC 2554 - SMTP Service Extension for Authentication. Perhaps it would just be a differnt authentication mechanism (STAMP-M$). One would have to assume, give the relay nature of SMTP, that the stamping operation would be between the 'local' SMTP server and one's mail client. Of course, one would need a compatiable client. On top of that, would not the SMTP server need to do the same calculation (server overload!) to compare the answers or will it have some sort of shortcut or dictionary? If the server will have a shortcut all a spammer would need to do is get a hold of the dictionary/shortcut and we are back to square one.

Also, even if you could 'secure' the 'stamps' does that really fix the problem of other relays that are open? In order for the 'stamping' to work ALL SMTP servers would have to participate, because all it would take one hole and spam would continue to flood in.

Why don't we start with basic authenticated SMTP. It's been a standard since 1999. Then pressure your local ISP to harden their relays. That way spoofing email will be tougher, then spammers could be flushed out instead of being able to hide in the shadows. And since bandwidth is not free I'm sure ISPs would not have a problem denying spammers when they find them.

Do you mean a system like the one defined in RFC1149?

A friend of mine is doing this himself using parts from a website (the name escapes me) and drivers that he is writing himself. I also ran into this a while back. It looks like a lot of work, but considering how much a system like this would cost, its probably a pretty fair bet for experienced hackers with some spare time.

RFC 1958 - Architectural Principles of the Internet

Which RFCs is that?
rfc1034 seems to allow that (section 4.3.3)
I will grant you that this was not the intent of the RFC to allow a loophole which can break the DNS, but mistakes do happen.
Perhaps a case can be made that wildcarding is not allowed for gTLDs. This is open for interpretation.
My opinion is still that Verisign sucks and should be taken down.

Yeah, Microsoft.com has a record, too. Has since early this morning when I checked after this article was posted:

$ host -t txt _ep.microsoft.com
_ep.microsoft.com text "<ep xmlns='http://ms.net/1' testing='true'><out><m>" "<mx/><a>213.199.128.160</a><a>213.199.128.145</a> <a>207.46.71.29</a><a>194.121.59.20</a><a>157.60.2 16.10</a><a>131.107.3.116</a><a>131.107.3.117</a>< a>131.107.3.100</a>" "</m></out></ep>"

You just didn't bother to read the spec; the TXT entry goes in a "_ep" subdomain rather than in actual domain.

(Of course, underscores are actually illegal in domain names per RFC 1034, so that doesn't help much.)

Yes, indeed!

I went to add the appropriate entries to a couple of my domains, and started getting errors up the wazoo!

From RFC 1034, on allowable names:

They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

For more information, see Verisign's page information regarding using other characters in domain names, which includes the RFCs for their proposed encoding scheme for additional characters.

Stupid Microsoft! Their "Caller ID for Email" specification cannot even be implemented.

Traceroute and ping are included with Windows. Hell, finger is included too! Other things like whois, dig, etc. can be done on Windows the hardcore way. Put netcat and some RFCs (for reference) on a floppy and send straight protocol commands.

Does this version of the protocol support RFC 2423, the HTCPCP (Hyper Text Coffee Pot Control Protocol)?

These things are being pursued more and more vigorously these days. *No* silly, not the Nausicaan aliens from the planet Nausicaa from Star Trek, they are too ugly...
I mean the rights to the name 'Nausicaa'. I wouldn't mind betting its copyright or trademark or some such rubbish.

From Star Trek Locations guide;

Nausicaa
(Nausicaan homeworld)
ENT "Fortunate Son"

An Experimental Encapsulation of IP Datagrams on Top of ATM (note the date...)

Clarke's Law(1962), which was later renamed Clarke's First Law, reads:

When a distinguished but elderly scientist states that something is possible, he is almost certainly right.
When he states that something is impossible, he is very probably wrong.

When, however, the lay public rallies round an idea that is denounced by distinguished but elderly scientists and supports that idea with great fervor and emotion --
the distinguished but elderly scientists are then, after all, probably right.

Not that these are much use to anyone here, but the 2.4.xx "Hello World" kernel module can be found here and an updated for 2.6.x can be found here.

Disclaimer, I have not compiled a "hello world" module since 2.2, so I have not tested either of these examples (although the 2.4 example does look pretty much the same as 2.2, IIRC), so just mod my post all to hell if...

from the Red Dwarf FAQ

What does "smeg" mean?
It's a word made up by Grant Naylor for the characters to use as an all-purpose profanity. Some fans have theorised that it was derived from "smegma" (a particularly unpleasant bodily secretion), but Rob and Doug deny this. In the interview on the CD included with the Six of the Best box set, they state that "we wanted to invent a futuristic curse word which had the right sort of consonant and vowel arrangement to make it sound like a genuine . . . curse word." In an online chat session, Doug Naylor said "I think it's Latin for clean, also there's an Italian washing machine company called Smeg. Also each of the letters S-M-E-G stand for smelting metal and something to do with the washing machine process." A detailed list of "smeg" references in the show is available at http://www.bristol.u-net.com/smegweb/docs/smeglist .html

Pathfinder software archive

CLIPS

: A Tool for Building Expert Systems. Maintained by Gary Riley.
fuzzyCLIPS

Some other NASA soft:
COBWEB/3 (ptolemy.arc.nasa.gov) ?
AUTOCLASS AutoClass is an unsupervised Bayesian classification system for independent data.
PRODIGY cs.cmu.edu Integrated Planning and Learning System

The rfc you just linked to says:

An HTTP URL takes the form:
http://<host>:< port>/<path>?<searchpart>
where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed.

Or are you the troll?

Seems like a troll, but I'll bite.
While the original HTTP RFC did not include user:pass@domain syntax, the URL RFC 1738 does.

RFC3161

Take your (digital) evidence, get it signed and timed by a trusted third-party time-stamp service.

That way you can prove the exact digital bits you have in your possession existed at that point in time.

Also good for proving prior art.

- Lnr