Slashdot Mirror

Actually, P-IMAP is supported by very few. IMAP with IDLE is very different from P-IMAP which part of a spec that Oracle helped develop for use with it's OCS 10g. P-IMAP came out of the Lemonade project and is an extension of IMAP4rev1 which was developed primarly and CMU for Cyrus, but with large contributions as well from UW with uw-imap.

The Push-IMAP protocol (P-IMAP) defines extensions to the IMAPv4 rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. The first enhancement of P-IMAP is that unlike a standard IMAPv4 Rev1 server, which relies on the client to constantly initiate contact to ask for state changes, the P-IMAP server can push crucial changes to a client. In addition, P-IMAP contains extensions for email filter management, message delivery, and maintaining up-to-date personal information. Bindings to specific transport are explicitly defined.

Last time I surfed the domain name RFCs for my QA validation, I thought I recalled a relatively recent RFC that expanded domain naming out to any character (except, presumably, the dot separator).

I think it was http://tools.ietf.org/html/rfc4343 though it could have been one of the internationalization RFCs

"However, the individual octets of which DNS names consist are not limited to valid ASCII character codes. They are 8-bit bytes, and all values are allowed. Many applications, however, interpret them as ASCII characters."

Before that, underscore was definitely not a valid character in domains.

With reduced cost per megabyte, higher data rates and increased battery life, this is becoming less and less relevant. I am completely happy with my IMAP, mainly because, when I really need to know, my server sends me an SMS that arrives in less than 10 seconds.

What, like IMAP-IDLE?

The 128-bit addresses of IPv6 are broken into two 64-bit parts - network prefix and host. A network thus has 16 billion billion addresses. Put another way, you could fit all 4 billion of the 32-bit IPv4 addresses into each IPv6 network and still have (on average) 4 billion unused addresses between each host. Even your largest corporation or institute would have at most a few thousand hosts in its network. If you could scan 1k addresses a second, it would take on average 584k years to hit *one* address in a 1k host network.

But the host part of IPv6 addresses are usually derived from the MAC address of the interface (see RFC 2464). The first three bytes of the 48-bit MAC address is assigned to vendors, assuming a "universally administered address" and not a "locally administered" one. Assuming you knew a network had equipment from a particular vendor, that still leaves 40 bits to scan, still larger than the current internet. With the same 1k host network (all with the same MAC address vendor prefix) and scanning 1k hosts a second (very fast), it would still take on average 12.7 days to find one host.

Your worm is not going to spread very quickly, and that's in ideal conditions. Your average organisation is likely to have NIC's from several vendors. There's also RFC 3041 which defines ways to randomise the host part of the address. In short, scanning will likely disappear with IPv6.

The 128-bit addresses of IPv6 are broken into two 64-bit parts - network prefix and host. A network thus has 16 billion billion addresses. Put another way, you could fit all 4 billion of the 32-bit IPv4 addresses into each IPv6 network and still have (on average) 4 billion unused addresses between each host. Even your largest corporation or institute would have at most a few thousand hosts in its network. If you could scan 1k addresses a second, it would take on average 584k years to hit *one* address in a 1k host network.

But the host part of IPv6 addresses are usually derived from the MAC address of the interface (see RFC 2464). The first three bytes of the 48-bit MAC address is assigned to vendors, assuming a "universally administered address" and not a "locally administered" one. Assuming you knew a network had equipment from a particular vendor, that still leaves 40 bits to scan, still larger than the current internet. With the same 1k host network (all with the same MAC address vendor prefix) and scanning 1k hosts a second (very fast), it would still take on average 12.7 days to find one host.

Your worm is not going to spread very quickly, and that's in ideal conditions. Your average organisation is likely to have NIC's from several vendors. There's also RFC 3041 which defines ways to randomise the host part of the address. In short, scanning will likely disappear with IPv6.

Certainly. It would make RFC 1149 data transmission vastly more efficient.

Not only that but S/MIME is an official standardized and widely recognized system whereas PGP/GPG is proprietary incompatible garbage that some guy invented.

http://www.ietf.org/rfc/rfc2440.txt

Who's asking for perfect accuracy? The general guideline for implemention of Internet technologies is "be liberal in what you accept, strict in what you produce". If you can't write a simple RE that accurately validates e-mail addresses, it's better to accept some invalid ones -- especially since there many, many perfectly well-formed e-mail addresses that are, in fact, invalid anyway. The only real way to validate an address is to send e-mail to it, any other validity checking is just testing to make sure the address looks valid-ish, so there's no point in being excessively strict.

