Slashdot Mirror

The Tao of IETF still mentions:
"We reject kings, presidents and voting. We believe in rough consensus and running code"
http://www.ietf.org/tao.html

Maybe it's just me, but might it apply here ?

Before the httpbis working group started looking at proposals for HTTP/2.0 SPDY was already implemented and deployed in the field by mutliple browser vendors, library builders for servers and several large websites. A bunch of research documents was written. And a protocol specification document draft existed. SPDY wasn't created in the open perse, but it was iterated with the help the community.

So the IETF WG let people suggest proposals:
http://trac.tools.ietf.org/wg/...

And then they voted.

SPDY got selected.

Also the SPDY draft was used as a basis for writing the new HTTP/2.0 draft.

Is anyone surprised ?

There might fundamental parts of the protocol which might have turned out differently if they would have gone through a open collaborative process.

But at first glace it doesn't look that bad.

I can see the appeal of rubberstamping what already exists.

That's completely not true. Comcast is working hard on improving transmission speeds over their slow speed lanes. They're going to have facilities on the peaks of mountain ranges that transmit the information via semaphore flags.

I believe they're in full compliance with RFC1149. https://www.ietf.org/rfc/rfc11...

Mitigating this it technically of course possible, but completely unfeasible

It's perfectly feasible to foreclose the lion's share of amplification attacks. All that's needed is for network operators to drop packets with source addresses that don't originate from their networks. This problem has been discussed for decades now but lazy network operators still can't be bothered to engage basic egress filter rules. My ISP will happily pass along packets with source addresses that they don't own; hell, I can send out packets with source addresses that don't even belong to ARIN and my North American ISP will happily pass them along.

Google can provide privacy

But they don't. They violate your privacy themselves, even when they're not cooperating with the government.

Like when? Automatically marking incoming emails as spam? Unlike your credit card, hotel, etc., Google keeps any data they collect to themselves, which is better than everyone else. Because they offer a lot of services they may collect too much data for your taste, but there are all sort of things they are accused of doing but don't do, such as rigging Chrome to send data back to them, Google glass always recording, etc.

The only cases I can find are a rogue employee using root powers to read someone's gmail (fired), and at a stretch you might be referring to PRISM. If you are, I have a lot to say on that subject.

Why are you fighting against the people who are fighting for privacy?

They aren't fighting for privacy in any meaningful sense. Occasionally they fight back as a PR move, but they've allowed all sorts of egregious privacy violations, and violate your privacy themselves.

Fighting back falls in two categories: legal and technical. Note that we need to fight on both, but the bad guys can win on whichever is weaker. I'm not a lawyer. Google published this video. My attitude is that we should fix the technical issues and hope that the lawyers will also fix the legal issues. We know that the NSA chose to bypass legal process, so there must be at least some things they want but can't get.

Google is working on end point security with Project zero, ChromeOS (secure boot + remote management), bug finding tools like afl and asan, etc. Google is working on transit security, they're upranking SSL sites, killing off SSL 3.0, killing off SHA-1, marking plain http as insecure, they invented and deployed Channel ID, Certificate pinning (which caught an intelligence agency they didn't know was attacking!). Their own networks were being snooped and they claim they now encrypt all traffic in and between data centers, but we only have their word on that. They also claim they were already planning to add encryption but reprioritized it when it was revealed that the NSA was already taking advantage of it. They're pushing for larger RSA keys, and for newer crypto entirely with features like forward secrecy. It could be argued that the newer crypto is more likely to have back doors, but as it stands there is no evidence that the NSA had any breakthrough technique for decrypting either new or old, they would just break into machines that have keys, or possibly factor smaller (1024 and less) RSA keys. Google deployed OTP and invented the U2F system which is better than OTP. As far as I'm aware, Google isn't doing much for DNS security (besides running Google DNS which has cache poisoning protection) or IP routing security (besides running Google Fiber), but perhaps they think those become irrelevant unless the attacker can also forge TLS keys.

