Domain: rfc-editor.org
Stories and comments across the archive that link to rfc-editor.org.
Comments · 398
-
Re:Fake Email AddressesWhenever I am asked for an email address from an non-reputable site, I simply give a fake one such as wigglebroggle@frogtoggle.com.
Making up domain names still pollutes the namespace, though -- imagine if people made up telephone numbers the same way. Why not use example.com instead?
The example.com, example.net and example.org domains are reserved by IANA for use in testing and documentation; they're the equivalent of a telephone 555 prefix, only less obvious. See RFC 2606, or visit the example.com web page.
-
Re:Why are sysadmins stupid?
If you care to see why this is true, read this article.
That 'tutorial' is mostly wrong and in fact has probably contributed to the problem described in the toplevel post. The tutorial's wrong both about the structure of DNS, and about the details of client/server interactions in WinDDNS. If you want to understand DNS, I suggest you go read an authoritative book on the subject, e.g., Albitz and Liu's DNS and BIND and perhaps the relevant RFCs. May I specifically recommend RFC1304, RFC1305, and RFC2136.
The best part is at the end of the tutorial:
- Win2K uses DNS names that use the underscore character.
-
Re:Why are sysadmins stupid?
If you care to see why this is true, read this article.
That 'tutorial' is mostly wrong and in fact has probably contributed to the problem described in the toplevel post. The tutorial's wrong both about the structure of DNS, and about the details of client/server interactions in WinDDNS. If you want to understand DNS, I suggest you go read an authoritative book on the subject, e.g., Albitz and Liu's DNS and BIND and perhaps the relevant RFCs. May I specifically recommend RFC1304, RFC1305, and RFC2136.
The best part is at the end of the tutorial:
- Win2K uses DNS names that use the underscore character.
-
Re:Why are sysadmins stupid?
If you care to see why this is true, read this article.
That 'tutorial' is mostly wrong and in fact has probably contributed to the problem described in the toplevel post. The tutorial's wrong both about the structure of DNS, and about the details of client/server interactions in WinDDNS. If you want to understand DNS, I suggest you go read an authoritative book on the subject, e.g., Albitz and Liu's DNS and BIND and perhaps the relevant RFCs. May I specifically recommend RFC1304, RFC1305, and RFC2136.
The best part is at the end of the tutorial:
- Win2K uses DNS names that use the underscore character.
-
Re:Why are sysadmins stupid?
If you care to see why this is true, read this article.
That 'tutorial' is mostly wrong and in fact has probably contributed to the problem described in the toplevel post. The tutorial's wrong both about the structure of DNS, and about the details of client/server interactions in WinDDNS. If you want to understand DNS, I suggest you go read an authoritative book on the subject, e.g., Albitz and Liu's DNS and BIND and perhaps the relevant RFCs. May I specifically recommend RFC1304, RFC1305, and RFC2136.
The best part is at the end of the tutorial:
- Win2K uses DNS names that use the underscore character.
-
Re:Cheap Hardware
As a frequent visitor of microsoft research facilities around the world (including the secret on in black mesa, nobody knows about that one becouse of the coverup after they tried and messed up big time working with the purest and potantially most untable copy of windows yet) I can reveal the folowing about their secret e-vaqDOTnet project. Remember that if you read this info and later work on any GPL code whatsoever our secret female assasins will be knocking on your door in minutes, they look cute but are deadly!
The evaq.net does have a a gigbit ethernet internet link but no need for a power cord thanks to the new microsoft implementation of electricity over ip (it has some enhancement making compatibility with future power-over-ip products highy unlikely unless you are prepared to sign away your soul for our documentation)Furthermore it does in fact not suck! While it does offer the new houselayout.NET conectivity saturising the gigbit link by sending data regarding the layout of your home to microsoft.com (they have some huge unused datastorage facilities now they suspended hailtorm you know) Microsoft will use the collected data to compose more efficient hovering-plans.
Posted as AC to protect my identity from the evil administrator!
On the topic of removing hardware from the x-box, all chips (the copermine based special pentium 3 version, nforce like chipset and the memory) are soldered on the main pcb only the harddrive and dvd drive are interesting but the dvd has a special power connector so you wont be able to put it in a pc. -
Better http links
-
Better http links
-
"You don't have to follow it"
...because it's only an RFC, so you don't have to follow it.That's not what RFC means, even though I know you're thinking "Request For Comments."
See the Status of this Memo section at the top of each RFC to determine whether it's an "Internet Standard" or "Internet standards track protocol" or "Experimental Standard" or "Historic" or some other category.
RFC 793 is "only an RFC" but your packets won't be routed if you don't follow it.
-
It doesn't scaleThis doesn't cause too many problems on a small scale. But if everybody picked his own root, it would be a disaster.
If you want domain names (and URLs) to work reliably and consistently from one location to another, there needs to be some mechanism to sort out conflicts over the meaning of a name. That job is inherently fraught with controversy, because it will pit people with vastly different interests, cultures, and expectations against one another. I don't particularly like the result of UDRP, but the bottom line is that dispute resolution is a difficult job no matter how it's done.
On the other hand if everybody picks his own root (or his own root search path) then URLs won't have the same meaning from one client to another, and instead of having ICANN handle disputes about who owns a TLD or SLD, we'll have the same disputes being handled by people trying to tell random users to change their root servers. or by interception proxies forced on users by ISPs. In some parts of the world there will be government edicts insisting that a particular root be used, with different roots required in different parts of the world.
Granted that ICANN is seriously screwed up and that its current proposal is not a step in the right direction. But having one authority responsible for dispute resolution at the TLD level makes a lot more sense than inviting wide variation in the meanings of DNS names.
RFC 2826 still says it pretty well.
-
Throttle ports not described by an RFCMy school had to implement and upload/download limit on internet1 traffic whlie they go over the options on how to control this problem
... Becasue of our schools privacy policy and unrestrictive content, the school doesn't want to censor or block any incoming material or outgoing. They don't monitor content.Then just start throttling ports whose protocol isn't defined by an IETF RFC. This allows legit traffic on FTP, HTTP(S), Usenet, e-mail, ssh, etc., to continue unimpeded while maintaining a neutral stance on both content and services, and it gives your school a reputation of supporting open protocols. For instance, Rose-Hulman restricts the ports that OpenNap, Gnutella, FastTrack, and WinMX use to 2.4 Mbps (about 40% of total bandwidth), and it works well. The IT department also grants exceptions to users that can prove a legitimate educational need such as a comparison and contrast of p2p filesharing networks for a computer networking course.
-
Re:Blacklists are bad - DNS fascism is WORSE!
What's far more annoying, in my opinion, is those sites who've configured their mail server to be utterly anal about DNS. Forward mapping, reverse mapping, no underscores, etc. etc.
Underscores? Quit smoking crack and read the RFCs.
Reverse mapping is a good thing for legitimate mail servers to have. Don't let slimy "direct marketers" make you believe otherwise. -
RFC3098 - How to Advertise Responsibly
This might be of interest:
RFC-3098 How to Advertise Responsibly Using E-Mail and Newsgroup -
Re:Looks good and a TFTP/FTP Question.
TFTP doesn't use passwords, so it's easier to use from a script.
-
Re:For all the other people wondering what RFP mea
Careful on your nomenclature. I didn't know what RFP meant until I read your post. Actually I knew it meant Rain Forest Puppy, but he's just a security expert, not a Reqeust for Proposals. But RFC collides with the internet's RFC or Request for Comments. The biggest reference for that would be here.
-
Re:ATT@Home DHCP problems
This is one time Linux dhcpcd is a bad thing- it's one of the few DHCP clients that actually plays by the rules, releasing your IP when you shutdown. Windows doesn't bother.
F.Y.I. There is no requirement in the RFC for a client to release the IP address.
MacOS 9 and before will release the lease upon shutdown and there is nothing more annoying then 50 angry mac users screaming at you at 8:30AM because the DHCP server went ass-up the night before and none of them have IP addresses.
FROM: http://ftp.rfc-editor.org/in-notes/rfc2131.txt"...where the client retains its network address locally, the client will not normally relinquish its lease during a graceful shutdown. Only in the case where the client explicitly needs to relinquish its lease, e.g., the client is about to be moved to a different subnet, will the client send a DHCPRELEASE message."
-
Re:What about the IETF precedentAs far as I can see, the difference is in the stated goals of the W3C. They state explicitly that one of the design principles of the Web is:
1.Interoperability: Specifications for the Web's languages and protocols must be compatible with one another and allow (any) hardware and software used to access the Web to work together.
And they further state that:These principles guide the work carried out within W3C Activities.
This would seem to be at odds with incorporating patents into standards. As far as I can tell, the IETF doesn't include any such principle. What I can find about their mission seems to be far more pragmatic.I would say that the W3C is in a difficult position. They fear that they will be sidelined if they don't find some way to incorporate patented technologies into their standards. However, this sort of action has the effect of draining the credibility out of a standards body, because it divides the community which wishes to use the technology for which the body is responsible. I believe that the W3C should avoid ratifying anything which has patents attached, unless the patent-holder allows the technology to be used on a royalty-free basis.
To make God laugh, tell him your plans. -
RFC, like request for comment? for real?
When i first went to this page I saw a shitload of RFC's. all numbers to low to be Real RFC's.
so whats up? Does this guy actually has to audacity to call something an RFC and actually just mean request for comment?
-Jon -
Re: Mailing list subscription confirmationFWIW, I emailed my concerns (as described in the above comment) to Ted Gavin, the principal author of RFC 3098. His response was that he and the other authors are in the process of amending this RFC to bring it into closer alignment with the MAPS guidelines and with RFC 2635. (The latter is an earlier RFC discussing mailing lists and spam.
Just goes to show -- people do listen.
-
Re:The only truism on the webThe Cache-Control header was invented in the HTTP/1.1 spec (RFCs 2068, 2616) as a response to the prior invention and use of web caches. Sort of like the XHTML standards and validation was created in response to the mess of HTML that webbrowsers allow and WYSIWYG editors create.
Thus, there are as many non-HTTP-compliant web caches as their are non-HTTP/HTML-compliant browsers.
-
Re:The only truism on the webThe Cache-Control header was invented in the HTTP/1.1 spec (RFCs 2068, 2616) as a response to the prior invention and use of web caches. Sort of like the XHTML standards and validation was created in response to the mess of HTML that webbrowsers allow and WYSIWYG editors create.
Thus, there are as many non-HTTP-compliant web caches as their are non-HTTP/HTML-compliant browsers.
-
Re:Pioneer is a HPB! Boot him!
Hmmm. Wonder what would be involved with contacting pioneer via RFC1149?
At least the launch vehicles would be small. Only problem is how do you put a space suit on a pigeon?
*Squaaaawk!*
No, thats not it....
*Squaaaaaaaaaaaaawk!*
Garn!
*Squaaaaaaaaaaaaaaaaaaaawk!* *crunch* ...
Oopsy. -
DNS is a pig
one problem with schemes like this is that compared to IP routing, DNS is much slower, less reliable, and more prone to misconfiguration. for another approach to solving the address exhaustion problem in the context of NATs, see RFC 3056 and draft-moore-6overnat-00.txt.
-
But it's a gTLD!
What every one has failed to notice, is that
.edu is a a "global TLD", just like his brethren .com, .org, .net, and their kid brother .int. Just take a look at RFC 1591 for the definitions. This is the section about .edu:World Wide Generic Domains:
I wonder what will DoC's decision mean to universities outside US who use their ...
EDU - This domain was originally intended for all educational institutions. Many Universities, colleges, schools, educational service organizations, and educational consortia have registered here. More recently a decision has been taken to limit further registrations to 4 year colleges and uiversities. Schools and 2-year colleges will be registered in the country domains (see US Domain, especially K12 and CC, below). .edu address regularly. My university in Iran is just one example. (I registered the .edu domain myself, after a lot of disputes with Network Solutions.) -
Re:Numbering problems
IPv6 is totally non-locative? Does that conflict with the goals stated in the RFC's that are worried about "transparency"?
Either way, I don't see any guarantee one way or another on 'locative' vs. 'transparency' with IPv6. There's been only a few addressing formats specified. We may not have seen the one that gets widely adopted yet.
-- -
Re:Instant Messaging Standardization UPDATE
Actually there is allready a RFC Draft pending in the RFC Queue.
So I guess we just have to sit down and wait, unless you want to make an EEE on an old protocol, like Unix Talk? :)
-H -
Wrong...but Mr. Postel can tell you that himselfAfter all, he wrote RFC 1591. I'll skip to the interesting part:
ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here.
Doesn't sound like he intended any restrictions on it. -
IPv6 a bad thing?
"Online companies will certainly also make use in future of a controversial feature called IPv6, designed by the Internet Engineering Task Force (IETF). At present, the anonymity of most Internet users is more or less protected because service providers generally assign a different IP address each time someone logs on. But IPv6 includes a new, expanded IP address, part of which is the unique serial number of each computer's connection hardware. Every data packet sent will carry a user's electronic fingerprints.
It's too bad to see a splotch like this in an otherwise informed article. IPv6 is an expansion of the IP protocol to expand the address space of the net, not a scheme by the IETF to help the government track you down. Using MAC addresses are just one option for ISP when assigning IPv6 adresses. I'd suggest the article author look over the RFC before making the IETF look like the RIAA or the MPAA. The internet you're using right now wouldn't exist if it weren't for them. MAC address are included with todays IPv4 packets. IPv6 is most certainly not going to make it any easier for the government to track you down. -
IPv6 a bad thing?
"Online companies will certainly also make use in future of a controversial feature called IPv6, designed by the Internet Engineering Task Force (IETF). At present, the anonymity of most Internet users is more or less protected because service providers generally assign a different IP address each time someone logs on. But IPv6 includes a new, expanded IP address, part of which is the unique serial number of each computer's connection hardware. Every data packet sent will carry a user's electronic fingerprints.
It's too bad to see a splotch like this in an otherwise informed article. IPv6 is an expansion of the IP protocol to expand the address space of the net, not a scheme by the IETF to help the government track you down. Using MAC addresses are just one option for ISP when assigning IPv6 adresses. I'd suggest the article author look over the RFC before making the IETF look like the RIAA or the MPAA. The internet you're using right now wouldn't exist if it weren't for them. MAC address are included with todays IPv4 packets. IPv6 is most certainly not going to make it any easier for the government to track you down. -
The IETF standard is ASCII
The Internet Engineering Task Force (IETF) publishes all its standards (the RFCs) for the Internet in American Standard Code for Information Interchange (ASCII). You can also submit the document in PostScript, but the ASCII is the primary reference.
ASCII is searchable, printable, indexable, and forward compatible essentially forevermore. Everyone can display it correctly, anywhere. There is no better format for any kind of International standard. The IETF debates the question of superceding ASCII as the standard format about every other year, but we've yet to identify any other format that has ASCII's advantages.
HTML might one day replace ASCII in this capacity, but it needs to be stable for longer than it has been, and the HTML generators out there never generate correct HTML (ever looked at web pages in iCab? It has a built-in syntax checker, and even slashdot comes up with errors, all the time). Until those problems are fixed...
-
Morse, Marconi, Bell, Postel
The article closes out with a musing about whether pioniers of the Internet like Tomlinson will go down in history with inventors like Morse, Marconi and Bell.
Now I frankly think that Tomlinson is not destined for many history books, and moreover that many of the ARPANET engineers will never become known as heroes the way Morse & co. are, but I think it was quite appropriate when the death of Jon Postel two years ago precipitated a wave of mourning throughout the Internet. To be sure, most Internet users never heard of him, not to mention the general public, but if you have any familiarity at all with the Internet's ascendancy, you'll know that Postel's contributions were crucial to its current success. Domain names, IP addressing, many of the basic TCP services such as chargen and echo, the Telnet protocol, FTP reply codes, the MIME standard -- Postel had a hand in developing numerous basic building blocks that now make up our everyday networking life.
Try searching for the author name Postel among the RFC's -- you get 232 hits. And I daresay that RFC authorship is a good deal more significant than authorship of a program like SENDMSG, since it's the open standards that made the Internet's success possible.
The Internet society has a page about him here. -
Re:Not surprising
English is the language of RFCs (see this overview), and therefore is the language of technology protocols and standards. All else flows from that
;)
From the RFC overview:
Like the Internet itself, the IETF and the ISOC are international organizations with representation from all areas of the world. However, English is the primary language in which IETF business is conducted, and English is the official publication language for RFCs. -
I have a dream...
Freenet is good, it came up with some pretty neat ideas, but it would be better if it had been developped and thought out in advance in the context of an IETF working group, if the specifications had been released as a Request For Comments, and, in other words, if it had paid a little more attention to existing Internet standards instead of being Yet Another anti-censorship system.
For example, why did Freenet have to come up with their own key scheme instead of using the official standard of Uniform Resource Names (URNs) defined by RFC2141 (the previous link was an example of a URN)?
I have this dream of a true world-wide distributed database founded on recognized Internet standards. It would use URNs as keys. (In particular, it would allow arbitrary Unicode character data.) It would use the ubiquitous RDF format as "semantic sugar" (pardon the expression) of its communications. It would borrow ideas from HTTP (the best Internet communications protocol we have so far) for the protocol, and Usenet and Freenet for the distribution mechanisms, as well as the public key distribution system and trust web, and the everything system. It would use public-key cryptography as the basis for its trust graph, so as to make data authentification possible and tampering impossible. Certificates and signatures would be distributed along the network itself. It would employ secret sharing mechanisms to split the risks of carrying certain data. It would be impossible to tamper with, impossible to censor, and extremely difficult to break. It would replace the lousy and obsolete DNS system (and also alleviate somewhat the power of "root registrars" in the DNS), and possibly The Web itself. And, to make my dream even more of a dream, it would be simple to implement.
Hmmm.... Nice project, for the year 2100 or so. Anyone care to start an IETF working group?
-
Monkeys and Typewriters...
"There are an infinite number of individually addressable states -- the Coulomb potentials -- where quantum bits can be stored," said Bucksbaum.
So does this mean that each electron out there is like Borel's infinite monkeys, and they all contain the complete works of Shakespeare? Or even more importantly, the un-"encrytped" digital signal of every movie ever made? If the MPAA figures this out, and gets a judge to order a halt on distribution of electrons, there sure will be a lot of hungry people in this country! -
Re:Solution to the bird problem.Can a network take down a flock of birds flying through the lasers?
I can see how this would interfere with RFC 1149and RFC 2549 based networks. "War of the networks"? "Imminent death of the net predicted, film at 11"? It would take care of dinner nicely, though. Pass the cranberry sauce, please?
Stefan.
It takes a lot of brains to enjoy satire, humor and wit- -
Re:Solution to the bird problem.Can a network take down a flock of birds flying through the lasers?
I can see how this would interfere with RFC 1149and RFC 2549 based networks. "War of the networks"? "Imminent death of the net predicted, film at 11"? It would take care of dinner nicely, though. Pass the cranberry sauce, please?
Stefan.
It takes a lot of brains to enjoy satire, humor and wit- -
Right idea, wrong implementationI completely agree: null routes are the easiest way to ensure that you don't allow RFC 1918 ingress or egress traffic. Here's the key paragraph from the RFC:
Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks.
However, your subnet mask (as is the correction you posted) is goofy, although it makes a nice wildcard mask. Let's give the Cisco kids out there some useful syntax that they can cut-and-paste into their routers (as long as they're in privileged exec/enable mode):
ip route 10.0.0.0 255.0.0.0 null0
ip route 127.0.0.0 255.0.0.0 null0
ip route 172.16.0.0 255.240.0.0 null0
ip route 192.168.0.0 255.255.0.0 null0 -
Re:A modest proposal
What we really need is a protocol that can, upon receipt of a single authenticated request, determine the speed that the remote end is running at, and then rapidly chunk out an entire page in a single request - instead of a few images here, a few javascript files there, and don't forget the stylesheet in the LINK tag!
TCP already provides flow control using a 16-bit window size field:TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission.
Window size is limited to 64K, but the TCP option Window Scale can be used to indicate the window size should be shifted by a certain number of bits, allowing a maximum window size of 2GB.
Therefore, it's obvious this protocol needs to be UDP.
UDP does not support virtual circuits -- data has to be sent in packets less than or equal to the size of the Maximum Tranmission Unit. UDP is also unreliable, has no flow control, and UDP datagrams can arrive out of order.
and then rapidly chunk out an entire page in a single request
HTTP 1.1 supports persistant connections for this purpose:
Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet. The use of inline images and other associated data often require a client to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a prototype implementation are available [26] [30]. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results [39]. Alternatives have also been explored, for example, T/TCP [27].
Security is also a concern
With IPv6, strong encryption can be used.
BXXP doesn't do that, unfortunately.. and if we're going to define a new protocol, let's plan ahead?
Fixing HTTP would be a better option.
-
Re:A modest proposal
What we really need is a protocol that can, upon receipt of a single authenticated request, determine the speed that the remote end is running at, and then rapidly chunk out an entire page in a single request - instead of a few images here, a few javascript files there, and don't forget the stylesheet in the LINK tag!
TCP already provides flow control using a 16-bit window size field:TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission.
Window size is limited to 64K, but the TCP option Window Scale can be used to indicate the window size should be shifted by a certain number of bits, allowing a maximum window size of 2GB.
Therefore, it's obvious this protocol needs to be UDP.
UDP does not support virtual circuits -- data has to be sent in packets less than or equal to the size of the Maximum Tranmission Unit. UDP is also unreliable, has no flow control, and UDP datagrams can arrive out of order.
and then rapidly chunk out an entire page in a single request
HTTP 1.1 supports persistant connections for this purpose:
Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet. The use of inline images and other associated data often require a client to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a prototype implementation are available [26] [30]. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results [39]. Alternatives have also been explored, for example, T/TCP [27].
Security is also a concern
With IPv6, strong encryption can be used.
BXXP doesn't do that, unfortunately.. and if we're going to define a new protocol, let's plan ahead?
Fixing HTTP would be a better option.
-
ipv6 ipv4
You'll have to RTFM for details (RFC-Editor or your local ipv6 man page) but there is an entire suite of methods for providing the necessary junction between the two. One of the nice things is you can implement ipv6 on your routers and big boxes and your dumb-as-a-rock MS boxes that run ipv4 won't know the difference. (knock on wood)
--
Eric is chisled like a Greek Godess -
Re:Just what we need...
Not as funny as this one.. :o)Thank you.
//Frisco
--
"At the end of the journey, all men think that their youth was Arcadia..." -Goethe -
Don't hesitate to contact us by pigeon...
-
Don't hesitate to contact us by pigeon...
-
Re:Don't underestimate lawyersThe RFCs you want are probably 1945 (HTTP 1.0) and 2068 (HTTP 1.1); you can get these from the RFC Editor pages.
In a nutshell, however, you want to:
[jas88@dax rfc]$ telnet slashdot.org 80
Trying 209.207.224.41...
Connected to slashdot.org.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 30 Apr 2000 19:05:11 GMT
Server: Apache/1.3.6 (Unix) mod_perl/1.21
Connection: close
Content-Type: text/html
Connection closed by foreign host.
Or similar. You can put GET instead of HEAD to get the actual page contents, but the raw HTML probably isn't much use. It works on hosts other than /., too :-)
James.
-- .sig? No thanks. Smoking's bad for you. -
For more information...
Here are a few more links for more information about HTTP and some neat things that are being done with it...
- Get the latest dirt from the World Wide Web Consortium.
- RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 ( text, PostScript, PDF)
- Berkeley's TranSend service is a cluster of workstations working together to act as a massive HTTP proxy. This proxy "transforms" Web pages based on clients settings. Was the basis of the ( now-commercial) Top Gun Wingman Web browser for the PalmPilot.
- The Anonymizer acts as a proxy that strips out all the unwanted/unneeded header lines that your Web browser sends.
I had started hacking together an HTTP/1.1-compliant proxy in perl that did on-the-fly compression if the client supported it, but I never got around to completing it. Initial results were impressive, especially when it was paired with a caching proxy like Squid or a CacheFlow box. Of course, with DSL and cable modems getting more widespread use, people like myself that are still pinned to a 33.6k connection are being left behind.
Caching/compressing/proxying is still in widespread usage outside North America (most notably Australia and European countries). Their problem was (is!) outrageous access prices and relatively slow overseas connections, so they've been using caching for a long time to help solve it. The US and Canada have solved their "problem" of Web pages not instantaneously loading by throwing more bandwidth at it...
-
Best RFCMaybe, but RFC527 is better...
Oh, we might be interested to vote for our favorite RFC.
-
missing RFCs?
I gather it's because no machineable copies exist of some of them. I understand that there's a project to collect soft copy and re-scan it.
This seems like a good time to call attention to my own contribution to the genre, RFC 2100, "The Naming of Hosts"... from 1 April 97, and invite those who enjoy it to go vote in the contest Rob posted about last week.
And to thank Jon.
Cheers, -
missing RFCs?
I gather it's because no machineable copies exist of some of them. I understand that there's a project to collect soft copy and re-scan it.
This seems like a good time to call attention to my own contribution to the genre, RFC 2100, "The Naming of Hosts"... from 1 April 97, and invite those who enjoy it to go vote in the contest Rob posted about last week.
And to thank Jon.
Cheers,