Further, I dispute your claim that a RE for an STMP e-mail address is so hard to write. RFC 2822 defines the allowable structure in terms of a fairly simple grammar, and most of the complexity in the grammar is to accomodate addresses with names (e.g. "Foo Bar <foo@bar.com>") or lists of addresses, neither of which are relevant for most forms where an e-mail address is entered. Any structure expressible as a grammar can be expressed as a regular expression, and the mapping is straightforward.

I suspect that your two-page RE for mailing addresses tries to also accomodate bang paths, X.400 addresses and other archaic addressing formats that are no longer relevant, as well as supporting STMP address lists, angle addresses, route specifications, obsolete SMTP formats and other obscure structures that can be safely ignored -- some of which probably wouldn't be accepted by an SMTP server anyway.

I particularly love the "pipelining" part. Send requests before getting valid acknowledgments from previous requests. ...

It's rude, annoying and breaks the rules/protocol.

HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.

"I personally think programs designed to aviod network security should be banned at the govermental level (that is a tenant of hacking, isn't it, - avoid security). This would force P2P and other programs to use easily identifiable port numbers. That would allow ISP's to present customers with clear service choices in an economically viable model."

There's already been something like that proposed. Details are available in RFC 3514

As I recall, back in 94-ish when the Internet was being commercialised, address spaces were allocated away in blocks. The size of the address space you got depended largely on how well you could negotiate and show a need for them (and whether you had a few fingers in the right pies, no doubt). The people lucky enough to get large amounts of an increasingly valuable resource aren't going to just hand it over, though they may sell it at a premium. There have been RFCs written detailing observations on this and possible answers for it, and appeals to return unused IP addresses going back to at least 1996.

We will need IPv6 if the Internet gets much bigger. Maybe not right now, but at some stage IPv4 will run out no matter how efficiently addresses are allocated. There will simply be more machines than address space. I imagine that the big players who decide when it's time to do something will wait until the last possible moment before making any big (and expensive) changes. That and there'll be less excuse to charge high prices for additional IPs.

I, for one, am an avowed linux fanboi. I have been almost as long as Linux has been around. I liked it then for a lot of reasons that would not be meaningful for you. I like it now much more because it's simply better than Windows.

I do know about pxe booting. I usually use pxelinux and tftpd for that -- usually with ghost for imaging, whatever OS is called for for thin client. Yes, I can use many of the various other ways to do the same thing, including Windows RIS. A tool's a tool. You use what works today and keep your eyes open for better tools tomorrow.

I don't know much about Kereberos except that it's an open standard with a reference implementation available for many platforms from MIT. What I don't know is how this pertains to general technical proficiency or Windows. That dealing with K is not my corner of the computer world does not mean I am ignorant -- my company has specialists that handle that. The IT world is broad and nobody can be everything. I do servers too, quite a lot of them and I dare say in more depth than most.

I do and have worked in environments where you need to manage 20,000 desktops. The stuff I get paid to do on the desktop involves Windows almost exclusively. Dealing with the SVCHOST.EXE bug caused by Windows' patches for the past few months has been quite profitable. Am I happy about making my living helping my customers overcome their crippled architecture instead of helping them activate their potential? In a word, no.

I'm telling you this so you can understand -- Supporting Windows is where my money comes from today and I am quite proficient at it. The world is what it is, and a guy's got to make a living. That doesn't mean I have to be a fan of this pathetically insecure, ridiculously unreliable system with its impossibly arcane interface. I know better stuff is available, and I am confident eventually the better stuff will prevail. Between now and then I have to tread the fine line between the straight answer (you know, linux and mac users don't have this "spyware/virus/shutdown/whatever" problem) and the political one (a hardware firewall, software firewall, patch management system, license management system, ready backup, manually type hyperlinks only to known good sites policy... might mitigate the problem until those dastardly bad guys find another 0-day remote admin exploit).

When the day comes, that Intel AMT 2.0 technology we're talking about over in the opinion center will be quite handy for eradicating Windows from the face of your enterprise overnight. Use it to update the desktops in a pilot project and then once you've got the migration details set up you can command all the clients in the enterprise to download whatever version of linux you choose, no-touch, from a single console, with the requisite per-site, per-client and per-user customizations. The benefits are obvious to anyone who isn't clue immune. On that fine day a lot of MCSEs are going to be out of work -- but not me.

