Slashdot Mirror

How many other things started out as an April Fool's day joke and then actually got implemented?

Well, the classic example has to be RFC1149, A Standard for the Transmission of IP Datagrams on Avian Carriers

The proper solution is to encrypt all your IP traffic through IPsec tunnels. Recent work within the IETF has given new ideas about how to start performing automatic IPsec connections with any host you can speak with. This is the type of solution that will help battle echelon like networks.

The proper solution is to encrypt all your IP traffic through IPsec tunnels. Recent work within the IETF has given new ideas about how to start performing automatic IPsec connections with any host you can speak with. This is the type of solution that will help battle echelon like networks.

The proper solution is to encrypt all your IP traffic through IPsec tunnels. Recent work within the IETF has given new ideas about how to start performing automatic IPsec connections with any host you can speak with. This is the type of solution that will help battle echelon like networks.

Let me guess, they're using Digest instead of Basic authentication, and you're just pissed because Netscape doesn't support it. Here's a nickel, kid. Go get a real browser.

Here's the IETF's ENUM working group charter. If you read this as opposed to the news article, the whole scheme may make a bit more sense.

Reading through the charter (And glancing at the RFC, I don't see where they came up with the "number for every person" idea. To me, it looks like they are just giving FQDN to devices that have phone numbers. ie. your cell phone (which may be able to recieve short messages), can now have its own FQDN so internet users can address it.

Here's the IETF's ENUM working group charter. If you read this as opposed to the news article, the whole scheme may make a bit more sense.

Reading through the charter (And glancing at the RFC, I don't see where they came up with the "number for every person" idea. To me, it looks like they are just giving FQDN to devices that have phone numbers. ie. your cell phone (which may be able to recieve short messages), can now have its own FQDN so internet users can address it.

For people who like facts with their uninformed speculation.

Where is that TCP/IP carrier pigeon again?

IP over Avian Carriers is specified by RFC 1149, updated by RFC 2549. The Bergen LUG made a prototype implementation, which /. covered last April. Ping time was about an hour, with 50% packet loss.

Where is that TCP/IP carrier pigeon again?

IP over Avian Carriers is specified by RFC 1149, updated by RFC 2549. The Bergen LUG made a prototype implementation, which /. covered last April. Ping time was about an hour, with 50% packet loss.

On April 1, 2000, an RFC was released on IMPS, the Infinite Monkey Protocol Suite, which is a means of keeping track of an infinite number of monkeys on an infinite number of typewriters to see if they duplicate the works of Shakespear (or any other works for that matter). The RFC is located at http://www.ietf.org/rfc/rfc2795.txt.

RFC 2795 specified that the entity which stores the works of Shakespear (and everyone else) is the Big Annex of Reference Documents (BARD) and communicates with the ZOO (Zone Operation Organization) vie the InterAnnex Message Broadcasting Protocol for Evaluating Neo-classical Transcripts (IAMB-PENT).

Anyway, my point is that this new language is great because what other language would you want to write an implimentation of IAMB-PENT in than Shakespear? Soon we will have another Linux groups try to demonstrate this important protocol like they did with RFC 1149!

You're right - and it exists. Routing protocols that would make such things work exists for so-called MANETS (Mobile Ad-hoc NETworks), being developed by the IETF.

Working in this area myself, I'd like to point to
http://www.ietf.org/html.charters/manet-charter. ht ml, which is the IETF-working group dealing with MANET's.

Now, for the shameless plug: A link to the OLSR routing protocol for MANET's, which is showing promising results. Implementations (downloadable, with sourcecode etc. of the routing deamon) are available (drop voop@cs.auc.dk an email if interrested in the code - the www-server is currently not responding).

You're right - and it exists. Routing protocols that would make such things work exists for so-called MANETS (Mobile Ad-hoc NETworks), being developed by the IETF.

Working in this area myself, I'd like to point to
http://www.ietf.org/html.charters/manet-charter. ht ml, which is the IETF-working group dealing with MANET's.

Now, for the shameless plug: A link to the OLSR routing protocol for MANET's, which is showing promising results. Implementations (downloadable, with sourcecode etc. of the routing deamon) are available (drop voop@cs.auc.dk an email if interrested in the code - the www-server is currently not responding).

I sent a very nice, polite bug report saying that the URLs are broken in w3m, since for some stupid reason they left the 'http:' off the beginning of all the intra-site URLs, i.e. '//slashdot.org/users.pl' instead of 'http://slashdot.org/users.pl'. But instead of taking the 5 seconds it would take to fix this, they just say "Sorry, your browser's broken, we aren't going to fix it."

Well, then w3m is b0rken. See rfc1808, section 2.4.3 for the proper behaviour.

I might just go find the w3m code and fix this...

9.2. Ignored Data Message byte SSH_MSG_IGNORE string data All implementations MUST understand (and ignore) this message at any time (after receiving the protocol version). No implementation is required to send them. This message can be used as an additional protection measure against advanced traffic analysis techniques.

What's intentional is the inclusion of SSH_MSG_IGNORE message which is specifically mentioned as being useful as "an additional protection measure against advanced traffic analysis techniques." such as the one described in the paper.

Please understand that this rant is the result of 10 years of watching the Internet come to terms with the lack of a HOSTS.TXT

HOSTS.TXT (yes, all caps) was the file that contained the list of all of the hosts on the Internet. Before DNS (and for a while after), there was HOSTS.TXT. You can probably find copies of it out there (for more info, you can see this old copy which I found via this article from the IETF mailing list).

What the heck ever made you think that I felt it was "needed"? It was, of course, needed in the pre-DNS Internet of the early 80s, but certainly has not been since, and would be a scary thing to try to maintain today ;-)

I was talking about the thrashing that has occured as the Internet has scaled beyond all expectations, and then done so again; repeatedly.

As for your "HUH?", I don't know that I can help you there....

There should be a standard mechanism implemented for management and status handling of Intelectual property which becomes part of IETS standards (protocols, file formats, etc) such that there is never a question as to the availability for use of a standard.

10.3.2. Standards Track Documents

(A) Where any patents, patent applications, or other proprietary
rights are known, or claimed, with respect to any specification on
the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the
document a note indicating the existence of such rights, or
claimed rights.

Squabling over Intellectual Property in standard protocols is short sighted. It reduces the possibility the company holding the IP will be able to have the market advantage that comes with inclusion of their technology in a atandard (because no one will bother to include their technology) and potentially harms the quality and viability of the proposed standard

Wow! This is incredible news: greedy claims to obvious ideas harms everyone! The patent system is broken!

from the listed Xerox rights assertment:

"Any license granted by Xerox under this Statement shall be subject to the following condition: any party receiving such a grant from Xerox must agree to grant Xerox Corporation, Xerox Ltd., Fuji Xerox Co. Ltd., Modi Xerox Limited and any corporation, firm, partnership, individual, or other form of business organization at least forty percent (40%) owned or controlled, directly or indirectly, by Xerox Corporation, Xerox Ltd., Fuji Xerox Ltd. or Modi Xerox Limited, upon request, a license under that party's patents relating to the TIFF-FX standard, on terms and conditions no less favorable than those granted by Xerox to that party."

So they don't just own your base, they own your hide. Yeah, right. Do you expect people like that to ever be able to co-operate or agree with anyone? That whole site made me sick.

IETF Meetings

The process is simple, pay the fee, read the documents, show up prepared to make comments. The IETF works both online through their mailing lists and Face - Face with their meetings held 3 times a year.

What a depressing organization.

2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. Apr-01-1998. (Format: TXT=19610 bytes) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc2324.txt?number =2324

Too bad Starbucks don't use RFC 2324 on their machines. I could use some free coffee every morning :)

See RFC 2917 for an "informational" RFC that seems (to me, at least) to be a superior technology. I'll quote the abstract inline:

This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications.

The carrier operates the physical equipment that implements the virtual routers. The customers retain control of the virtual router as long as they keep paying their bills. VPN routes don't waft into the core like they do in RFC 2547, and the virtual routers are perfectly free to encrypt traffic over the LSP if the customer is willing to pay for it being done that way.

Can someone please explain why this 'request for comments' has attracted so little interest?

Among the voice-over-IP (VoIP) protocols out in the world are H.323 (an ITU-T spec that makes heavy use of ASN.1) and SIP (RFC 2543 et. al.)

H.323 interoperability is tough. Some problems are due to differences in how one entity encodes a piece of data and another decodes it. Many H.323 implementations, um, do not fail gracefully under such circumstances.

SIP call signalling looks like HTTP. There have been complaints that it's too verbose, and needs to be replaced with something binary. One proposal suggests using a binary encoding. It uses LZW compression and shared "codebooks" (schemas?)

That's just for call signalling. Both these VoIP protocols (and others) use RTP ("Real Time Protocol") for voice, video, etc.; that's encoded and compressed pretty darned seriously.

(I'm not speaking for my employer, I'm just speaking my mind.)

Despite the fact that the IETF uses ASN.1 in some of its protocols (notably SNMP), it is widely derided as "asinine one" around here, with the Brain-damaged Encoding Rules (BER). To get around a lot of the stupidity in ASN.1, the IETF uses a very carefully constrained subset of it.

The standard for uncompressed HDTV is a document called SMPTE-292M -- it's a 1.485Gb/S synchronous stream typically carried over coax. There is an IETF draft RFC for carrying uncompressed SMPTE-292M over IP HERE.

The University of Washington, with the assistance of Sony and Enron, presented a demonstration of seven channels of HDTV compressed to 200Mb/S over an OC-48 backbone at the National Association of Broadcaster's convention in April of 2000. In this demo, they produced a HiDef newscast on the floor on the Las Vegas Convention Center, while the newcasters, cameras, and the broadcast transmitter were all in Seattle.

I know there were limited demonstrations of highly compressed HDTV over internet protocol almost a year before that. One group that has been working on that is a University consortium called The Research Channel.

By the time the MPEG toolkit compresses a video signal down to 50:1, a LOT of data has been discarded. You see strange artifacts (if you're watching carefully enough) such as arms disappearing while the football player is throwing the ball, or water behind a moving boat looking more like clouds. Yes, for some still images you still get the 1920X1080 resolution, but mostly you get interpolated fuzz lower than the resolution of standard-definition video.

We've had PPPoE in Ontario, Canada for some time with 1MBit ADSL modems. My experience is not as bad as some, and there seems to be a lot of FUD out there.

When we got it, the RFC was six to eight months old. No kernel support. No HOWTOs.

There was a userland program that fed packets in stdin and out stdout and took 30% of a decent CPU, or 80% of a 486 firewall machine. And there was a great kernel patch for 2.2.x that actually did the job (mostly) properly. To get a good connection, you had to apply the patch (horrors!).

But six months later, the software had matured. Now pppoe support is in the main branch for 2.2.x and 2.4.x, and all the big distros are set up to use it.

It was a couple of days of pain as I got all the necessary stuff together and prepared the gateway/firewall linux box so it would reconnect if the connection went down. But since then, the gateway has had hundreds of days uptime, and I don't notice the pppoe at all.

There's no "dialup" like some people are complaining about. Sure, the connection takes about ten seconds to occur, but my box only restores its connection once a week, and usually at 3am. No inconvenience there.

We all bitched and moaned at the time, but it's hard to bitch now that it's even a normal config option in the floppy-firewall distros! When I was a kid, we had to scribe the pppoe discovery packets by hand! Uphill! In the rain!

First. MS Hailstorm (and Passport) don't have anything to do with Mono or the C# programming environment as far as I can tell. Mono is basicly a free software version of C#, not a free software version of everything the MS marketing department (you mean there's other MS departments?) has decided and will decide to throw under the .NET moniker. The relation between MS Passport and C# is coincidental.

Second. I don't understand what makes C# so superior to Java that we need it. The only reason MS is using it instead of Java is because they do not have a license to use Java. Microsoft, and Sun Settle. But that doesn't mean it shouldn't be ported, I mean, name a language that isn't supported by free software.

Third. Nicholas Petreley is right that MS Passport is a problem, and the real threat to computer users and an open Internet. What is needed is a Internet Standard way of managing authentification, one that is standard and independant of any one company or computer platform. Where is the auth: RFC?

Fourth. Mono is Free Software :-) (Software Libre) not Open Source
MS can Embrace and Extend Open Source software, it can't Embrace and Extend Free Software.