All of those are security issues, which are tightly intertwined with privacy in that if your security can be penetrated then you lose your privacy. They also created "incognito mode", a pure privacy feature with no security implication

Already implemented with routing protocols. Take a look at e.g. https://tools.ietf.org/html/rf.... Of course, not every small shop has expertise to set up BGP peering with their ISP, nor do the ISPs provide the service..

Widespread adoption of the security flag should help quite a bit.

And do you follow up on the message or just blindly type 'yes'?

Anyway, RFC 4255 and 6594, along with DNSSEC mitigates this threat. You can even sign your keys with your CA using 'ssh-keygen -s cakey' if you like.

Layers, people.

And do you follow up on the message or just blindly type 'yes'?

Anyway, RFC 4255 and 6594, along with DNSSEC mitigates this threat. You can even sign your keys with your CA using 'ssh-keygen -s cakey' if you like.

Layers, people.

Since 2002, the STARTTLS extension to SMTP, RFC 3207, has been a standard. In this particular case, the vendor's domain appears to be hosted on Google Sites, so if the OP has a gmail account the message won't even leave Google's network until he picks up the message via HTTPS or SSL-secured IMAP.

So what we need is a system that doesn't allow for egress of bad or malicious packets. Set the evil bit in the packet header as per RFC 3514, then filter on that :-)

Go read RFC 1034, the standard that introduced DNS. HOSTS.TXT predates TCP/IP, and thus the primacy of Unix on the early Internet.

No, I don't think he did. He was suggesting that browsers truly act on that option selection in a useful way. You misunderstood his post.

The Do Not Track option is defined in the RFC draft as not doing anything except sending the DNT: 1 header to a remote server. Having it do more goes against the specification.
Of course, browsers can implement other functionality to thwart tracking, but not as part of Do Not Track, which has a very specific meaning.

(feeling karma-guilty now) Some of my previous BGP bookmarks,

The RFC6480 I'm sure you'll want to read this first, every bit of it. Others may wish to skip on to the next chapter which is a good bit and has Marvin the Robot in it.

Introduction to BGP and How BGP best path (by default!)
[2014] spammers squatting on unassigned IP address ranges
  [2014] Using BGP advertisements to gather Bitcoin mining traffic (doing digital money with unsecured protocols, kewl!)
[2012] Packet Pushers #93: Lies and Routing in the Internet great interview with Geoff Huston. Look for the show notes links too.
[2012] Packet Pushers #105: BGP Origin Validation with Resource Public Key Infrastructure (RPKI) with Alex Brand from RIPE. Discussion of attack profiles, resistance and real-world challenges to its implementation.
[2012] Previous Slashdot: Engineers Ponder Easier Fix To Internet Problem
[2013] Denver pings Denver --- via Iceland! Someone's Been Routing Internet Data Through The Great Chefs Of Europe

Here's some confusing BGP routing diagrams to print out and tape to the walls to impress everybody.

...and most of the efor was in learning the software configuration (PPP and SLIP)

You missed HTCPCP/1.0
https://www.ietf.org/rfc/rfc23...

Abstract
      This document describes HTCPCP, a protocol for controlling,
      monitoring, and diagnosing coffee pots.

Sigh... I can't tell if you're arguing this because you don't understand the English language, of if you're just trolling.

If somebody has to "be presenting their own" certificate, then they are NOT PASSIVE!! A passive network attacker is, for example, somebody sitting at a coffee shop with the WiFi card in promiscuous mode, watching all the traffic that gets sent over that (open) network. In that position, the attacker cannot do a damn thing about a self-signed cert. Now, if they are able to use ARP spoofing or DNS hijacking or can configure the router's upstream host or something like that, then they can intercept traffic and present their own certificate, sure. That requires an *active* attack, though.

