Slashdot Mirror

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.

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.

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.

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.

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.

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.

IP over Avian Carriers with Quality of Service

Faster, lower latency.

IP over Avian Carriers with Quality of Service

Faster, lower latency.

...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.

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.

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.

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.

This might be of interest:
RFC-3098 How to Advertise Responsibly Using E-Mail and Newsgroup

TFTP doesn't use passwords, so it's easier to use from a script.

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.

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.

"...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."

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.

These principles guide the work carried out within W3C Activities.

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.

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

Just goes to show -- people do listen.

Thus, there are as many non-HTTP-compliant web caches as their are non-HTTP/HTML-compliant browsers.

Thus, there are as many non-HTTP-compliant web caches as their are non-HTTP/HTML-compliant browsers.

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.

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.

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:

...
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).

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.

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

ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here.

"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.

"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.

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...

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.

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.

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?

"There are an infinite number of individually addressable states -- the Coulomb potentials -- where quantum bits can be stored," said Bucksbaum.

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-

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-

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.

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 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.

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 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.

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

Thank you.
//Frisco
--
"At the end of the journey, all men think that their youth was Arcadia..." -Goethe

I wonder if that is going to use either of the avian carrier RFCs (RFC1149 Standard for the transmission of IP datagrams on avian carriers or RFC2549 IP over Avian Carriers with Quality of Service) or if Microsoft has developed there own proprietary pigeon transmission protocol...

I wonder if that is going to use either of the avian carrier RFCs (RFC1149 Standard for the transmission of IP datagrams on avian carriers or RFC2549 IP over Avian Carriers with Quality of Service) or if Microsoft has developed there own proprietary pigeon transmission protocol...

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.

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...

Oh, we might be interested to vote for our favorite RFC.

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,

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,