AOL, if anyone wants to read the filing available from the FCC is leaning toward the SIMPLE protocol that has come out of one of the IMPP subgroups (spawned groups?) Not Jabber, but since Jabber has publicly stated that they will support the eventual IMPP protocols (or CPIM) it may all be good. Still a lot of undetermineds, of course. And who is the major player they reference?

It's an IETF standard. (ISO/OSI did, indeed, have a set of internetworking protocol 'standards' that were competing against TCP/IP, but they lost that battle hands-down in the '80s, as it became clear that TCP/IP was the de facto standard.)

Is it RFC 2324 compliant?

Heh. I thought you meant Top-Level Aggregation identifiers. There are only 2^13 of those. 8-)
------

I still think RFC1149 is a better, and cheaper alternative! ;-)

MPLampS - Electricity over IP (with MPLS Control Plane)

This will let us send the electricity you need over the existing IP network...

Bill

It be kinda like saying that using gzip to compressed a file before transfering, is offering faster dial-up.

In my experience, using Accept-Encoding: gzip (part of HTTP 1.1, RFC 2068) does gain some download speed over dial-up, but it's less noticeable in Mozilla 0.9.1 because Moz renders tables as they're being downloaded, while IE and older Netscape wait for the last </table> before drawing anything. (This is part of why Slashdot articles seem to take a looooong time to load on IE.) You just have to design your transport and application protocols to move the common types of data (text and pixels) efficiently. That is, send and store XML documents in a compressed form, as compactness of markup was never a design feature of XML.