The reason that passive attacks are so concerning right now is that it's pretty trivial for ISPs and governments to record all network traffic that they want to. It just costs money for storage and storage bandwidth. However, they aren't actively intercepting that traffic, just passively recording it for later data mining. TLS, even using anonymous Diffie-Hellman or a self-signed certificate, is sufficient to completely defeat that kind of monitoring.

You're basically arguing that since an armored car can't tae a hit from the cannon of a main battle tank, there's no point in armoring them at all and it would be better for them to go unarmored so as not to lure people into a false sense of security. Turns out that's bullshit: the typical threat to people moving valuables is from small arms (which an armored car can shrug off just fine), and the typical threat to browser privacy is from pervasive passive monitoring, which self-signed certs defeat. Not that I would ever argue that it's better to have a self-signed cert than a CA-signed one, but it's not as *much* worse as you seem to think.

Besides, there's things you can do to make a self-signed cert even more secure. For example, you (the user) can add *just that cert* to your trust store. Now, if an attacker tries to substitute their *own* self-signed cert, your browser should object, or at least won't show the site as truly secured. For applications (including a few browsers) that support certificate pinning, this can also be used with self-signed certs in a trust-on-first-use basis (take a look at, for example, HTTP Public Key Pinning).

It's called DANE, or DNS-based Authentication of Named Entities and described in RFC 6698. The DNS record is TLSA, it associates a TLS certificate to a domain name.

Unfortunately a major browser vendor has yet to implement it. How about supporting the feature requests to implement it? https://bugzilla.mozilla.org/s...

Internet of Things: Yeah, but the industrial applications will be huge. Imagine a factory where each machine, or every subsystem in every machine, has a health status that updates in real time, based on sensor input (I imagine this is already in place in many factories). With a sufficiently advanced setup a lot of workers could probably be laid off.

No. That is the intranet of things, not the internet of things. Also, that is just networked industrial sensors, that isn't what the "internet of things" is. The word "things" there means "things that would not otherwise be networked," like the common examples of the refrigerator and coffee maker. For example, the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) https://www.ietf.org/rfc/rfc23... isn't even clearly a joke anymore.

The code is what matters. Here's a site with a bit more info:
http://tools.ietf.org/html/rfc3463

If HOTMAIL is rejecting with one code but YAHOO is rejecting with a different code then there may be THREE issues for him to deal with.

And since he is running a server he will most likely be using port 25. Encryption may change that. But for initial testing purposes he should skip encryption for HOTMAIL and YAHOO until he can determine why his messages are being rejected.

Maybe he's suggesting to just use plain SSL without the initial plaintext exchange and initiation.

Yup. Nobody needed to reinvent traditional TLS/SSL secure sockets in order to send email.

What's wrong with STARTTLS? To quote the original RFC: "...a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error."

So in other words, if you're writing an SMTP stack you have to handle a severe security edge case by parsing a string instead of getting an exception from your secure socket library. What could possibly go wrong! Oh right... there's a reason this is on Slashdot.

Yeah we agreed about everything except for what label to put on it. There's no need to convince me to call it socialism if we already agree on what the policy should be! That's a high level of agreement, more than I normally get even from friends! I'd say we could start a political party and just avoid using the word "socialism" since that's the one thing we disagree on.

Actually, I have no issue with the word "socialism." Actually, I don't really have a problem with a single-payer system like the UK's NHS either.

Frankly, I consider the ACA to be the legislative version of BTNS, except less useful. ACA provides a number of positive changes (limits on profit-taking by insurers, eliminating pre-existing condition restrictions, minimum standards for insurance plans, etc.), but it does little or nothing to resolve the systemic issues (procedure based treatment, insurance and healthcare providers driven by a profit motive, medical bill bankruptcies, lack of cost transparency and a host of other things) in our healthcare system.

As for starting a political party, why not? I have a big jar of silver change we can use as start-up funds. Truth be told, given the current political climate (driven by unlimited political contributions -- wherein our "representatives" are only representing the monied interests), I don't see us getting anywhere better. Until we get the sewer of filthy lucre out of our political system, we will be hamstrung by the greedy monied interests whose only motto is, "Fuck you, Jack! I got mine."