DOCSIS 3.0 mandates both IPv6 and IPv4 support in cable modems, as well as the other improvements. See http://www3.ietf.org/proceedings/06mar/slides/v6op s-4/v6ops-4.ppt for a presentation about why cable MSOs (operators) are deploying IPv6 (Comcast already has IPv6 in its core network and plans to roll out to homes, because it's exhausted the 10.x address space already in IPv4, and is now onto public IPv4). So this means that DOCSIS 3.0 cable modems will really be the first mass deployed IPv6 capable devices, and some cable operators will turn IPv6 on, certainly Comcast.

And I linked the wrong presentation. I meant this one:

http://www3.ietf.org/proceedings/07mar/slides/v6op s-6/sld1.htm

"Observations of IPv6 firewall and IDS".

Sorry about karmawhoring, but I'm at karmacap anyway.

"Today we learned, that lots of people who have thought of NAT as a security mechanism, are getting a hit with cluebat when they find out that the IPv4 NAT also implements a stateful firewall as a byproduct. Since there is no NAT with IPv6, you only have to implement stateful firewall without address translation."

Sigh.

This is a non-issue.

What IS an issue are the new IPv6-specific things related to security. You cannot do a network scan anymore since even a /64 is a huge address space to scan and so on. The presentation I watched at IETF Prague was quite interesting: http://www3.ietf.org/proceedings/07mar/slides/v6op s-1/sld1.htm

There are some implementation issues, such as anycast addresses and stuff like that you need to take into account.

However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.

The "E-mail address" entry in Wikipedia talks about plus addressing and refers to RFC 2822 and RFC 3696.

Google has other links. Interesting that Gmail allows plus addresses.

I'd explain how, but that would be telling

http://www.ietf.org/rfc/rfc1149.txt "A Standard for the Transmission of IP Datagrams on Avian Carriers"

The question you should be asking is - which shared calendar protocol should we choose?

Good call on the question remark, I'd disagree with your answer.

The problem is that iCalendar isn't calendar 'line' or 'sharing protocol, it's more of a 'serialization/persistance' protocol. iCalendar does not define any connection or query methods. Things like that have to be defined if there is to be any interop. We've actually written tools around the iCalendar/WebDAV combo, they work great for smaller teams, but you run into problems very quickly has the team grows or the calendar's use increases.

As things settle down, CalDAV, a.k.a RFC 4791 will probably become more of an entrenched calendar sharing standard. I've been working on a CalDAV Outlook plugin, Open Connector for quite some time. CalDAV is supported by Apple Calendaring products, Mozill thunderbird, Oracle calendaring server and a bunch of other open-source and commercial packages.

It looks like "push email" works off a relatively new IMAP protocol extension.
  1. Client connects to server, sends "IDLE" command
  2. If/when server has mail for that client, it sends a message back through the connection opened (and left open) by the client
  3. After getting a "there are messages for you" message, the client REALLY downloads the actual message (over same IMAP connection?)
  4. Upon timeout, etc., client issues "DONE" and/or reconnects

Nice whitepaper:
http://www.isode.com/whitepapers/imap-idle.html

RFC 2177:
http://tools.ietf.org/html/rfc2177

If you are sticking to the HTML 3.2 standard you are doing exactly the opposite of what you state. Before CSS...

While it doesn't apply to the person you are responding to, it's perfectly possible to use CSS with HTML 3.2. In fact, you can use it with HTML 2.0. From the HTML 2.0 RFC:

The <LINK> element is typically used to indicate authorship, related indexes and glossaries, older or more recent versions, document hierarchy, associated resources such as style sheets, etc.

CSS might not have been invented when HTML 2.0 was around, but that doesn't mean they hadn't already come up with the way to associate stylesheets with HTML documents.

And as for "HTML doing things formerly reserved for Javascript", I literally have no idea what you're referring to.

I suspect he's talking about how you can do client-side validation declaratively with HTML 5 instead of writing JavaScript event handlers for form submit events.

Do people actually read the specs?

XHTML1.1 is the modularization of XHTML1 with one important difference - you should not serve it as text/html.

If you want to drop support for all legacy browsers then be my guest, there just doesn't seem to be any point to using 1.1 until all UA's accept application/xhtml+xml