Active involvement in the W3C and IETF; particularly, he was an author of HTTP/1.1 (RFC2616) and several HTTP-related RFCs (e.g. 2145), in addition to which he's an all-around pretty swell guy.

IP over electrical lamps is boring.

No, really. Just today the IESG has approved for publication a new Informational RFC: MPLampS: Electricity over IP (with an MPLS control plane).

From the document:

1. IP packets carry electricity in discrete, digitized form.
2. Each packet would deliver electricity to its destination (e.g., a device with an IP address) on-demand.
3. MPLS control will be used to switch packets within the core LDS, and in the edge premises. The architecture for this is referred to as Mostly-Pointless Lamp Switching (MPLampS).
4. The MPLampS architectural model will accommodate both the overlay model, where the electricity consuming devices (referred to as "lamps") are operated over a distinct control plane, and the peer model, in which the lamps and the distribution network use a single control plane.
5. RSVP-TE (RSVP with Tariff Extensions) will be used for establishing paths for electricity flow in a de-regulated environment.
6. COPS will be used to support accounting and policy.

IP over electrical lamps is boring.

No, really. Just today the IESG has approved for publication a new Informational RFC: MPLampS: Electricity over IP (with an MPLS control plane).

From the document:

1. IP packets carry electricity in discrete, digitized form.
2. Each packet would deliver electricity to its destination (e.g., a device with an IP address) on-demand.
3. MPLS control will be used to switch packets within the core LDS, and in the edge premises. The architecture for this is referred to as Mostly-Pointless Lamp Switching (MPLampS).
4. The MPLampS architectural model will accommodate both the overlay model, where the electricity consuming devices (referred to as "lamps") are operated over a distinct control plane, and the peer model, in which the lamps and the distribution network use a single control plane.
5. RSVP-TE (RSVP with Tariff Extensions) will be used for establishing paths for electricity flow in a de-regulated environment.
6. COPS will be used to support accounting and policy.