I wish I wasn't so cynical, but given the current situation, I can't really blame me.

Well, X- headers are generally "experimental" (too lazy to check the HTTP RFC right now to find the exact language). If an application needs a custom header with a promise that middleboxes won't tamper with it, the application's authors need to push an RFC through the standards process.

Sure we do, it's an RFC even: http://tools.ietf.org/html/rfc...

Once again, you've proven you have have no understanding of these issues. The GP's reference to downgrade protection refers to mitigation of a MITM's ability to force a protocol downgrade to SSL 3.0 and hence gain the ability to decrypt sensitive data such as session cookies. As I mentioned in an earlier reply, TLS_FALLBACK_SCSV offers mitigation for such protocol downgrade scenarios, although it should be noted that the most desirable means of resolving this entire mess is to disable SSL 3.0 on the server side.

Why are you persisting in posting replies which clearly indicate you're nothing more than a pompous ass and pretender? To help you understand my context, I spend the majority of my time contributing to the efforts of a team that is devoted to securing a varied assortment of information assets for Fortune 50 companies. Do I really need to track you down and dox everything I find to everyone you know? Is that really what you want? Hush up now, it's past your bedtime, junior.

Systemd 'replaces' NTP and DHCP daemons which never were particularly good.

Wow, I'm pretty sure you don't know how hilarious that comment is. Surely nobody could intentionally be that ironic?

Ted Lemon wrote the Vixie/ISC DHCP; it's a beautiful piece of elegant code. Dave Mills invented NTP and wrote several of the implementations; he also invented BGP and wrote the fuzzball, and if that doesn't impress the hell out of you, you really don't know anything about computer science or the history of the Internet.

Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. -- Edsger Dijkstra (1984) On the nature of Computing Science (EWD896)

and the ability to mark Grandma as okay even if her internet is down

Neither RFC 1149 - IP over Avian Carriers nor RFC 2549 - IP over Avian Carriers with QoS protocol are implemented by my local carrier pigeon, you ignorant clod!

and the ability to mark Grandma as okay even if her internet is down

Neither RFC 1149 - IP over Avian Carriers nor RFC 2549 - IP over Avian Carriers with QoS protocol are implemented by my local carrier pigeon, you ignorant clod!

Ask yourself this question. Should I use a standard protocol with tons of tools an an ecosystem to support it or should I use a totally custom protocol to handle everything?

Yes, you should use the standard protocol... which means you should not be shoehorning printer control stuff into some custom monstrosity layered on top of HTTP!

First of all, I doubt you'll find anything that already works on Windows.

So it would have to be something like Linux on both sides. So you'll need a Linux machine as a gateway if you want to use Windows.

Now that said, there are 2 things I've seen which are available for Linux:
- multipath-TCP could do this, but TCP is usually pretty bad as a tunneling protocol if you want good latency.
- a better way might be a routing protocol with a weight for the latency (=round-trip time) and with very fast convergence to be useful. Their is existing code and a IETF draft for babel(d): https://tools.ietf.org/html/dr...

That could work.

Just set the Evil Bit, yeesh.

It’s not arbitrary if whatever terms of service your customers “agreed” to forbid them from doing what you’re cutting off. The grey area with Bittorrent is pretty much every residential broadband “agreement” forbids copyright infringement, but for all you know, I might be downloading the latest ISO of Ubuntu and not infringing anything.

Note: “Agreement” because there’s not exactly a meeting of the minds when they’re the only game in town and your choices are accept their terms unilaterally or invest in carrier pidgins...

Atleast since HTTP/1.0

http://tools.ietf.org/html/rfc...

Ah, so it is a regression ;)

In 1996 - http://tools.ietf.org/html/rfc... - earlier if you count the prior drafts.

Atleast since HTTP/1.0

http://tools.ietf.org/html/rfc...