XHTML1 is the XML serialization of HTML4.1

Some say that you should not serve XHTML1 until all UAs accept the XHTML MIME type but serving as text/html to legacy UAs is permitted in the original and current recommendation, associated MIME type note and mentioned in RFC3236

Not to worry. You'll have no problem detecting unsafe traffic on .safe because all other traffic will have to have the evil bit set!

Network Voice Protocol was demonstrated in 1973 and standardized as RFC 741 in 1976. Stated goal:

"to develop and demonstrate the feasibility of secure, high-quality, low-bandwidth, real-time, full-duplex (two-way) digital voice communications over packet-switched computer communications networks"

Everything else in the patent (like using standard telephones at the ends) is pretty obvious.

See RFC 3290 for the IETF RFC spec of XMPP and XMPP.org for the home of the Extensible Messaging and Presence Protocol.

Your call for collaboration does not help the business models of AOL (AIM), Microsoft (Windows Live! Messenger) or Apple (iChat) because it cedes their control and might lose users from their platform. The big names aren't interested in it, but we-the-little-people can run our own network of OpenID enabled Jabber chatting.

Google TiSP sounds amazing. I am curious though as to the impact on RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers.

I realize that these pigeons could travel down the tubes, but this could create severe blockages of their own. The only benefit I can see is that the pigeon would die in a gaseous environment which could signal a pending DoS attack - or depending how far the infrastructure a Distributed DoS (DDoS) attack.

So fine, set up your own Internet. Nothing is stopping you.

Full instructions available for free here.

I hope you can understand that we don't give a shit whether you "trust" us or not. You don't like the way we run the net? Start your own. Put up or shut up.

See ya! Buh-bye! Have fun!

Some of the concepts that CS text books explain in a chapter of verbal cruft could be better explained in three paragraphs of transparent analogy.

``Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.''

http://www.ietf.org/rfc/rfc3675.txt

So, you mean that they abuse their economical power... But it is ok, since they do that with a nice GUI? Or are you saying (falsely) that Microsoft has not extended those protocols? Because they have extended (or tried) almost all of them, DNS being the only exception, and irrelevant since they already tried to extend TCP.

• AD can serve a standard DNS domain (even if mixed with Linux BIND servers), including an LDAP backend and dynamic updates: http://support.microsoft.com/kb/317590
  
• AD can also serve Kerberos for Linux clients (in a standard way): (here), it can also do RADIUS as well.
  
• AD is LDAP compliant so use can also use nss_ldap to grab user information on Linux system from it
  
• Linux and Windows nodes can perform two directional file sharing via standard* CIFS protocol
  
• AD (with addition of certificate services) can serve as s X509 Certificate Authority.
  
• AD + Exchange will understand SMTP, SMTP-AUTH (over LDAP), POP3, IMAP, IMAPS, NTTP protocols (additional web based access is also provided).
  
• With Windows Server 2003 R2, AD can also serve standard NIS, NFS, CUPS and similar UNIX protocols.
  
• If you include non standard (but known) protocols in the mix, Windows and Linux machines can also interoperate via DFS (Distributed File Sharing), RPD (Terminal Services), etc.
  
  
  The required setup is done less than an hour, and will require a (less competent) system administrator for maintenance in the long run.
  
  (It can be argued that the Linux side will require a more educated - i.e: more expensive - system administrator, and preparation of many site specific scripts and configurations - yet this may not seem objective for some people).
  
  Don't misunderstand I'm not proposing converting all the systems to AD. I'm telling AD is also a fine solution based on open protocols.

Ah, so it's you I have to blame for this mess. Please write out the following one hundred times:

The DNS does not categorise content. The DNS does not categorise content. The DNS does not categorise content.

If you are at all familiar with computer science then you will perhaps recognise the term "layering violation".

If you want to impose content filtering on everyone then you should push for laws requiring that all pornographic, violent, obscene, etc. content be classified with a labelling system such as PICS. Instead of misusing the DNS as a totally subjective and far too-coarse grained catagorisation system, you should consult those who actually thought about this problem logically and came up with PICS.

With PICS, instead of a subjective and fundamentally inaccurate 'porn/not porn' label, you rate HTTP resources based on their actual content. For further information, consult its website and the excellent RFC 3675 entitled .sex considered harmful.

Ah, so it's you I have to blame for this mess. Please write out the following one hundred times:

The DNS does not categorise content. The DNS does not categorise content. The DNS does not categorise content.

If you are at all familiar with computer science then you will perhaps recognise the term "layering violation".

If you want to impose content filtering on everyone then you should push for laws requiring that all pornographic, violent, obscene, etc. content be classified with a labelling system such as PICS. Instead of misusing the DNS as a totally subjective and far too-coarse grained catagorisation system, you should consult those who actually thought about this problem logically and came up with PICS.

With PICS, instead of a subjective and fundamentally inaccurate 'porn/not porn' label, you rate HTTP resources based on their actual content. For further information, consult its website and the excellent RFC 3675 entitled .sex considered harmful.

I thought this .xxx stupidity had been put to bed. The PICS system is an appropriate method of categorizing web content, DNS is not.

Agreed, but while Reed Solomon is well suited for small scratches on a CD or small losses of streamed data, it is rather inefficient in case of massive losses that can destroy a whole (contiguous) block of the data, as it operates on small blocks, and so its range of effect is limited. Fortunately there exist very robust FEC codes that can protect larger blocks. With Raptor or LDPC codes, one can protect very large blocks of data with redundant codes that yield a high probability of recovery given an overall loss rate.

In the case of critical data storage, I'd advocate in favor of large block codes such as Raptor or LDPC with a redundancy of at least 100% (meaning that one can recover the whole data is half of it is destroyed). Note that this need not be done on the physical layer, rather one could FEC-encode files with varying levels of redundancy.

Note that data recovery on damaged physical storage is no different than on unreliable transmission channels such as Wifi, 3G or IP multicast. For information, Raptor codes have been chosen for the DVB-H standard as the preferred FEC scheme for IP datacasting (based on the FLUTE protocol), and LDPC is used in DVB-S2.