What's good is the popular mail clients are finally starting to support it (I know the latest version Eudora supports it.)
------

After all, would PNG exist if Unisys hadn't tried to kill GIF? Would the zlib compress algorithm be developed if it weren't for software patents on other alogrithms? (From RFC #1951, "The format can be implemented readily in a manner not covered by patents," and, later, in the purpose section "The purpose of this specification is to define a lossless compressed data format that ... [c]an be implemented readily in a manner not covered by patents, and hence can be practiced freely[.]" And Ogg Vorbis is an attempt to create a audio codec not covered by the ... um, Fraven.. Frahuen... uh, the F whatever Institute's patents.

So it would seem that these patents do encourage innovation... to get around them!

Sweet! Not quite as cool as a dome on the moon or something, but still pretty interesting. And maybe the vacuum of space will help keep noises in the room across the ship from yours inaudible.

But wait, how will I check my e-mail?

Here are some more informative RFCs regarding TLDs and related servers: RFC2795, RFC3092, RFC2551, RFC2100.

There is an IETF working group with a charter for this: Site Multihoming in IPv6 (multi6)

cjs

Huh? QoS is integrated in a complete architecture. You definitly don't need IPv6. Look at DiffServ for the architecture, network engineering are interested in using. Basically the network provider marks your packets at the edge, based on the contract you have with him (and the info you give him); your packets are routed through the other providers based on the contracts they have with each others. And that's it.

If you only want to have QoS on a 1 Mbps link between your sites at San Francisco and Chicago, you might also choose the same provider so that you don't need to switch back and forth between different providers backbones. How your packets are marked, how they are handled, how your excess packets are treated, and how much you pay is just a matter of contract with your provider in the DiffServ model.

This linksys/net2phone SIP-in-a-box product was just announced yesterday. What great timing to get it published on /. :-) They haven't even updated their websites yet.