To resist RFC-1149.

Firechat uses Apple's Multipeer connectivity for IOS, and a similar protocol for Android, to achieve a mesh network. I do not believe that any of this is MANET (the IETF's favorite mesh networking protocol).

I can!

Something very much like the, uh, modern hosts file was originally specified by rfc952 in 1985. So the venerable hosts file is nearly 30 years old! That's like 10,000 in computer years!

QED.

Question: aren't there privacy issues associated with SNI? http://tools.ietf.org/html/rfc... [ietf.org] shows no attempt to munge the server name. So even though a third party might not be able to determine what content you're trying to access, they probably can intercept - albeit with the victim experiencing an interuption in service - the hostname and determine whose content you're trying to view.

That's not really avoidable with HTTPS. The host you are connecting to is already visible to anyone packet sniffing for non-SNI HTTPS because the "attacker" can see what IP address you are making HTTPS requests to, which can be easily converted to a hostname. SNI has the same security properties in that sense.

Looking at the Wikipedia page, the two EOL'd environments that stand out are:

- Android browser on Gingerbread (and older) - hopefully this'll be solved soon, Gingerbread is finally disappearing but it's taken a while.
- Internet Explorer on Windows XP.

Everything else seems to be the kind of environment where if you're still using a browser that cannot support SNI then you're probably running into all kinds of problems anyway.

(I would like to think that Windows XP users are using Firefox these days, but...)

Question: aren't there privacy issues associated with SNI? http://tools.ietf.org/html/rfc... shows no attempt to munge the server name. So even though a third party might not be able to determine what content you're trying to access, they probably can intercept - albeit with the victim experiencing an interuption in service - the hostname and determine whose content you're trying to view.

What is really required is a combination of BCP38 and RPKI. BCP38 is 14 years old and is fairly easy to implement. I did so for a major network about a decade ago. It simply means blocking packets from addresses that do not belong to your customers. Since a great many attacks including BGP spoofing involve inserting packets to spoof the routing system, simply doing this will prevent a huge part of the problem and no new technology or techniques are required. What is required are tools to maintain a record of the network prefixes allowed from each customer and maintain the prefix lists on each router.

The ONLY excuse for the very limited implementation of this Best Current Practice is that it does cost money and the provider business is highly competitive. This puts pressure on them to avoid any added cost that can be either ignored or kicked down the road. As a result, the majority of the providers don't implement this practice that is so critical to securing the network.

RPKI is routing specific, but is far more effective. The problems at the moment are limited implementation and, again, cost. It is probably quite a bit more expensive to implement, though post implementation is probably a bit less expensive. It also is a far bigger change in the operation of routing and, therefore, more frightening. Still, any network experiencing a routing attack will certainly wish that they had implemented RPKI and that it was implemented by all. But, unlike BCP38 which generally protects others, each provider implementing RPKI is protecting themselves.

P.S. I am only an anonymous coward because some bug leaved me no longer logged in when I make comments via a new post. (Works OK for replies.) I am kevmeister, formerly a senior network engineer at ESnet.

I will go to carrier pigeon before I let ComCast touch my house.

RFC 1149 FTW!

That decision was made almost 20 years ago, and I haven't had much luck finding any records of the discussion about it. I can, however, point out that there's a big difference between numbering networks and numbering hosts. A 48-bit space for numbering hosts is tight; a 64-bit space for numbering networks is not.

And your ISP is supposed to be giving at least a /56, so take your allocation size up with them. If they won't give you more, it's not IPv6's fault, it's their fault.

It is a legitimate concern. Mocking it doesn't allay the concern.

A legitimate concern? Man! I want some of what you've been smoking, buddy!

I'd be really interested to know how one can send and receive data across the Internet without sharing your IP address with each intervening router, as well as the endpoint. I've been doing IP networking (since you're obviously rather thick, I'll explain that IP is the Internet Protocol which is the basis for all communications across the Internet. You can find out more with the TCP/IP Tutorial and the Internet Protocol Specification) for a long time, possibly since before you were born (your comments indicate that it may have been yesterday) and your IP address is critical to routing your data to and from the network node you're using at any given time.