For those interested by LDPC, there exists an excellent LGPL'd library by the french INRIA here (info) and here (download), and best of all it's a patent-free technology. As for Raptor, it is unfortunately proprietary and patented by Digital Fountain, but you can however find a lot of enlightening info on their Web site (worth a read if you're interested in FEC technologies).

That could or might be true.

But the most important contributing protocols involving networking looks like they come from IBM Research labs.

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

Do you have any examples?

-Hack

RFC 2549 provides a specification for IP over Avian Carriers with Quality of Service.

http://www.ietf.org/rfc/rfc1438.txt

Personally, I have always been a fan of http://www.ietf.org/rfc/rfc1149.txtRFC 1149: implementing TCP/IP via carrier pigeon :P

Pragmatically, the vast majority of content is served via http and https.

I don't think this is accurate. I believe the majority of traffic nowadays is due to BitTorrent. NNTP isn't that far behind HTTP, either, so saying "vast majority" isn't right.

If your goal is to filter the Interweb, PICS labels were designed for this purpose, or if you don't want to wait on sites to label, there's lots of filtering software out there.

I can sign up for cable and use parental controls to block my kids from recording and watching content with certain ratings.

This is exactly how PICS ratings are intended to work.

I think that the ratings are not strict enough,

The advantage of PICS is that multiple ratings bureaus are implied. Each community can rate independently from the others. This lets the solution scale globally without pissing off every other community that doesn't like the rating.

most parents don't have the technology cops to set up dansguardian and squid

These parents should make it clear that the demand exists, and ISPs will offer these services.

We have the technology, why not make their lives simpler?

Exactly. Get more sites to rate with PICS ratings bureaus, do some pointy clicky in IE, and your (Interweb) problem is solved.

I think the points people are trying to make here don't involve saying that this problem doesn't exist or it isn't a "real" problem. The solution, however, is a bad one from a technical perspective. It's like the government saying we have a fuel efficiency problem, so from now on car engine blocks shall be made out of foam and plastic. Why don't we leave the technical details to the people that actually understand how the Internet works?

IT'S NOT THAT SIMPLE. Can't you just accept the possibility that the armies of people that do this type of thing for a living might just have a reason for saying this is impractical and dangerous? If you are not sufficiently educated and skilled in this area, it is inappropriate for you to be airing your opinion, just as it's inappropriate for legislators to be pushing for this "solution" in the first place.

For a thorough consensus discussion of why .xxx is bad, please see RFC3675.

See:

http://www.ietf.org/rfc/rfc3675.txt

All of the arguements are there already.

But wait! What other protocols have you forgotten about which you use on a daily basis?

• DNS
• NTP
• HTTPS
• IMAP
• FTP
• Telnet
• Kerberos
• POP
• SFTP
• IRC
• VNC
• LDAP
• RTSP
• Rsync

The list goes on and on. In fact, my /etc/services contains 4596 ports registered for TCP protocols.

Clearly the legislation should be amended to declare the MSB of the port number to be the "evil bit" similar to that specified in RFC3514.

Better, they could use a less broken solution such as a URL tagging system like PICS.

More information on this subject, including a detailed discussion of why content segregation is dangerous, can be found in RFC3675. It suggests an actual workable solution: PICS tags.

PICS Labels (Platform for Internet Content Selection) is a generalized system for providing "ratings" for Internet accessible material. The PICS documents should be consulted for details. In general, PICS assumes an arbitrarily large number of rating services and rating systems. Each service and system is identified by a URL.

It would be quite reasonable to have multiple PICS services that, in the aggregate, provided 300 bits of label information or more. There could be a PICS service for every community of interest. This sort of technology is really the only reasonable way to make categorizations or labelings of material available in a diverse and dynamic world.

While such PICS label services could be used to distribute government promulgated censorship categories, for example, it is not clear how this is any worse than government censorship via national firewalls.

A PICS rating system is essentially a definition of one or more dimensions and the numeric range of the values that can be assigned in each dimension to a rated object. A service is a source of labels where a label includes actual ratings. Ratings are either specific or generic. A specific rating applies only to the material at a particular URL [RFC 2396] and does not cover anything referenced from it, even included image files. A generic rating applies to the specified URL and to all URLs for which the stated URL is a prefix.

This seems like very much the "right" way of doing it. It:

1. Doesn't break any existing systems,
2. Is plenty flexible enough to be used for flagging pr0n as such, but also could be used by services like del.icio.us to suggest similar content to the current page,
3. And gracefully degrades to support systems that are unaware of it.

Also, unlike their proposed port breakage, it can easily be turned off if you don't care about it.

More information on this subject, including a detailed discussion of why content segregation is dangerous, can be found in RFC3675. It suggests an actual workable solution: PICS tags.

PICS Labels (Platform for Internet Content Selection) is a generalized system for providing "ratings" for Internet accessible material. The PICS documents should be consulted for details. In general, PICS assumes an arbitrarily large number of rating services and rating systems. Each service and system is identified by a URL.

It would be quite reasonable to have multiple PICS services that, in the aggregate, provided 300 bits of label information or more. There could be a PICS service for every community of interest. This sort of technology is really the only reasonable way to make categorizations or labelings of material available in a diverse and dynamic world.

While such PICS label services could be used to distribute government promulgated censorship categories, for example, it is not clear how this is any worse than government censorship via national firewalls.

A PICS rating system is essentially a definition of one or more dimensions and the numeric range of the values that can be assigned in each dimension to a rated object. A service is a source of labels where a label includes actual ratings. Ratings are either specific or generic. A specific rating applies only to the material at a particular URL [RFC 2396] and does not cover anything referenced from it, even included image files. A generic rating applies to the specified URL and to all URLs for which the stated URL is a prefix.

This seems like very much the "right" way of doing it. It:

1. Doesn't break any existing systems,
2. Is plenty flexible enough to be used for flagging pr0n as such, but also could be used by services like del.icio.us to suggest similar content to the current page,
3. And gracefully degrades to support systems that are unaware of it.

Also, unlike their proposed port breakage, it can easily be turned off if you don't care about it.

Unfortunately port 69 is already assigned. From my /etc/services:

tftp 69/tcp
tftp 69/udp

In any case, the concept is fundamentally flawed. Ports are designed to discriminate by protocol, not by service content. This is just another flawed implementation of RFC3514.

It's only actually 'Pi Day' for a limited number of people (Specifically, those in the United States). The rest of the world uses little-endian (dd/mm/(yy)yy) or, as is more appropriate for us geeks, big-endian (yyyy/mm/dd).

"There's no place like 0:0:0:0:0:0:0:1"

You heard it here first. iThankyou.

From the RFC1939:
The POP3 server marks the message as deleted. Any future reference to the message-number associated with the message in a POP3 command generates an error. The POP3 server does not actually delete the message until the POP3 session enters the UPDATE state.
When the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state.

It depends. Just check the Evil bit.