A slightly different version of this service was discussed recently on /.

We've been playing around with a SIP gateway server and a VoIP phone on our DSL connection here in Europe. It works, but phone quality to the US sucks at best. The problem is QoS. Without spending US$10,000++ per month on a dedicated IP pipe from Europe to the US with a guaranteed QoS end-to-end, VoIP just doesn't replace regular phone service. But for IP connections within Europe, we get reasonable quality. Now, if only there were more than 3 people who could call us (and two of those are inside cisco TAC who only call to test their SIP setups)

This linksys/net2phone service requires you to pay them a subscription to use their SIP gateway, and the units probably are not configurable to use alternate SIP services. So if your account expires, your box becomes an expensive blinking light source.

It should work in Europe, I doubt they care which IP block you are coming from. But all the sessions will pass to north america for processing on their VoIP network. If you do buy one of these boxes, drop me a note. I'd love to see what kind of "virtual phone number" they assign you.

the AC

[...]it lacks essential freedoms such as publication of modified versions[...]

For the record, I feel that:

• Dan is a brillant programmer who has not had to make any changes to Qmail in the last three years--since Qmail has not had one security problem of note ever. The only reason Dan has to make changes to DjbDNS is because of the way the BIND developers makes changes to how they interpret the vaguely-worded DNS RFCs.
• Dan does give away his software, and he does allow people to freely use it and freely separately distribute patches for it.
• While I do not completely agree with Dan w.r.t. the license he chose, I feel Dan has valid concerns about Linux fragmenting the way Unix fragmented. His license stops Qmail or DjbDNS from fragmenting.

Let me say this once before everyone goes nuts:

I never said that RFC == standard.

