Slashdot Mirror

Take DHCP for example - damn handy system, developed by microsoft.

RFC2529 updates RFC1149. Anybody tried it out yet?

Camp Area... Wireless Access... what you really need is this.

The Internet Architecture Board has recently written a document (draft-iab-identities) which covers how DNS names are used as identities and why doing things like what verisign was trying to do is a bad thing. They don't outright specify this particular battle, but talk about it in a more generic sense.

98% is pretty pathetic - 1 error in 50. Most good Bayesian filters (SpamProbe, CRM114, DSPAM) can reach at least 99.9% (1 error in 1000) with ease. Others can grow far beyond this and reach as high as 99.985%, as a recent slashdot article covered (and this one). I reset my stats a few weeks ago, and out of 1800 spams so far, 0 have made it through. The only problem with Bayesian filtering is that it's mismarketed by companies who insist they have a better solution (although it's less accurate).

And to answer your question - collaborative filtering, such as message inoculation works quite well at boosting accuracy even beyond the high levels of accuracy Bayesian filters are really capable of, whereas things like shared groups and such hurt it.

Cisco has patented HSRP. VRRP is an IETF standard. The issue was raised back in the 1996-1998 time span. Cisco's latest comments on the matter were in 1998. Please see the IEFT comments on the matter.

There are sufficient dissimilarities between HSRP and VRRP such that both protocols are now included in higher-end Cisco products (3750G switches, for example). If there wasn't a difference, Cisco would have never put both in.

It was never the object of patent laws to grant a monopoly for every trifling device, every shadow of a shade of an idea, which would naturally and spontaneously occur to any skilled mechanic or operator in the ordinary progress of manufactures. Such an indiscriminate creation of exclusive privileges tends rather to obstruct than to stimulate invention. It creates a class of speculative schemers who make it their business to watch the advancing wave of improvement, and gather its foam in the form of patented monopolies, which enable them to lay a heavy tax on the industry of the country, without contributing anything to the real advancement of the arts. It embarrasses the honest pursuit of business with fears and apprehensions of unknown liability lawsuits and vexatious accounting for profits made in good faith. -- U.S. Supreme Court, Atlantic Works vs. Brady, 1882