So please, do enlighten all of us who clearly don't have your intimate knowledge of IP networking as to how we can send and receive data without sharing our IP address. I'd be much obliged.

It is a legitimate concern. Mocking it doesn't allay the concern.

A legitimate concern? Man! I want some of what you've been smoking, buddy!

I'd be really interested to know how one can send and receive data across the Internet without sharing your IP address with each intervening router, as well as the endpoint. I've been doing IP networking (since you're obviously rather thick, I'll explain that IP is the Internet Protocol which is the basis for all communications across the Internet. You can find out more with the TCP/IP Tutorial and the Internet Protocol Specification) for a long time, possibly since before you were born (your comments indicate that it may have been yesterday) and your IP address is critical to routing your data to and from the network node you're using at any given time.

So please, do enlighten all of us who clearly don't have your intimate knowledge of IP networking as to how we can send and receive data without sharing our IP address. I'd be much obliged.

Not DANE the people, DANE (DNS based Authentication of Named Entities) http://tools.ietf.org/html/rfc... Mozilla are in a position to both publish TLSA record and authenticate the CERT.

Why does the list have to be hardcoded? Why not pull the records from DNSSEC... there's a whole specification for this, RFC6698

"What is the purpose of connecting anything to a network? To communicate with other devices."

I'm learning something new from a guy with a ridiculously high SlashID now! Up until now I thought that the purpose of the internet was to allow people to communicate! Now I know it is was devices the whole time! RFC822 was just a ruse! That Tim Berners Lee guy? Just trying to throw us off the scent with has damn human readable content ruse! The ability to share documents? Again, it is about the devices sharing, not people! Network printers? Again, nobody was ever supposed to read the shit after it was printed! Yes kid, you are clueless.

Again, I'm not clear on your point. I did get the ad-hominems (thanks for those, by the way -- that was very sweet!). And your attempt to ridicule me for my /. ID was especially humorous. What is more, at 47 years old, it is kind of nice to be called 'kid'.

While having (with appropriate security controls) control systems and other devices connected to a network (note, I did not say "the Internet" although in appropriate circumstances that can be useful too) can be extremely useful, I'm no fan of connecting every damn fool thing to the Internet. There's no reason why I need to monitor my microwave oven (someone might be making popcorn -- that must be stopped!) or make sure that the bleach levels in my washing machine are optimal while I'm at the movies.

Beyond that, go ahead and read the IP, UDP and TCP protocol specifications. I have -- and first did so nearly a decade *before* Berners-Lee, et. al. published the the HTTP protocol specification. The whole point of the TCP/IP suite, as well as the DARPA/NSFNet/Internet was to interconnect devices to facilitate communications. Having read and understood those documents over the last 20+ years, I can say with some confidence that they do not require that connected devices be "general purpose" or "human focused." New applications which take advantage of these protocols are developed all the time.

SMTP and HTTP are applications that ride on top of the TCP/IP suite. They are applications which were developed to enhance the capabilities of interconnected networks. Others, such as the RPC spec are designed specifically for device to device communications.

Leaving aside your sarcasm, ill humor and general negativity, I still don't understand what point you're trying to make. Other than attacking me what, if anything, are you trying to add to this conversation? That's not a veiled slur, I really would like to understand. Please elucidate. Pretty please!

"What is the purpose of connecting anything to a network? To communicate with other devices."

I'm learning something new from a guy with a ridiculously high SlashID now! Up until now I thought that the purpose of the internet was to allow people to communicate! Now I know it is was devices the whole time! RFC822 was just a ruse! That Tim Berners Lee guy? Just trying to throw us off the scent with has damn human readable content ruse! The ability to share documents? Again, it is about the devices sharing, not people! Network printers? Again, nobody was ever supposed to read the shit after it was printed! Yes kid, you are clueless.