Read what I wrote. I said "well on its way." I did not say "definitely will become." Just because I did not explicitly say "but may not reach that point" doesn't mean it that isn't implied.

RFCs tended to be well documented protocols and procedures that tend to head towards standards or at least widely used methods. Most protocols never even reach this point. If a person or group writes an RFC, they believe they have something worthy of a larger audience.

And yes, I am aware of the multitude of humorous standards in there (IMPS, RFC 2795, comes instantly to mind, RFC 1097 or "subliminal telnet messaging" being an earlier one).

Still, my point in that post was that many RFCs are widely used as if they were standards even though they are not stands. Internet Relay Chat is RFC's 1459, 2810, 2811, 2812, and 2813, all marked "Experimental" or "Informational". Their headers do state they are not information standards, but this has not stopped over 10 IRC networks, dozens of client programs and tens of thousands of users from using them. Likewise, RFC 1413, a.k.a. the ident protocol, has been a proposed standard for seven years, yet is included in every UNIX-based operating system. Your secure shell products (SSH) use a protocol that has a working group, but they have not even reached the RFC point in the process!

Just because someone says something is not a standard does not mean it is not widely adopted. Personally, I want to implement RFC 2324, better known as the Hyper Text Coffee Pot Control Protocol :)

Let me say this once before everyone goes nuts:

I never said that RFC == standard.

Read what I wrote. I said "well on its way." I did not say "definitely will become." Just because I did not explicitly say "but may not reach that point" doesn't mean it that isn't implied.

RFCs tended to be well documented protocols and procedures that tend to head towards standards or at least widely used methods. Most protocols never even reach this point. If a person or group writes an RFC, they believe they have something worthy of a larger audience.

And yes, I am aware of the multitude of humorous standards in there (IMPS, RFC 2795, comes instantly to mind, RFC 1097 or "subliminal telnet messaging" being an earlier one).

Still, my point in that post was that many RFCs are widely used as if they were standards even though they are not stands. Internet Relay Chat is RFC's 1459, 2810, 2811, 2812, and 2813, all marked "Experimental" or "Informational". Their headers do state they are not information standards, but this has not stopped over 10 IRC networks, dozens of client programs and tens of thousands of users from using them. Likewise, RFC 1413, a.k.a. the ident protocol, has been a proposed standard for seven years, yet is included in every UNIX-based operating system. Your secure shell products (SSH) use a protocol that has a working group, but they have not even reached the RFC point in the process!

Just because someone says something is not a standard does not mean it is not widely adopted. Personally, I want to implement RFC 2324, better known as the Hyper Text Coffee Pot Control Protocol :)

Let me say this once before everyone goes nuts:

I never said that RFC == standard.

Read what I wrote. I said "well on its way." I did not say "definitely will become." Just because I did not explicitly say "but may not reach that point" doesn't mean it that isn't implied.

RFCs tended to be well documented protocols and procedures that tend to head towards standards or at least widely used methods. Most protocols never even reach this point. If a person or group writes an RFC, they believe they have something worthy of a larger audience.

And yes, I am aware of the multitude of humorous standards in there (IMPS, RFC 2795, comes instantly to mind, RFC 1097 or "subliminal telnet messaging" being an earlier one).

Still, my point in that post was that many RFCs are widely used as if they were standards even though they are not stands. Internet Relay Chat is RFC's 1459, 2810, 2811, 2812, and 2813, all marked "Experimental" or "Informational". Their headers do state they are not information standards, but this has not stopped over 10 IRC networks, dozens of client programs and tens of thousands of users from using them. Likewise, RFC 1413, a.k.a. the ident protocol, has been a proposed standard for seven years, yet is included in every UNIX-based operating system. Your secure shell products (SSH) use a protocol that has a working group, but they have not even reached the RFC point in the process!

Just because someone says something is not a standard does not mean it is not widely adopted. Personally, I want to implement RFC 2324, better known as the Hyper Text Coffee Pot Control Protocol :)