Historically, the IETF has been neutral about using patents in the Standards process, and its position is summed up best in the charter of the IPR Working Group (http://www.ietf.org/html.charters/ipr-charter.htm l):

The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology.

While the 'Tao' of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of RFC2026 'The Internet Standards Process -- Revision 3' was to make it easier for the IETF to make use of encumbered technology when it made sense to do so.

Last year, there was an attempt to make the IETF change their policy, but it failed miserably (http://news.com.com/2100-1013-996351.html?tag=fd_ top).

So you can have more secure communications, but only if you pay Cisco.

Bastards.

Say what you will, the ability for a clueless end-user to click "accept" on an email and automatically schedule themselves for a meeting is a Big Deal(tm).

Kronolith (the Horde web-based calendar) and IMP can do this via iTip.

You could write the server-side of the protocol this client expects for instance.

Er, no, don't do that unless you want to keep tracking our ever-expanding knowledge of exactly how Exchange works. OpenGroupware made their server work against Connector 1.2, and then it just failed against Connector 1.4.

Admittedly, if they had had the source, they could have figured out why, and fixed things, but the point is that Connector doesn't really have a real, official, documented "protocol". It just does whatever works best for us at the time, and we're always figuring out new things.

If you're going to try to hack in to one of the Evolution backends, it would be better to use the GroupWise SOAP interface, since that does have well-defined semantics. (Although that API will also be changing over time.)

The best would be to get CAP or CalDAV finalized and out the door so Evolution can support those.

You could write the server-side of the protocol this client expects for instance.

Er, no, don't do that unless you want to keep tracking our ever-expanding knowledge of exactly how Exchange works. OpenGroupware made their server work against Connector 1.2, and then it just failed against Connector 1.4.

Admittedly, if they had had the source, they could have figured out why, and fixed things, but the point is that Connector doesn't really have a real, official, documented "protocol". It just does whatever works best for us at the time, and we're always figuring out new things.

If you're going to try to hack in to one of the Evolution backends, it would be better to use the GroupWise SOAP interface, since that does have well-defined semantics. (Although that API will also be changing over time.)

The best would be to get CAP or CalDAV finalized and out the door so Evolution can support those.

When the Calendar Access Protocol gets finished. Of course, now their talking about having to modify iCal and such to deal with inconsistencies caused by the CAP draft. The CAP draft itself is on draft 12 which is 6 years of development.

If you want a server, see if you can help get CAP out the door: IETF Calendaring & Scheduling group

From what research I've done, everyone seems to think this will be the final draft, sets up a new project. Although, I am hopeful that the UW project will be successful, although I have no clue how tough to integrate with Cyrus or Postfix it will be.

Some packets have to travel several hops over the trust network, so you have two new problems: sharing the bandwidth and finding short routes.

The first problem is solved by requiring every participant to contribute as many resources to the network as they use. You do this by charging your neighbours for forwarding their packets, and paying them to forward your packets. You're free to set the price as high as you want, and they're free to send the packets by a cheaper route, so you're in competition with their other neighbours to carry their traffic. The payment happens hop-by-hop so you don't need a digital currency, you just keep score with each of your neighbours.

The second problem (finding short routes) is solved by flooding, because that's a good way of finding the lowest-latency route in a dynamic network. But you don't want to flood the entire network because that kills scalability. Instead, anyone who wants to receive connections sends out periodic advertisement broadcasts. Each node that receives the advertisement adds an entry to its route cache. Anyone who wants to establish a connection broadcasts a search for a node with a route to the destination. If the search reaches a node that has seen the advertisement, it proceeds along the cached route to the destination. Since the broadcasts only need to overlap at one node, the diameter of each broadcast is on average half the diameter of the network, so the traffic scales according to the square root of the number of nodes, which is better than unlimited flooding but still not great.

You don't necessarily trust people more than one hop away, so you need end-to-end proof of delivery using digital signatures. When a packet is acknowledged, each node along the route updates its route cache (even the nodes that weren't in range of the original advertisement), so finding a route to a well-known destination just requires finding someone who's communicated with it recently.

One question: Will it implement RFC 1149?

I'd like to run linux on it too. Basically I don't want to pay for a bulky Zaurus or iPAQ. People always say that linux isn't good on PDAs. Well PalmOS isn't that great either. One poorly written app and you can kiss all your data goodbye.

Linux would be interesting because you'd have access to plenty of apps. You could host the compiler on the device (if you had a big memory card). You can get keyboards for these PDAs so if you really must try out some neat idea for an algorithm while you are on the road, you can.

You could use CVS, Intermezzo or rsync to sync to a desktop. If you had it use iCalendar file format (RFC2445 you can easily integrate with MS Exchange, Apple iCal, Mozilla Calendar, OpenGroupware, or various free web calendars you can find around.

What you say, Linux doesn't do database type files in a natural way like PalmOS or WinCE? Take a look at SQLite. It's a very fast and lightweight SQL engine with some interesting extensions. It is also Public Domain, so you don't have to worry about GPL if you have some political problems with that license.

People say Linux sucks on PDAs, but honestly if you look at the work for libraries, applications and kernel features geared towards embedded Linux products it's pretty obvious that Linux would do quite nicely on a PDA. Take the AgendaVR3, Zaurus or iPAQ for example. They all do a decent job with Linux.

Allow me to quote RFC 3629:

ISO/IEC 10646 [ISO.10646] defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of characters is defined by the Unicode standard [UNICODE], which further defines additional character properties...

And, for your reference, here's the link to the RFC 3629, and the link to the Unicode web site.

You are not nearly ambitious enough.

What we need is a more general way of defeating all things that will block traffic based on it not using http, as put forth in rfc 3093, dated from 1 April 2001.

First of all, there is no "alarm" of any sort. Qubits are transmitted; on average, half of them will be wasted (because the receiver has to guess at which basis to read them in). It'll be a little bit more or less than half, but about half.

Which is my point. The odds that it is exactly half are tiny, so you are going to be willing to tolerate a range of values.
As long as I can get something of value without notcibly throwing off your average I'm all set.

Ya this is really an implementation issue. The algorithm works provided we have working hardware.

The "perfect implementation" may turn out to be fundamentally impossible.

Even if you can read half of our key without us knowing, it's not a huge deal

If I can read half your key it's a HUGE deal. That would mean that quantum crypto just plain sucks. Sure you can apply other security measures on top of quantum crypto to try and fix the problem, but I could apply a lot of those same measures to IP via avain carrier

All you've done is sidestep my argument.

Think about it this way:
You and I are gambling on a coin toss. I do all the tossing and picking so I have the ability to rig a round with my double-headed coin. You want to be able to catch me if I rig a round. You tell me that you will be keeping a running average of the results and if things get too skewed, you're quitting. You give me the specfic number of rounds you will be averaging and how far away from the mean it can get before you'll cry foul.
Using this information I can calculate the risk I'm taking by rigging any number of rounds. I can then choose to rig a number of rounds that leaves it likely that I can do my rigging, play the rest fair and still most likely fall withing you established limit.

That's my point about quantum crypto being reliant on statistics. You can accept only a single possible result for, you need to allow a range of results. This leads to a vulnerability: You want to detect eavsdropping, that's kinda the whole point of quantum crypto. You want your probability of false alarm to be low (significantly less than 50%), so you need to accept a wide range of likely results. This means that there's going to be some amount of listenting in I can do where it will still be less than 50% likely that your alarm goes off.
To me this appears to be a weak point in the concept.
There are ways to combat this, but it seems that with QC, you're going to be forced to assume that you're handing over a certain number of your bits to the enemy.
In order to ensure a good probability of detection for a "significant" amount of eavesdropping, you're you going be forced to assume that X number of bits are always being intercepted, since it will not be until X+1 bits are intercepted that you will hit your desired probability of detection.
This then requires the design of a protocol where X bits can be intercepted, but it is still to hard to guess the message, so you start employing privacy amplification. While I'm not all that familiar with privacy amplification, I expect there are fundamental limits to it's effectiveness, just the same as in the fields of compression and error correction.

But again, even if you read 50% of our key (or 90% or 95% or ....), we can make it arbitrarily secure by increasing the key length.

Same thing with carrier pigeons......which is why I'm getting the impression that QC is overrated.

There is RFC 2385 titled Protection of BGP Sessions via the TCP MD5 Signature Option. In the first paragraph of its Introduction section it says -

The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.

The date of publishing - August 1998, which makes it about 6 years old.

However the proposed option was primarily meant as a quick BGP fixup, which should've got depricated as soon as IPsec got RFC'ed and deployed. It did went standard few months later, but IPsec implementations enjoyed full share of cross-vendor compatibility problems.

With time Authenticated Header (AH) IPsec protocol didn't see much use or acceptance and IPsec slowly evolved (and keeps evolving) into confidentiality rather than authentication layer.

Besides it's an IP security after all, while the RST spoofing is a TCP problem. And one can quite rightfully percieve authenticating TCP with IPsec as an overkill.

Anyhow, long story short - it's a known and rather old problem with handful of existing and equally unattractive solutions. Perhaps this time around it will be addressed better due to the amount of the publicity it's aimed to get.

A recently published I-D (here) claims 200 seconds is sufficient time for a broadband sub to successfully attack a TCP session, provided their ISP doesn't use egress filtering (and way too few do so).

This is rather serious. Whether you personally aren't susceptible is irrelevant if your upstreams are.

There is a new Internet draft addressing this issue.

Even worse, they didn't set the ISMALICIOUS flag, in *clear* violation of RFC-3514...

If you want to tax networks, there are several other things that you've got to start taxing as well. First off, by setting up a pair of tin cans with some string between them, I have in fact created a local point-to-point communication medium. It's a two-node network, isn't it? I guess that my tin cans should be taxed.

Now that we've broadened our horizons a bit, let's look at the other networking equipment around the office...ah, Pigeons. The little buggers are RFC 1149 capable, and thereby capable of carrying network packets. Therefore, 9.17% of the pigeons on and near the office must be reported as taxable hardware. The same goes for Sparrows.

Beyond the simple networking hardware, we have to factor in social networking. The low-delay, high-loss mesh network used to communicate rumors through an office building is a highly complex device that is very expensive to maintain. The nodes in this network recieve pay at regular intervals (AKA "Salary") in order to remain part of the network. Therefore, another 9.17% (or more, if you're part of several social networks, or are a social hub) of your salary should be taxed away, you network node, you. You can dodge this one if you don't talk to any real people though. Keep your relationships virtual, and you'll be able to categorize your communications as part of the existing wired infrastructure. No point in being double-billed, is there?

Let's just hope this tax blows over.

If you want to tax networks, there are several other things that you've got to start taxing as well. First off, by setting up a pair of tin cans with some string between them, I have in fact created a local point-to-point communication medium. It's a two-node network, isn't it? I guess that my tin cans should be taxed.

Now that we've broadened our horizons a bit, let's look at the other networking equipment around the office...ah, Pigeons. The little buggers are RFC 1149 capable, and thereby capable of carrying network packets. Therefore, 9.17% of the pigeons on and near the office must be reported as taxable hardware. The same goes for Sparrows.

Beyond the simple networking hardware, we have to factor in social networking. The low-delay, high-loss mesh network used to communicate rumors through an office building is a highly complex device that is very expensive to maintain. The nodes in this network recieve pay at regular intervals (AKA "Salary") in order to remain part of the network. Therefore, another 9.17% (or more, if you're part of several social networks, or are a social hub) of your salary should be taxed away, you network node, you. You can dodge this one if you don't talk to any real people though. Keep your relationships virtual, and you'll be able to categorize your communications as part of the existing wired infrastructure. No point in being double-billed, is there?

Let's just hope this tax blows over.

TCP/IP over Avian Carrier, obviously.

Duh.

Like someone already pointed out, it's not really different than TCP MD5 Signature (unless I didn't understood what you mean).

1. RFC3261,
2. RFC3262,
3. RFC3263,
4. RFC3264, and;
5. RFC3265.

1. RFC3261,
2. RFC3262,
3. RFC3263,
4. RFC3264, and;
5. RFC3265.

1. RFC3261,
2. RFC3262,
3. RFC3263,
4. RFC3264, and;
5. RFC3265.

1. RFC3261,
2. RFC3262,
3. RFC3263,
4. RFC3264, and;
5. RFC3265.

1. RFC3261,
2. RFC3262,
3. RFC3263,
4. RFC3264, and;
5. RFC3265.

RTFA (Read the F'in Advisory).
The bug is in the pluggable protocol handler for MHTML, which is implemented in outlook express.

For better or worse, IE is nearly infinitely extensible, and it calls out to other components to parse extra protocols.

Pfft! Real men use netcat and the FTP RFC for reference.

Well, we already have a framework for such communication in the form of the Infinite Monkey Protocol Suite.

Perhaps we need to revise it to allow poo flinging, though.

Will This help you Google? RFC 3098
Which is about
How to Advertise Responsibly Using E-Mail and Newsgroups
or - how NOT to MAKE ENEMIES FAST!
http://www.ietf.org/rfc/rfc3098.txt

Before that, BBSs. Mostly WWIV, Nightline, and a few other types of software. I helped set up a Fidonet once, which had a crossover into the 'Net, and another time, was a tech guy for Caffnet, a POD-like network a friend of mine set up.

Heh... good times.

More on topic, my favorite RFC's:

Etymology of "Foo"
The Infinite Monkey Protocol Suite (IMPS)
Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
And who can forget A Standard for the Transmission of IP Datagrams on Avian Carriers
? Packet by pigeon...

Before that, BBSs. Mostly WWIV, Nightline, and a few other types of software. I helped set up a Fidonet once, which had a crossover into the 'Net, and another time, was a tech guy for Caffnet, a POD-like network a friend of mine set up.

Heh... good times.

More on topic, my favorite RFC's:

Etymology of "Foo"
The Infinite Monkey Protocol Suite (IMPS)
Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
And who can forget A Standard for the Transmission of IP Datagrams on Avian Carriers
? Packet by pigeon...

Before that, BBSs. Mostly WWIV, Nightline, and a few other types of software. I helped set up a Fidonet once, which had a crossover into the 'Net, and another time, was a tech guy for Caffnet, a POD-like network a friend of mine set up.

Heh... good times.

More on topic, my favorite RFC's:

Etymology of "Foo"
The Infinite Monkey Protocol Suite (IMPS)
Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
And who can forget A Standard for the Transmission of IP Datagrams on Avian Carriers
? Packet by pigeon...

Before that, BBSs. Mostly WWIV, Nightline, and a few other types of software. I helped set up a Fidonet once, which had a crossover into the 'Net, and another time, was a tech guy for Caffnet, a POD-like network a friend of mine set up.

Heh... good times.

More on topic, my favorite RFC's:

Etymology of "Foo"
The Infinite Monkey Protocol Suite (IMPS)
Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
And who can forget A Standard for the Transmission of IP Datagrams on Avian Carriers
? Packet by pigeon...

borked link. lets try that again, shall we?

RFC 0825 - Request for comments on Requests For Comments

RFC2223 - Instructions to RFC Authors

RFC 0825 - Request for comments on Requests For Comments

This one is my favourite:

RFC 1149: A Standard for the Transmission of IP Datagrams on Avian Carriers

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

Wouldn't it make more sense to introduce a date format where there was a separator between the fields? Then the length of the fields can grow as needed.

Yes, I do understand that this RFC was an April 1st joke, but still...

Sounds like a great opportunity to apply the new RFC from yesterday, #3751:

There is a long, long tradition for RFCs to be issued on 1-April which are not to be taken so seriously (e.g.: Telnet Randomly Lose (748) and Subliminal Message (1097) options). They've occasionally shown up on implementation checklists: this can been interpreted by the vendor's support departments that a potential client may need additional support.

Some are intended to be taken seriously, but authors have been known to request pubilication to be held for a few days to prevent confusion (not that there aren't some that need this distinction).