Again, I'm not clear on your point. I did get the ad-hominems (thanks for those, by the way -- that was very sweet!). And your attempt to ridicule me for my /. ID was especially humorous. What is more, at 47 years old, it is kind of nice to be called 'kid'.

While having (with appropriate security controls) control systems and other devices connected to a network (note, I did not say "the Internet" although in appropriate circumstances that can be useful too) can be extremely useful, I'm no fan of connecting every damn fool thing to the Internet. There's no reason why I need to monitor my microwave oven (someone might be making popcorn -- that must be stopped!) or make sure that the bleach levels in my washing machine are optimal while I'm at the movies.

Beyond that, go ahead and read the IP, UDP and TCP protocol specifications. I have -- and first did so nearly a decade *before* Berners-Lee, et. al. published the the HTTP protocol specification. The whole point of the TCP/IP suite, as well as the DARPA/NSFNet/Internet was to interconnect devices to facilitate communications. Having read and understood those documents over the last 20+ years, I can say with some confidence that they do not require that connected devices be "general purpose" or "human focused." New applications which take advantage of these protocols are developed all the time.

SMTP and HTTP are applications that ride on top of the TCP/IP suite. They are applications which were developed to enhance the capabilities of interconnected networks. Others, such as the RPC spec are designed specifically for device to device communications.

Leaving aside your sarcasm, ill humor and general negativity, I still don't understand what point you're trying to make. Other than attacking me what, if anything, are you trying to add to this conversation? That's not a veiled slur, I really would like to understand. Please elucidate. Pretty please!

"What is the purpose of connecting anything to a network? To communicate with other devices."

I'm learning something new from a guy with a ridiculously high SlashID now! Up until now I thought that the purpose of the internet was to allow people to communicate! Now I know it is was devices the whole time! RFC822 was just a ruse! That Tim Berners Lee guy? Just trying to throw us off the scent with has damn human readable content ruse! The ability to share documents? Again, it is about the devices sharing, not people! Network printers? Again, nobody was ever supposed to read the shit after it was printed! Yes kid, you are clueless.

Again, I'm not clear on your point. I did get the ad-hominems (thanks for those, by the way -- that was very sweet!). And your attempt to ridicule me for my /. ID was especially humorous. What is more, at 47 years old, it is kind of nice to be called 'kid'.

While having (with appropriate security controls) control systems and other devices connected to a network (note, I did not say "the Internet" although in appropriate circumstances that can be useful too) can be extremely useful, I'm no fan of connecting every damn fool thing to the Internet. There's no reason why I need to monitor my microwave oven (someone might be making popcorn -- that must be stopped!) or make sure that the bleach levels in my washing machine are optimal while I'm at the movies.

Beyond that, go ahead and read the IP, UDP and TCP protocol specifications. I have -- and first did so nearly a decade *before* Berners-Lee, et. al. published the the HTTP protocol specification. The whole point of the TCP/IP suite, as well as the DARPA/NSFNet/Internet was to interconnect devices to facilitate communications. Having read and understood those documents over the last 20+ years, I can say with some confidence that they do not require that connected devices be "general purpose" or "human focused." New applications which take advantage of these protocols are developed all the time.

SMTP and HTTP are applications that ride on top of the TCP/IP suite. They are applications which were developed to enhance the capabilities of interconnected networks. Others, such as the RPC spec are designed specifically for device to device communications.

Leaving aside your sarcasm, ill humor and general negativity, I still don't understand what point you're trying to make. Other than attacking me what, if anything, are you trying to add to this conversation? That's not a veiled slur, I really would like to understand. Please elucidate. Pretty please!

"What is the purpose of connecting anything to a network? To communicate with other devices."

I'm learning something new from a guy with a ridiculously high SlashID now! Up until now I thought that the purpose of the internet was to allow people to communicate! Now I know it is was devices the whole time! RFC822 was just a ruse! That Tim Berners Lee guy? Just trying to throw us off the scent with has damn human readable content ruse! The ability to share documents? Again, it is about the devices sharing, not people! Network printers? Again, nobody was ever supposed to read the shit after it was printed! Yes kid, you are clueless.

Again, I'm not clear on your point. I did get the ad-hominems (thanks for those, by the way -- that was very sweet!). And your attempt to ridicule me for my /. ID was especially humorous. What is more, at 47 years old, it is kind of nice to be called 'kid'.

While having (with appropriate security controls) control systems and other devices connected to a network (note, I did not say "the Internet" although in appropriate circumstances that can be useful too) can be extremely useful, I'm no fan of connecting every damn fool thing to the Internet. There's no reason why I need to monitor my microwave oven (someone might be making popcorn -- that must be stopped!) or make sure that the bleach levels in my washing machine are optimal while I'm at the movies.

Beyond that, go ahead and read the IP, UDP and TCP protocol specifications. I have -- and first did so nearly a decade *before* Berners-Lee, et. al. published the the HTTP protocol specification. The whole point of the TCP/IP suite, as well as the DARPA/NSFNet/Internet was to interconnect devices to facilitate communications. Having read and understood those documents over the last 20+ years, I can say with some confidence that they do not require that connected devices be "general purpose" or "human focused." New applications which take advantage of these protocols are developed all the time.

SMTP and HTTP are applications that ride on top of the TCP/IP suite. They are applications which were developed to enhance the capabilities of interconnected networks. Others, such as the RPC spec are designed specifically for device to device communications.

Leaving aside your sarcasm, ill humor and general negativity, I still don't understand what point you're trying to make. Other than attacking me what, if anything, are you trying to add to this conversation? That's not a veiled slur, I really would like to understand. Please elucidate. Pretty please!

"What is the purpose of connecting anything to a network? To communicate with other devices."

I'm learning something new from a guy with a ridiculously high SlashID now! Up until now I thought that the purpose of the internet was to allow people to communicate! Now I know it is was devices the whole time! RFC822 was just a ruse! That Tim Berners Lee guy? Just trying to throw us off the scent with has damn human readable content ruse! The ability to share documents? Again, it is about the devices sharing, not people! Network printers? Again, nobody was ever supposed to read the shit after it was printed! Yes kid, you are clueless.

Again, I'm not clear on your point. I did get the ad-hominems (thanks for those, by the way -- that was very sweet!). And your attempt to ridicule me for my /. ID was especially humorous. What is more, at 47 years old, it is kind of nice to be called 'kid'.

While having (with appropriate security controls) control systems and other devices connected to a network (note, I did not say "the Internet" although in appropriate circumstances that can be useful too) can be extremely useful, I'm no fan of connecting every damn fool thing to the Internet. There's no reason why I need to monitor my microwave oven (someone might be making popcorn -- that must be stopped!) or make sure that the bleach levels in my washing machine are optimal while I'm at the movies.

Beyond that, go ahead and read the IP, UDP and TCP protocol specifications. I have -- and first did so nearly a decade *before* Berners-Lee, et. al. published the the HTTP protocol specification. The whole point of the TCP/IP suite, as well as the DARPA/NSFNet/Internet was to interconnect devices to facilitate communications. Having read and understood those documents over the last 20+ years, I can say with some confidence that they do not require that connected devices be "general purpose" or "human focused." New applications which take advantage of these protocols are developed all the time.

SMTP and HTTP are applications that ride on top of the TCP/IP suite. They are applications which were developed to enhance the capabilities of interconnected networks. Others, such as the RPC spec are designed specifically for device to device communications.

Leaving aside your sarcasm, ill humor and general negativity, I still don't understand what point you're trying to make. Other than attacking me what, if anything, are you trying to add to this conversation? That's not a veiled slur, I really would like to understand. Please elucidate. Pretty please!